Android Developers Blog

Per-App Language Preferences - Part 1

22 November 2022

Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)

What if you have a set of users who are quite fluent in English, Hindi, and Spanish, and they have a news app on their phones and prefer to read the news in Hindi? For their texting app, they prefer Spanish as they have some friends and family who they text with in Spanish. But for ease of access, they still prefer their device to be in English. Now there are many such use-cases where the users might want their app languages to be different from their system language. Interesting! Starting with Android 13, we have included one of the most-requested features from users, Per-App Language Preferences. It lets users switch app languages from System settings, providing users with better control over their language choices for different apps, irrespective of the system language.

A cellphone screen displaying App language preferences in system settings for the YouTube app

Build for your multilingual users This blog focuses on how to integrate the Per-App Language Preferences API in your app to provide your users the flexibility to choose different languages for different apps.1. Users can change the language settings from system settings by selecting: Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]

NOTE: Only those apps that have opted in for the feature by specifying the locale_config.xml file (more on this below), will appear in system settings.

A cellphone screen demonstrating finding the language settings from system settings by selecting Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]

2. If your app already has an in-app language picker, you can integrate the Per-App Language Preferences API to leverage the full platform support. For pre-Android 13 users, the system settings won’t be visible, but developers can still provide an in-app language picker.

A cellphone screen demonstrating integrating the Per-App Language prefences API for an app which already has an in-app language picker

How to integrate this feature in your app?

There are 5 steps that need to be followed while working on the Per-App Language Preferences feature, listed here →

1. Create locale_config.xml file

Create a new file in values/xml/ directory and name it as locale_config.xml. This file should contain a list of all the locales that are supported by the app. The list element should be a string containing a locale tag.

NOTE: The locale tags must follow the BCP47 syntax, which is usually {language subtag}–{script subtag}–{country subtag}. Anything other than that will be filtered out by the system and won't be visible in the system settings.

locale_config.xml

<?xml version="1.0" encoding="utf-8"?>
<locale-config xmlns:android="http://schemas.android.com/apk/res/android">
...

<locale android:name="en"/>

<locale android:name="ja-JP"/>

<locale android:name="zh-Hans-MO"/>

<locale android:name="zh-Hant-TW"/>
...
</locale-config>

2. Add the locale_config in the AndroidManifest.xml
locale_config.xmlAndroidManifest.xml
AndroidManifest.xml

3. Add the libraries

Use the latest version of AppCompat Library

build.gradle (app)

def latestAppCompatVersion = “1.6.0-rc01”

dependencies {
...
implementation "androidx.appcompat:appcompat:$latestAppCompatVersion"
implementation "androidx.appcompat:appcompat-resources:$latestAppCompatVersion"
...
}

4. Use AndroidX APIs

Use the APIs in your code to set and get the app locales.

MainActivity.kt

val appLocale: LocaleListCompat = LocaleListCompat.forLanguageTags("xx-YY")

// Call this on the main thread as it may require Activity.restart()
AppCompatDelegate.setApplicationLocales(appLocale)

// Call this to get the selected locale and display it in your App
val selectedLocale = AppCompatDelegate.getApplicationLocales()[0]

NOTE: These APIs are also backward compatible, so even if the app is being used on Android 12 or lower, the APIs would still behave the same, and no additional checks for OS versions are required in your code.

5. Delegate storage to AndroidX

Let AndroidX handle the locale storage so that the user's preference persists.

AndroidManifest.xml

Steps 3, 4, & 5 above demonstrate the minimum components needed to create an in-app language picker.

And with this, your app can now support locale switching.

Additional things to take care of while migrating to the API

Earlier, developers had to handle the user's preferences on their own, either by using SharedPreferences, storing the data on a server, or other app logic. With the new APIs, there is no need to handle this separately. So when you are using these APIs, AndroidX is already taking care of the storage part, but what happens when the app is opened for the first time after a user updates their device to Android 13 or higher?

In this case, the system won’t be aware of the user’s preferences for the app language and thus it will map the app to the default system language. To avoid this, developers need to add some one-time migration logic so that their users don’t have to set the language again when they update the app.

// Specify the constants to be used in the below code snippets

companion object {

// Constants for SharedPreference File
const val PREFERENCE_NAME = "shared_preference"
const val PREFERENCE_MODE = Context.MODE_PRIVATE

// Constants for SharedPreference Keys
const val FIRST_TIME_MIGRATION = "first_time_migration"
const val SELECTED_LANGUAGE = "selected_language"

// Constants for SharedPreference Values
const val STATUS_DONE = "status_done"
}

// Utility method to put a string in a SharedPreference
private fun putString(key: String, value: String) {
val editor = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE).edit()
editor.putString(key, value)
editor.apply()
}

// Utility method to get a string from a SharedPreference
private fun getString(key: String): String? {
val preference = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE)
return preference.getString(key, null)
}

