Welcome to the Android 14 Developer Preview! Please give us your feedback, and help us make Android 14 the best release yet.

Features and APIs Overview

Stay organized with collections Save and categorize content based on your preferences.

Android 14 introduces great new features and APIs for developers. The sections below help you learn about features for your apps and get started with the related APIs.

For a detailed list of new, modified, and removed APIs, read the API diff report. For details on new APIs visit the Android API reference — new APIs are highlighted for visibility. Also, to learn about areas where platform changes may affect your apps, be sure to check out Android 14 behavior changes for apps that target Android 14 and for all apps.

Internationalization

Per-app language preferences

Android 14 expands on the per-app language features that were introduced in Android 13 (API level 33) with these additional capabilities:

  • Dynamic updates for an app's localeConfig: Use the setOverrideLocaleConfig() and getOverrideLocaleConfig() methods in LocaleManager to dynamically update your app's list of supported languages in the device's system settings. Use this flexibility to customize the list of supported languages per region, run A/B experiments, or provide an updated list of locales if your app utilizes server-side pushes for localization.

  • App language visibility for input method editors (IMEs): IMEs can utilize the getApplicationLocales() method to check the language of the current app and match the IME language to that language.

Grammatical Inflection API

The Grammatical Inflection API allows you to more easily add support for users who speak languages where grammatical gender changes the sentence based on the person being addressed, providing a more personalized and natural-sounding user experience for those languages.

Example of inflection for grammatical gender

Grammatical gender is integral to some languages and can't be easily worked around like in English. For example, in English to write a message telling the user that they are subscribed to your app's service, you could use a single phrase: "You are subscribed to...".

To provide a similar phrase in French, there are a few options:

  • Masculine-inflected form: "Vous êtes abonné à..." (English: "You are subscribed to...")
  • Feminine-inflected form: "Vous êtes abonnée à…" (English: "You are subscribed to...")
  • Neutral phrasing that avoids inflection: "Abonnement à…activé" (English: "Subscription to ... enabled")

Similar to English, the first two options address the user directly. However, without any mechanism to accommodate this grammatical feature of French, you would only have the third option, which changes the tone of the message and might not be what you want to display in your user interface.

In these cases, the Grammatical Inflection API lowers the effort to display strings relative to the viewer's grammatical gender—that is, the person who's viewing the UI, not who's being talked about. To show users personalized translations in your app, add translations that are inflected for each grammatical gender for affected languages and then use the GrammaticalInflectionManager API to adjust which translations are shown to each user.

Previously, to add similiar support, you would need to use the SelectFormat API from the International Components for Unicode (ICU), which must be applied on a per-string basis.

Add translations for languages with grammatical gender

To provide localized text for languages with grammatical gender, create an alternative resources file and append the grammatical gender qualifer immediately after the locale name for those languages. The following table outlines the possible values:

Qualifier String value Example (French fr)
Feminine feminine res/values-fr-feminine/strings.xml
Masculine masculine res/values-fr-masculine/strings.xml
Neuter neuter res/values-fr-neuter/strings.xml

You should only include strings that support grammatical gender inflections in these resources files. Include other strings in the default resource file that contains other localized strings and the default translation will be shown whenever a grammatical-gendered version is not available. In the example provided for French earlier, the neutral phrasing would be the value of the string in the default resources res/values-fr/strings.xml file.

Regional preferences

Regional preferences enable users to personalize temperature units, the first day of the week, and numbering systems. A European living in the United States might prefer temperature units to be in Celsius rather than Fahrenheit and for apps to treat Monday as the beginning of the week instead of the US default of Sunday.

New Android Settings menus for these preferences provide users with a discoverable and centralized location to change app preferences. These preferences also persist through backup and restore. Several APIs and intents—such as getTemperatureUnit and getFirstDayOfWeek— grant your app read access to user preferences, so your app can adjust how it displays information. You can also register a BroadcastReceiver on ACTION_LOCALE_CHANGED to handle locale configuration changes when regional preferences change.

To find these settings, open the Settings app and navigate to System > Languages & input > Regional preferences.

Regional preferences screen in Android system settings

Temperature options for regional preferences in Android system settings

Accessibility

