Status Update
Comments
au...@google.com <au...@google.com> #2
ch...@google.com <ch...@google.com> #3
ch...@google.com <ch...@google.com> #4
Can someone clarify?
yb...@google.com <yb...@google.com> #5
AppCompatDelegate generally works at the Activity level. This is the case with other features such as NightMode as well. This is why it is intended that it does not affect the application context.
I'm re-assigning this to the team to assess the feasibility of extending the feature to alter the application context.
ki...@google.com <ki...@google.com> #6
ki...@google.com <ki...@google.com> #7
We recently added a language picker to our alarm app with ~5M downloads. We were enthused when we heard of Android 13's per-app language capabilities and back-porting.
However, in practice this is a half-baked pre-Android 13 implementation. Anyone who implements it is going to have to handle attachBaseContext()
in the Application.kt, Services, and any activity that doesn't extend AppCompatActivity.
If no changes are made, I would at least suggest adding to the attachBaseContext()
for pre-Android 13, and suggested implementation for it - please don't make 1000s of developers write this code :)
Thanks!
ki...@google.com <ki...@google.com> #8
It is common use case, to be able to get string from application context besides activity & fragment. If pre-13 unable exhibit same behavior as 13 (able to get localized string from application context), then AppCompatDelegate.setApplicationLocales doesn't solve the backward compatible issue.
Due to this limitation, we can only provide such a dynamic language feature, for Android 13 only.
yb...@google.com <yb...@google.com> #9
Hacked
ap...@google.com <ap...@google.com> #10
I call AppCompatDelegate.setApplicationLocales, but the strings are still in the device locales in all the cases I get the strings outside a fragment or activity.
On Android 13 it works well.
I noticed that when I get the strings by the activity's context, it works well, so why is not the application context updated on Android 12 and below like on Android 13+?
ap...@google.com <ap...@google.com> #11
ki...@google.com <ki...@google.com>
al...@google.com <al...@google.com> #12
al...@google.com <al...@google.com> #13
This also causes Intent.ACTION_LOCALE_CHANGED not being received
al...@google.com <al...@google.com> #14
Same problem. AppCompatDelegate implementation is broken, when you want to use it outside an activity.
There is no way to use AppCompatDelegate.setApplicationLocales
and AppCompatDelegate.getApplicationLocales
, when the Activity is not running. E.g from Application class, content provider, broadcast receiver, etc. These two calls are tightly bounded with the activity in compat code.
If you use custom localization library, you usually initialize it in Application class. But in Application class you can't retrieve currently set application locale on a pre-13 devices. AppCompatDelegate.getApplicationLocales
here returns empty locale list.
Also migration from custom locale storage to AppCompatDelegate
storage works only when the Activity
is running. This must be possible to do before starting the Activity
to prevent Activity recreation during migration.
ap...@google.com <ap...@google.com> #15
Any update on this issue?
I must say that this API and its documentation is so misleading for at least two reasons. First, because AppCompatDelegate.setApplicationLocales
naming makes you think that this will update the application context on all Android versions, and in fact it does it only on the last one out of 13. Second, for the fact that this issue is no where mentioned in any related documentation.
Good luck to all the devs that will learn or have learned this the hard way, like myself.
Either give us an option to not have to resort to workarounds like this
Description
AsyncTask is now deprecated in Android R and there are several usages in AndroidX. This is a tracking to migrate or suppress them.