// Check if the migration has already been done or not
if (getString(FIRST_TIME_MIGRATION) != STATUS_DONE) {

   // Fetch the selected language from wherever it was stored. In this case it’s SharedPref
   // In this case let’s assume that it was stored in a key named SELECTED_LANGUAGE
getString(SELECTED_LANGUAGE)?.let { it →

      // Set this locale using the AndroidX library that will handle the storage itself
val localeList = LocaleListCompat.forLanguageTags(it)
AppCompatDelegate.setApplicationLocales(localeList)

      // Set the migration flag to ensure that this is executed only once
putString(FIRST_TIME_MIGRATION, STATUS_DONE)
}
}

What flexibility does the feature provide to the users and developers?

Here are a few things that might prove to be beneficial for you users.

All devices running Android 13 or higher will have a common place for users to discover and change the language of their apps.
Although the system settings are limited to the devices running Android 13 or higher, the AndroidX APIs are backwards compatible. Thus, there is no requirement to add OS Version checks in your code while building for your multilingual users.
Developers do not need to handle configuration changes separately or worry about storing the user's selected language every time. The API handles configuration changes and stores the language preferences for you.
Works with other Android features like Backup and restore. If a user switches to a new device and restores the previously backed up data, your app will retain the user’s last preferred language, thus providing your users with a better and more seamless experience.

Recap

With that, most parts of the feature are covered. So let’s have a quick recap on what we discussed in today’s read.

A quick read on what Per-App Language Preferences offer to multilingual users and app developers.
What end users will see on their devices.
How to migrate your app to the Per-App Language Preferences APIs.
A few things that need to be taken care of while migrating to the APIs to ensure a better user experience.
Lastly, the benefits that end users and developers can leverage from this feature.

References

App Bundles for Google TV and Android TV

21 November 2022

Posted by Josh Wentz, Product Management, Google TV

TLDR: Google TV and Android TV will be requiring Android App Bundles that are archivable starting in May 2023 to save storage for users. Over the past few decades, TV has transformed from linear channel surfing to on-demand content with multi-app experiences. Today, over 10,000 apps are available on Android TV OS. While software has grown exponentially, TV hardware has remained limited in capacity compared to its phone counterparts. In 2022, smartphones often have a minimum storage size of 64GB, but smart TVs have an average of just 8GB. Less storage results in users having to uninstall apps, hindering their overall TV experience. To help with this problem and others, Android introduced App Bundles in Nov 2020.
What are Android App Bundles? “Android App Bundles” (AABs) are the standard publishing format on Google Play (phones, tablets, TVs, etc) that have replaced “Android Package Kits” (APKs). App Bundles are smaller, faster, fresher, and better than its precursor. Key benefits include:

Smaller Download/Storage Size - App Bundles create an average of 20% total size savings compared to its equivalent APK counterpart by optimizing for each device.

Less Likely to Uninstall - Since App Bundles enables users with the option to archive (which reclaims ~60% of app storage), users can keep these and more apps on their TV despite limited storage. A quick archive/unarchive user interface is built-in to the TV. Developers can also maintain state for a frictionless later return.

Applicable to All Android Surfaces - App Bundles are helpful for all Android surfaces using the Google Play store including TV, phone, tablet, watch, auto, & more.

Streamlined Delivery & Security - For easier delivery, a single artifact with all of your app's code & resources allows Play store to dynamically serve an optimized app for each device configuration. For greater security, developers can also reset the upload key if it’s lost or compromised.

What is new for TV? With TV storage confined and users having an increasing appetite for more apps, Google TV and Android TV will be requiring App Bundles starting in May 2023. While this provides about 6-months to transition, we estimate that in most cases it will take one engineer about 3-days to migrate an existing TV app from Android Package Kit (APK) to Android App Bundle (AAB). While developers can configure archiving for their mobile apps, TV apps are required to be archivable so that all users and developers can benefit on storage-constrained TVs. For TV apps not transitioned in time, Google may hide such apps from the TV surface. If you’re working on a brand new TV app, be sure to use Android App Bundles from the start!
How can TV apps transition? Visit our Developer Guide to learn more about how to migrate to an Android App Bundle (AAB).

Explore the AAB format, find steps to build & test an AAB, and see FAQ. This example and video may help as well.

App Bundles are fully supported for Android 5.0 (API Level 21) and above. Certain App Bundle features are not compatible for Android versions before Android 5.0 (Lollipop).

Many TV apps have been developed with Android 5.0 (API Level 21) or higher. For context, Google TV launched on Android 10 (API Level 29) in 2020.

All told, App Bundles bring a delightful experience to both you as developers and your users, especially in the living room. Thank you for your partnership in creating immersive content and entertainment experiences for the future of TV.

Introducing Camera Viewfinder

21 November 2022

Posted by Francesco Romano, Developer Relations Engineer, Android