Non-linear font scaling to 200%

Starting in Android 14, the system supports font scaling up to 200%, providing low-vision users with additional accessibility options that align with Web Content Accessibility Guidelines (WCAG).

To prevent large text elements on screen from scaling too large, the system applies a non-linear scaling curve. This scaling strategy means that large text doesn't scale at the same rate as smaller text. Non-linear font scaling helps preserve the proportional hierachy between elements of different sizes while mitigating issues with linear text scaling at high degrees (such as text being cut off or text that becomes harder to read due to an extremely large display sizes).

Test your app with non-linear font scaling

Enable the maximum font size in a device's accessibility settings to test your app.

If you already use scaled pixels (sp) units to define text sizing, then these additional options and scaling improvements will be applied automaticaly to the text in your app. However, you should still perform UI testing with the maximum font size enabled (200%) to ensure that your app applies the font sizes correctly and can accommodate larger font sizes without impacting usability.

To enable 200% font size, follow these steps:

  1. Open the Settings app and navigate to Accessibility > Display size and text.
  2. For the Font size option, tap the plus (+) icon until the maximum font size setting is enabled, as shown in the image that accompanies this section.

Use scaled pixel (sp) units for text-sizes

Remember to always specify text sizes in sp units. When your app uses sp units, Android can apply the the user's preferred text size and scale it appropriately.

Do not use sp units for padding or view heights: with non-linear font scaling sp dimensions might not be proportional, so 4sp + 20sp might not equal 24sp.

Convert scaled pixel (sp) units

Use TypedValue.applyDimension() to convert from sp units to pixels, and use TypedValue.deriveDimension() to convert pixels to sp. These methods apply the appropriate non-linear scaling curve automatically.

Avoid hardcoding equations using Configuration.fontScale or DisplayMetrics.scaledDensity. Because font scaling is now non-linear, these fields are no longer accurate.

User experience

Improvements for app stores

Android 14 introduces several new PackageInstaller APIs that allow app stores to improve their user experience.

Request install approval before downloading

Installing or updating an app may require user approval. For example, when an installer making use of the REQUEST_INSTALL_PACKAGES permission attempts to install a new app. In prior Android versions, app stores can only request user approval after APKs are written to the install session and the session is committed.

Starting with Android 14, the requestUserPreapproval() method lets installers request user approval before committing the install session. This improvement lets an app store defer downloading any APKs until after the installation has been approved by the user. Furthermore, once a user has approved installation, the app store can download and install the app in the background without interrupting the user.

Claim responsibility for future updates

The new setRequestUpdateOwnership() method allows an installer to indicate to the system that it intends to be responsible for future updates to an app it is installing. This capability enables update ownership enforcement, meaning that only the update owner is permitted to install automatic updates to the app. Update ownership enforcement helps to ensure that users receive updates only from the expected app store.

Any other installer, including those making use of the INSTALL_PACKAGES permission, must receive explicit user approval in order to install an update. If a user decides to proceed with an update from another source, update ownership is lost.

Update apps at less-disruptive times

App stores typically want to avoid updating an app that is actively in use because this leads to the app's running processes being killed, which potentially interrupts what the user was doing.

Starting with Android 14, the InstallConstraints API gives installers a way to ensure that their app updates happen at an opportune moment. For example, an app store can call the commitSessionAfterInstallConstraintsAreMet() method to make sure that an update is only committed when the user is no longer interacting with the app in question.

Seamlessly install optional splits

With split APKs, features of an app can be delivered in separate APK files, rather than as a monolithic APK. Split APKs allow app stores to optimize the delivery of different app components. For example, app stores might optimize based on the properties of the target device. The PackageInstaller API has supported splits since its introduction in API level 22.

In Android 14, the setDontKillApp() method allows an installer to indicate that the app's running processes shouldn't be killed when new splits are installed. App stores can use this feature to seamlessly install new features of an app while the user is using the app.

Detect when users take device screenshots

To create a more standardized experience for detecting screenshots, Android 14 introduces a privacy-preserving screenshot detection API. This API lets apps register callbacks on a per-activity basis. These callbacks are invoked, and the user is notified, when the user takes a screenshot while that activity is visible.