* Verified 1:1 chats, Android UI (#2560)
Depends on https://github.com/deltachat/deltachat-core-rust/pull/4315/.
Follow-up for https://github.com/deltachat/deltachat-android/pull/2541.
- Show a "verified" icon on protection changed update messages
- Add C API
- Show a dialog over the input bar not only for contact requests, but also when the protection is broken (using the new method `isHalfBlocked()`)
- The positive button reads "OK" (as opposed to contact requests where it reads "Accept")
- Add SVG icons, remove PNG one
- Translations
- When tapping on the `DC_INFO_PROTECTION_{EN|DIS}ABLED` message, show more information (for now, it leads to the online preview of my FAQ PR)
- Block loading remote images in the "Full Msg View" not only for contact requests, also when the protection is broken (using the new method `isHalfBlocked()`)
- Show a big verified/crossed-out-verified symbol over the `DC_INFO_PROTECTION_{EN|DIS}ABLED` messages
- Fix a bug that was kind of present before (for contact requests) but only became really visible now:
- Set a draft with an image (or other attachment)
- Your chat partner breaks verification
- Expected: Both the input bar and the draft image are hidden by the input-bar-dialog.
- Bug behavior (before c31de5bcf): The input bar is hidden, but the draft image stays visible.
* change button order of verification-broken alert (#2621)
Having "OK" in the middle of the buttons is weird. The old order was:
```
End-to-end encryption cannot...
[More Info] [OK] [Scan QR code]
```
1. _If_ the main purpose of the dialog would be to "Scan QR code",
the text should point that out more, also the opening button.
Then, the button position would be correct, however,
it has to read "Cancel" then.
2. _However_, the main purpose of the dialog is to "Show Info",
"Scan QR code" is only an optional offering and the button a shortcut only.
And finishing "Show Info" is better done by a simple "OK".
Then, the "OK" should be rightmost.
This PR implements the second option, the buttons read as follows afterwards:
```
End-to-end encryption cannot...
[More Info] [Scan QR code] [OK]
```
* fix: load updated display name when chat protection breaks
* Implement feature flag for verified 1:1 chats
* Update res/values/strings.xml
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/connect/DcHelper.java
* Make another AlertDialog
* Revert "Implement feature flag for verified 1:1 chats"
This reverts commit 2efd17edfcf14e3cf89a6671df38647b552e5661.
* Fix typo
* email server->email provider
---------
Co-authored-by: bjoern <r10s@b44t.com>
Co-authored-by: adbenitez <asieldbenitez@gmail.com>
when talking about this function,
it is most times called 'Verified by me'.
this also makes translations easier to languages that
have diferent forms (as 'Du' vs. 'Sie' in german)
even though, we're most times using 'You' when the 'App talks to you',
we have some exceptions as 'Me' in the summary already,
where the 'You' does not work well.
(we leave the key as is, this is not really shown to translators anyways,
better key might be 'verified_by_self', however, it is not worth
opening this issue as the key is already in use -
and it is also not needed to force retranslation,
locales should use what fits and sounds best, may it be 'Me' or 'You')
* set targetSdkVersion to 33
* api33 requires permission NEARBY_WIFI_DEVICES to access wifi
not sure, if this affects getSystemService(Context.WIFI_SERVICE),
however, we anyway do not ask for permissions here but just try/catch -
if things do not work, we just cannot get the wifi name
(we're not asking for permission as this would require LOCATION in the past -
and that would scare users that just installed Delta Chat
and select "Add Second Devive".
this is the exact reason why NEARBY_WIFI_DEVICES was introduced, btw.
so in case getting the Wifi name does not work on api33,
we can consider asking for a permission - would still be on startup, however)
* update storage permissions in manifest
according to https://developer.android.com/training/data-storage/shared/media#storage-permission
* also update compileSdkVersion
* api33: adapt audio permission request
* api33: adapt gallery permission request
* request correct permissions for the 'photo rail'
* request correct permissions for avatar selection
* api33: storage and audio permission not needed
* add comment wrt 'camera roll'
* add POST_NOTIFICATIONS to the manifest, this already allows to enable notifications in the system settings
* ask for POST_NOTIFICATIONS permission on startup
* explain how to re-enable notifications if initially disabled
* prefer a device message over an alert
* show in settings if notifications are system-disabled
i just checked all translations from Signal,
they all use `+NUM` or very few `+ NUM`
(the latter might be a typo as transifex makes it easy to mess up with spaces).
also, the string would be hard to explain to translators
and would probably result in quite some questions.
if a language pops up that need sth. different,
we can still iterate.
the system camera has usually more features (flash, physical zoom, filter)
and is less buggy than the mostly unmaintained built-in one.
also, the system camera seems to be more supported
(isDeviceSupported() is not needed) and does not require to ask for permission.
there is still a switch in "advanced settings" to use the old built-in camera,
however, at some point we may remove the old code completely.
- meet.jit.si is no longer usable without registration,
so does not work smoothly for ad-hoc calls
- basicwebrtc: protocol is no longer build-in in any app,
so that example does not make sense as well
this is an intermediate step,
we want to get rid of the example string completely
and instead show the URLs of the predefined settings.
closes https://github.com/deltachat/deltachat-android/issues/2642
* streamline menu
- remove prefix 'Show', we are not using it at most other places,
nor do comparable UI
- move 'All Locations' below 'All Media',
this seems to be more logical
(we were even thinking of making 'Locations' a tap in 'Media')
* add missing plural form for 'Location' (needed for iOS map experiments, maybe also the better title for the in-chat-maps in general)
* update changelog for 1.36, core part
* update changelog for 1.36, android part
* bump version to 1.36
* add device message for 1.36
* qualify 'Add Second Device' as experimental also in device message
* apply recent suggestions to CHANGELOG
we already had a confirmation dialog for probably most security-aware users
always when the device is protected by a screen lock.
this commits adds a more on-point text -
and shows the same text in a simple alert in case a device has no screen lock.
ppl try already now to set up a second device from the welcome screen.
however, end up in logging into their email account again,
creating issues with keys and more.
a dedicated "Add as Second Devies" button targets this UX issue
by offering a clear path for setting up a second device.
moreover, the string "Scan Invitation Code" is used again (as on all releases),
this string is used quite a bit in different handouts,
changing that would worsen UX as well.
the "Restore from Backup is moved down,
if you really use this path, finding the button is the smallest issue.
the different layout of the button makes clear,
that this is not the preferred way to set up a new account
(but sure, to restore a backup :)
B. Petersen