* 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')
* add basic reaction view
* reuse pill background
* make pill border a little more visible; this affects sended reactions as well as received ones
* use 🤣 instead of 😂 to differ more from 😢
also, 😂 is a bit outdated for younger generations
(so is probably 🤣 but not that much)
(alternative would be 💀 for laughing,
but that is probably not compatible between generations)
* use 🙁 instead of 😢 for 'sad' to distict from lol
lol gets revered to 😂 as
🤣 seems to be even a more non-go (thanks for expertise, young folks!)
* wording: we add one reaction, not many
* show/hide add-reaction-view together with action mode
* pass message&view to showAddReactionView()
* add sendReactions() api
* create AddReactionView class
* send reactions on click
* hide AddReactiobView on sending emoji
* detect self-reaction
* feat: remove selections
* position AddReactionView atop of parent view
* move AddReactionView up a bit
* padding top/bottom
* center for now, this also postpones rtl/ltr
* force initial layout
* move slightly more off the bubble, keep away a bit from screen margin
* move AddReactionsView left/right depending on incoming/outgoing mails
* do not allow reactions in read-only chats
* do not allow to react to videochat-invitations and info; the latter may makes sense at some point, however, to lower burder on other implementations, we do not send them for now
* hide reaction-picker when leaving action mode with 'back'
* hide reaction-picker when leaving action mode with 'back'
* scroll reaction-panel together with recyclerview; this does not happen if new messages come in, however, this is a minor (and a stable panel position can be regarded even as a feature)
* add sending reactions as an experimental feature as long not at least all system display reactions
* clarify that reactions are currently not seen by all members
* prefer View.INVISIBLE over offscreen hack
* 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
B. Petersen