Over the years, Android devices have evolved to include a variety of sizes, shapes, and displays, among other features. Since the beginning, however, taking pictures with your phone has been one of the most important use cases. Today, camera capabilities are still one of the top reasons consumers purchase a phone. As a developer, you want to leverage camera capabilities in your app, so you decide to adopt the Android Camera Framework. The first use case you want to implement is the Preview use case, which shows the output of the camera sensor on the screen. So you go ahead and create a CaptureSession using a surface as big as the screen size. As long as the screen has the same aspect ratio as the camera sensor output and the device stays in its natural portrait orientation, everything should be fine. But what happens when you resize the window, unfold your device, or change the display or orientation? Well, in most cases, the preview may appear stretched, upside down, or incorrectly rotated. And if you are in a multi-window environment, your app may even crash. Why does this happen? Because of the implicit assumptions you made while creating the CaptureSession. Historically, your app could live in the same window for its whole life cycle, but with the availability of new form factors such as foldable devices, and new display modes such as multi-window and multi-display, you can't assume this will be true anymore. In particular, let's see some of the most important considerations when developing an app targeting various form factors: Let's examine some common pitfalls to avoid when developing an app targeting various form factors:

Don't assume your app will live in a portrait-shaped window. Requesting a fixed orientation is still supported in Android 13, but now device manufacturers may have the option of overriding an app request for a preferred orientation.

Don't assume any fixed dimension or aspect ratio for your app. Even if you set resizableActivity = "false", your app could still be used in multi-window mode on large screens (>=600dp).

Don't assume a fixed relationship between the orientation of the screen and the camera. The Android Compatibility Definition Document specifies that a camera image sensor "MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension." Starting with API level 32, camera clients that query the orientation on foldable devices can receive a value that dynamically changes depending on the device/fold state.

Don't assume the size of the inset can't change. The new taskbar is reported to applications as an inset, and when used with gesture navigation, the taskbar can be hidden and shown dynamically.

Don't assume your app has exclusive access to the camera. While your app is in a multi-window state, other apps can obtain access to shared resources like camera and microphone.

While CameraX already handles most of the cases above, implementing a preview that works in different scenarios with Camera2 APIs can be complex, as we describe in the Support resizable surfaces in your camera app Codelab. Wouldn’t it be great to have a simple component that takes care of those details and lets you focus on your specific app logic? Say no more… Introducing CameraViewfinder CameraViewfinder is a new artifact from the Jetpack library that allows you to quickly implement camera previews with minimal effort. It internally uses either a TextureView or SurfaceView to display the camera feed, and applies the required transformations on them to correctly display the viewfinder. This involves correcting their aspect ratio, scale, and rotation. It is fully compatible with your existing Camera2 codebase and continuously tested on several devices. Let’s see how to use it. First, add the dependency in your app-level build.gradle file:

implementation "androidx.camera:camera-viewfinder:1.3.0-alpha01"

Sync your project. Now you should be able to directly use the CameraViewfinder as any other View. For example, you can add it to your layout file:

<androidx.camera.viewfinder.CameraViewfinder
android:id="@+id/view_finder"
app:scaleType="fitCenter"
app:implementationMode="performance"
android:layout_width="match_parent"
android:layout_height="match_parent"/>

As you can see, CameraViewfinder has the same controls available on PreviewView, so you can choose different Implementation modes and scaling types. Now that the component is part of the layout, you can still create a CameraCaptureSession, but instead of providing a TextureView or SurfaceView as target surfaces, use the result of requestSurfaceAsync().

fun startCamera(){
val previewResolution = Size(width, height)
val viewfinderSurfaceRequest =
ViewfinderSurfaceRequest(previewResolution, characteristics)
val surfaceListenableFuture =
cameraViewfinder.requestSurfaceAsync(viewfinderSurfaceRequest)

Futures.addCallback(surfaceListenableFuture, object : FutureCallback<Surface> {
override fun onSuccess(surface: Surface) {
//create a CaptureSession using this surface as usual
}
override fun onFailure(t: Throwable) { /* something went wrong */}
}, ContextCompat.getMainExecutor(context))
}

Bonus: optimized layouts for foldable devices

CameraViewFinder is ready-to-use across resizable surfaces, configuration changes, rotations, and multi-window modes, and it has been tested on many foldable devices.

But if you want to implement optimized layouts for foldable and dual screen devices, you can combine CameraViewFinder with the Jetpack WindowManager library to provide unique experiences for your users.

For example, you can choose to avoid showing full screen preview if there is a hinge in the middle of the screen, or if the device is in “book” or “tabletop” mode. In those scenarios, you can have the viewfinder in one portion of the screen and the controls on the other side, or you can use part of the screen to show the last pictures taken. Imagination is the limit!

The sample app is already optimized for foldable devices and you can find the code to handle posture changes here. Have a look!

Per-App Language Preferences - Part 1

App Bundles for Google TV and Android TV

Introducing Camera Viewfinder

Labels

Archive

Feed

Newsletter