IssueTracker

Tagging with a review tag so that Jetpad picks it up

[LIBRARY_API_REVIEW_TAG:core/core/api/1.4.0-alpha01.txt]

"Please add."?

Oh, okay -- it's a feature request to add that method.

Handler.hasCallbacks was added in JB timeframe in https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/183519/1/core/java/android/os/Handler.java

It was marked as @hide, so technically we can use reflection on pre-29 versions to get to it. But what would we do ICS? Nothing?

And on ICS there is no underlying MessageQueue API to check for runnable callbacks. That was added as part of the same original CL at https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/183519/1/core/java/android/os/MessageQueue.java

Note that we didn't see a single internal or external request to actually expose this API in AndroidX in a backwards compatible way.

It would have to be RequiresApi(JELLY_BEAN), but if the @hide method was on the non-SDK-usage blacklist in P then we're out of luck.

Where do I find that blacklist?

You could either check the status manually by searching in a CSV (SDK 29) and TXT (SDK 28):

https://developer.android.com/distribute/best-practices/develop/restrictions-non-sdk-interfaces#determine-list

Or go ahead and write it and then pass the library through veridex:

https://developer.android.com/distribute/best-practices/develop/restrictions-non-sdk-interfaces#test-veridex-tool

It's light-greylist on SDK 28, so we should be able to reflect on SDK 16+.

Though if an OEM changed the implementation, we're going to have to throw an exception. It's unlikely, but it's there.

Still waiting on core to go back to alpha... This is waiting in aosp/1580773.

Hey all, we added text like this to the doc in two spots.

For backward compatibility with previous Android versions, equivalent APIs are also available in AndroidX. However, the backward compatible APIs work with the AppCompatActivity context, not the application context, for Android 12 (API level 32) and earlier. Access the backward compatible APIs with Appcompat 1.6.0 or higher.

I would suggest at least adding to the documentation about the attachBaseContext() required in Application.kt, Services, activities that do not extend AppCompatActivity, etc. And a suggested implementation or gist would be very useful too.

This documentation could be added beneath, or as part of Support Android 12 and lower.

Such as...

Application Context in Android 12 and lower

In order for application context to have the correct language resources, developers will need to handle attachBaseContext() in Application.kt, Services, activities that do not extend AppCompatActivity (TODO: Where else is this needed???). The following code snippet shows how this may be implemented:

    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(getContextForLanguage(base));
    }

    public static Context getContextForLanguage(Context context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) return context;

        String languageTag = PreferenceManager.getDefaultSharedPreferences(context).getString(PREF_APP_LANGUAGE_TAG, "");
        if (languageTag.isEmpty()) return context;

        Locale locale = Locale.forLanguageTag(languageTag);
        Locale.setDefault(locale);

        Resources resources = context.getResources();
        Configuration configuration = resources.getConfiguration();

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
            configuration.setLocales(new LocaleList(locale));
        } else {
            configuration.setLocale(locale);
        }

        return context.createConfigurationContext(configuration);
    }

I'm not sure if this is the best implementation, but it has worked very well for our app with ~5m downloads (and supported in 22 languages). I think many developers are avoiding adding an in-app language picker for Android 12 and under due to the amount of testing and lack of documentation that increases the risk trying to find the correct implementation.

Thanks!

I would also like to point out that when setting locale to Traditional Chinese for Android 6 (not tested on earlier Android versions from KitKat to Lollipop), the following codes do not work even for Activity Context: AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale.TRADITIONAL_CHINESE))

AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale.TAIWAN))

AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale("zh", "TW")))

AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale("zh_tw")))

The following works for Android 6: AppCompatDelegate.setApplicationLocales(LocaleListCompat.create(Locale("zh-tw")))

Hi chewwengchuen@gmail.com, thanks for reporting this issue. I logged a separate bug to keep this bug focused on using the backward compatible APIs with other contexts. New bug: https://buganizer.corp.google.com/issues/283028855

