a common hint makes things easier,
and also has the advantage, that it is more clear to the user what the
focus of this view is as it picks up the wording from the title.
* factor out checkmark strings
* no automatic remote content for contact requests
loading remote content in contact requests
now always require explicit consent of the user.
moreover, contact request do not alter
the otherwise used never/once/always settings.
* re-applying patch from @Hocuri from #2458
* apply sandbox isolation patch from @WofWca
* wait for gc as suggested by @WofWca, @Simon-Laux and others
* Update res/raw/sandboxed_iframe_rtcpeerconnection_check.html
Co-authored-by: WofWca <wofwca@protonmail.com>
* Update res/raw/sandboxed_iframe_rtcpeerconnection_check.html
Co-authored-by: WofWca <wofwca@protonmail.com>
* improve progress bar, inspired by @Simon-Laux and @WofWca
* comment about the gist of setNetworkAvailable()
* unify url-loading; this cleans up things and makes adding CSP more straight-forward
---------
Co-authored-by: WofWca <wofwca@protonmail.com>
* update CHANGELOG for 1.34.9
* bump version to 1.34.9
* add a little device message for the 1.34.9 update
* add f-droid changelog
* make device message more clear and add it only for existing installations
* bump to 1.34.10
this is similar to opening a chat and feels more natural.
settings/connectivity/help etc. still appear from the bottom as being
"something little different".
* basic layout of new archive-link, including icon and unread counter
* remove 'archived chats' from main menu
* vertically align elements of new archive-link
* show unread indicator also for archived chats
* show muted unread counter in grey
* use shorter label for the 'Archive' link
sdk16/android4.1 does not support RTL fully,
therefore just return LTR in this case
(this is also what `ViewCompat.getLayoutDirection()`
and `View.getLayoutDirection()` are doing).
always using `ViewCompat.getLayoutDirection()`, however,
causes problems as the layout is based on the content then
(see #2422)
closes#2420
notificationManager.notify() sometime crashes,
it seems to be on some OS versions
in combination with missing sounds (maybe deleted system sounds, idk).
i could not reproduce the issue,
however, by the stack traces reported in the gplay backend,
adding a try/catch block should help.
there is also a similar issue reported on stackoverflow ,
https://stackoverflow.com/questions/72491592/notificationmanager-notify-throwing-securityexception-only-on-android-11-and-1
in the issue, ppl try to fall back to some default parameters in the exception block,
however, as it is a bit unclear what really the issue is,
one only risks further crashes; also, the crashes are still quite rare,
sth. seems to be wrong in the OS here,
so we should not try to be too smart here.
* bump targetSdkVersion to 32
* explicitly set `android:exported` for `indent-filter`
this is required since targetSdkVersion 31,
https://developer.android.com/guide/components/intents-filters#Receiving
as the default was `false` before,
i just explicitly set `android:exported="false"` without looking in the details
of each filter.
* update to gradle 7.2.2; this might be needed to get warnings etc.
* update androidx dependencies
at least the update of androidx.sharetarget is required because of the missing
`android:exported`; i took the chance to update all androidx depenencies.
see https://developer.android.com/jetpack/androidx/releases/appcompat
for a CHANGELOG of each dependency.
* use explicit dependency instead of transitive ones; this fixes a weird duplicate error, see https://stackoverflow.com/questions/69817925/problem-duplicate-class-androidx-lifecycle-viewmodel-found-in-modules
* work around google's poor design decision wrt FLAG_MUTABLE
instead of setting a default behavior and logging a warning,
google crashes the application when the flag is missing on newer androids.
and setting the flag for older API seems to be undefined and therefore a lot of
Build.VERSION.SDK_INT >= Build.VERSION_CODES.M would be required each time
a PendingIntent object is constructed ...
our Util returns either the new flag or zero,
so that can just be used unconditionally on construction.
* update dependencies but exoplayer to mitigate issues with FLAG_MUTABLE
exoplayer needs more love and updating opens a can of worms;
i tested, at least in the emulator, video and voice message playback
works as usual, so let's update exoplayer if needed.
* add dclogin scheme to qr code scan
* Update src/org/thoughtcrime/securesms/qr/QrCodeHandler.java
Co-authored-by: Asiel Díaz Benítez <asieldbenitez@gmail.com>
* Update src/org/thoughtcrime/securesms/qr/QrCodeHandler.java
Co-authored-by: bjoern <r10s@b44t.com>
* handle DCACCOUNT and DCLOGIN schemes on new intents
* keep existing function name, that is maybe not less confusing, but at least already known
Co-authored-by: bjoern <r10s@b44t.com>
Co-authored-by: Asiel Díaz Benítez <asieldbenitez@gmail.com>
* move webxdc private apps to separate tab
* switch to scrollable tab layout; fixed layout may look not-so-nice with more tabs and longer descriptions that get a tiny font then
* reword "Webxdc [content]" to "Webxdc Apps"
adding "App" to the term makes things much clearer to the user,
was "Webxdc" is about.
eg. on iOS, we have an app selector meanwhile,
calling that _just_ "Webxdc" in the menu or in the title makes it pretty
unclear to the user what this is about.
same for the tab "Webxdc" on desktop or the default description in the summary.
otoh, calling it _only_ "Apps" (as now), may also raise false expectations
and may be mixed with "normal" apps.
so, "Webxdc App" seems to be a good approach.
there is also the term "Mini App" [^1], we could also go for that,
but this is a broader discussion as this would give up the term "Webxdc" partly.
in any case, if there is few space in the UI,
it seems to be okay to abbreviate with just "App" or "Apps" as needed,
if it is otherwise clear that the thing is a "Webxdc App" or "Mini App".
[^1]: the term "Mini App" is aleady known for similar types of apps
(some "small app" running in a "super app")
cmp. https://www.w3.org/TR/mini-app-white-paper/#what-is-miniapp .
of course, our "Webxdc Apps" are not compatible with other "Mini Apps"
however, this is also not the case between "Mini Apps" of other vendors
which also have different focuses.
so "Mini App" seems to be a broader term and does not imply compatibiliy.
* use term 'Private Apps' for webxdc content
* add some translator hints
Asiel Díaz Benítez