We added new API (ContextCompat#getContextForLanguage(Context)) in androidx core 1.11.0-beta01 for getting context that respect per-app locales.

Feel free to try it and let us know if there is any issue.

Here is the release note: https://developer.android.com/jetpack/androidx/releases/core#1.11.0-beta01

Thanks! I just tested this and works great... on a side-note Services also need this added in attachBaseContext() otherwise they can have the wrong context for notifications, strings, etc.

I didn't see any issues with upgrading users who have already selected a different language either - their context/strings looked correct with Application context 👍

One issue I've found with ContextCompat.getContextForLanguage() is that it doesn't update the default Locale - Locale.getDefault().

This can prove problematic in Application/Service classes, as well as it isn't inline with the other changes with language changes in AppCompatActivity or in API 33+, which both adjust the Locale.getDefault() to the users selected language.

I believe the default Locale should be updated similarly as done in AppCompatActivity/API 33+, no?

Hi,

Thanks for your feedback. I agree that adding Locale.getDefault() to ContextCompat.getContextForLanguage() would help some developers who are not aware that Locale is still not updated in other Android components. However, it doesn't make much sense from an API perspective. If someone just wants to get the context via ContextCompat.getContextForLanguage(), they may not be aware that an unrelated object (Locale) has also been changed. It looks fine in per-app locales cases for now, but we don't want someone to use this API to cause unexpected behavior someday. I think we can add some description in the docs to help other developers aware this so that app owners can add Locale.setDefault() themselves.

Good point, it doesn't make sense to set the default Locale in ContextCompat.getContextForLanguage(). When you update its docs can you state that the per-app locale can be retrieved with LocaleManagerCompat.getApplicationLocales() outside of activity context to set default Locale with?

Otherwise I think developers are going to try to use AppCompatDelegate.getApplicationLocales() and not know there's another similar API...

Thanks, I'll update it in the docs. If you want to set per-app locale to Locale after ContextCompat.getContextForLanguage(), you can consider getting per-app locale from Context, which returns from ContextCompat.getContextForLanguage() because its configuration already contains per-app locale and you can save one disk IO.

Right, using LocaleManagerCompat.getApplicationLocales() would lead to an extra disk IO.

So, basically an in-app implementation of this could be...

    Context updatedContext = ContextCompat.getContextForLanguage(initialContext);

    Locale updatedLocale = updatedContext.getResources().getConfiguration().locale; // using deprecated for example only

    // Avoid setting default locale needlessly
    if (!Locale.getDefault().equals(updatedLocale)) {
        Locale.setDefault(updatedLocale);
    }
        
    return updatedContext;

Thanks!

Using ContextCompat.getContextForLanguage(context) and setting the base context in the Application works great for the use case when the app is restarted. The problem we have is when we update the locale programmatically in the app with AppCompatDelegate. We are using the application context to retrieve strings across the whole app.

How can we make sure that this application context is using the app locale under the hood without restarting the whole application?

I just opened another issue for per-app languages (affects Android 12 and under too): https://issuetracker.google.com/issues/309393568

The current implementation of ContextCompat.getContextForLanguage(context) has some major issues that make it hard to recommend:

• Each call performs a blocking disk I/O call which impacts performance, because LocaleManagerCompat.getApplicationLocales(context) (used internally) performs a disk I/O. ContextCompat.getString(context, resId) suffers from the same issue because it calls ContextCompat.getContextForLanguage(context) internally.
• The documentation suggests to call it in Application's attachBaseContext(), in which case a single I/O call would be acceptable. However, if the selected language is updated while the application is open, the Application context language will not be updated, so this technique doesn't work properly.

I suggest to implement some synchronized caching mechanism in AppLocalesStorageHelper, similar to what AppCompatDelegate does. This way, there should only be a single blocking disk I/O during the first call to ContextCompat.getContextForLanguage(context), and it can then be called repeatedly everywhere an Activity Context is not available.

The documentation should also be updated to mention the big limitation of calling ContextCompat.getContextForLanguage(context) in Application's attachBaseContext().

As a workaround, I reimplemented ContextCompat.getContextForLanguage(context) to use a cache internally that I also update when calling AppCompatDelegate.setApplicationLocales(), but since that cache is not synchronized with AppCompatDelegate's cache I get 2 blocking I/O reads in total.

Any updates on issue described in the comment above?