The first developer preview of Android 14

Making Android work well for each of the billions of Android users is a collaborative process between us, the Android hardware manufacturers, and you, our developer community.

On February 8, Android released the first developer preview of Android 14. Your feedback in these previews is a key part of making Android better for everyone. Android 14 continues to focus on improving developer productivity while enhancing performance, privacy, security, and user customization. This preview is just the beginning, and we'll share more as the release cycle progresses.

Android continues to deliver enhancements and new features throughout the year, and your feedback on the Android 14 Developer Preview and Quarterly Platform Release (QPR) beta program plays a key role in helping Android continue to improve. The Android 14 developer site provides more information about the preview, including download and release schedules for Pixel. We look forward to hearing your thoughts, and thank you in advance for your continued help in making Android a platform that works for everyone.

Works across devices and form factors

Android 14 builds on the work done in Android 12L and 13 to support tablet and foldable form factors. To help you build apps that adapt to different screen sizes, we created window size classes, sliding pane layouts, activity embeds, and boxes with constraints, all of which are supported in Jetpack Compose. With each release, our goal is to make it easier for you to optimize your apps on all Android platforms.

To help simplify your app preparation, we’ve updated our app quality guidelines for large screens and provided more learning opportunities about building for large screens and foldable devices. The Large Screen Gallery contains proven design patterns and design inspiration around the markets your app supports, such as social and communication, media, productivity, shopping, and reading apps.

Multi-device experiences are an important part of the future of Android. You can get started today with the cross-device SDK preview, enabling you to build rich experiences that work intuitively across different devices and form factors, with more to come.

Simplify back-office work

Android 14 continues its efforts to optimize how apps work together, improve system health and battery life, and improve the end-user experience.

JobScheduler and foreground service updates and additions

Performing some background work is more complex than necessary, such as downloading large files when WiFi is available. We’re creating a standard path for this work to simplify your app development and potentially improve the user experience. We’re also being more opinionated about how we use foreground services, reserving them only for the highest priority user-facing tasks so that Android can improve resource consumption and battery life.

In Android 14, we're making changes to existing Android APIs (Foreground Services and JobScheduler), including adding new capabilities for user-initiated data transfers, and updated requirements for declaring a foreground service type. User-initiated data transfer jobs will make it easier to manage user-initiated downloads and uploads, especially when they need to be restricted, such as downloading only on Wi-Fi. The requirement to declare a foreground service type allows you to clearly define your app's intent for background work, while making it clear which use cases are appropriate for foreground services. Additionally, Google Play will be rolling out new policies to ensure appropriate use of these APIs, with more details coming soon.

Optimize broadcasting

We've made several optimizations to the internal broadcast system to improve battery life and responsiveness. While most of the optimizations are internal to Android and won't affect your app, we have adjusted how context registration broadcasts are received after your app enters the cached state. Broadcasts to context-registered receivers may be queued and delivered to the app only after it leaves the cached state. Additionally, some repeating context registration broadcasts, such as BATTERY_CHANGED, may be coalesced into one final broadcast before delivery once the app leaves the cached state.

Accurate alarm

Invoking exact alarms can significantly impact device resources, such as battery life. So in Android 14, newly installed non-clock or calendar apps targeting Android 13+ (SDK 33+) must request that the user grant them the SCHEDULE_EXACT_ALARM special permission before they can set an exact alarm. Apps can direct users to a settings page via an intent to toggle this permission, but we encourage you to evaluate your use cases and choose more flexible scheduling alternatives whenever possible.

Clock and calendar apps targeting Android 13+ (SDK 33+) that rely on accurate alarms as part of their core app workflow will be able to declare the USE_EXACT_ALARM general permission (granted at install time) instead. Apps will not be able to publish versions of their apps to the Play Store using this permission in the manifest unless they comply with the policy language.

Customization

We will continue to ensure Android users can tailor their experience to their individual needs, including enhanced accessibility and internationalization features.

Larger fonts with non-linear scaling

Starting with Android 14, users will be able to enlarge fonts up to 200%. Previously, the maximum font size ratio on Pixel devices was 130%.

To alleviate the problem of overly large text, starting with Android 14, the system automatically applies a non-linear font scaling curve. This ensures that text that is already large does not increase at the same rate as smaller text.

In Android 14, you should test your app UI at maximum font size using the Font size option in Accessibility > Display size and text settings. Make sure that the adjusted large text size setting is reflected in the UI and doesn't cause text to be truncated. Our documentation has more on best practices.

Language preference per application

You can use LocaleManager.setOverrideLocaleConfig to dynamically update your app's localeConfig to customize the set of languages ​​that appear in the per-app language list in Android Settings. This allows you to customize the language list per region, run A/B experiments, and deliver updated locales if your app uses server-side localization push.

IME can now use LocaleManager.getApplicationLocales to understand the UI language of the current application to update the keyboard language.

Syntax Inflection API

The Grammatical Infection API allows you to more easily add support for users of languages ​​with grammatical genders. For example,

M: “You subscribed to…”

Woman: “You subscribed to…”

Neutral: "Subscription... is enabled"

Grammatical gender is intrinsic to the language and not easily resolved in some non-English languages. This new API reduces the work of supporting viewer gender (who is viewing the UI; not who is being talked about) compared to SelectFormat in ICU which had to be applied on a per-string basis.

To display personalized translations, you just need to add inflected translations for each grammatical gender of the affected languages ​​and integrate the API.

Privacy and Security

Runtime Receiver

Apps targeting Android 14 must indicate whether uses of dynamic Context.registerReceiver() should be considered "exported" or "unexported", a continuation of manifest-level work from previous versions.

Safer implicit intent

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents to unspecified packages internally.

Safer dynamic code loading

Dynamic code loading (DCL) introduces an exit point for malware and exploits because dynamically downloaded executables can be unexpectedly manipulated, leading to code injection. Apps targeting Android 14 are required to mark dynamically loaded files as read-only.

Block installation of applications

Malware often targets older API levels to bypass security and privacy protections introduced in newer Android versions. To prevent this, starting with Android 14, apps with a targetSdkVersion lower than 23 will not be installed. This specific version was chosen because some malware apps use targetSdkVersion 22 to avoid being constrained by the runtime permissions model introduced in 2015 with Android 6.0 (API level 23).

On devices upgraded to Android 14, any apps with a targetSdkVersion lower than 23 will remain installed.

You can test your app against older API levels using the following ADB commands:

adb install --bypass-low-target-sdk-block filename.apk

Credential Manager and Key Support

We recently released an alpha version of Credential Manager, a new Jetpack API that lets you simplify the authentication process for your users, while also improving security with support for keys . Keys are a more secure alternative to passwords and other phisable authentication factors, and are more convenient for users (they only require a biometric swipe to log in securely on any device).

App Compatibility

We're working to make updates faster and smoother with each platform version by prioritizing app compatibility. In Android 14, we've made most app-facing changes opt-in to give you more time to make any necessary app changes, and we've updated our tools and processes to help you get ready faster.

OpenJDK 17 support - This preview includes access to 300 OpenJDK 17 classes. We are working to fully enable Java 17 language features in upcoming developer previews. These include record classes, multiline strings, and pattern matching instanceof. Thanks to Google Play system updates (Project Mainline), more than 600 million devices are able to receive the latest Android Runtime (ART) update containing these changes. This is part of our commitment to provide a more consistent and secure environment for apps across devices, and to provide users with new features and functionality independent of platform versions.

Easier testing and debugging of changes - To make it easier for you to test opt-in changes that may affect your apps, we are making many of these changes toggleable again this year. With the toggle, you can force-enable or disable changes individually from Developer Options or adb.

App compatibility toggle in Developer Options

Platform Stability Milestone - As with last year, we're letting you know about our platform stability milestones in advance to give you more time to plan your app compatibility work. At this milestone, we'll deliver final SDK/NDK APIs as well as final internal APIs and system behaviors for apps. We expect to reach platform stability in June 2023, and from then on you'll have a few weeks to do final testing before the official release.

Get started with Android 14

The Developer Preview includes everything you need to try Android 14 features, test your apps, and give us feedback. To test your apps with tablets and foldable devices, the easiest way to get started is to use the Android Emulator in a tablet or foldable configuration in the latest preview of the Android Studio SDK Manager. For phones, you can get started right away with a system image on a Pixel 7 Pro, Pixel 7, Pixel 6a, Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, or Pixel 4a (5G) device. If you don't have a Pixel device, you can use a 64-bit system image with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest Android Studio Giraffe preview (or the newer Giraffe+ version). Once you're set up, you should do the following:

Try out new features and APIs - In the early stages of developer preview, your feedback is critical. Report issues in our tracker on the feedback page.

Test your current apps for compatibility—Find out if your app is affected by default behavior changes in Android 14; install your app on a device or emulator running Android 14 and test it extensively.

Test your app with opt-in changes - Android 14 has opt-in behavior changes that affect your app only when it targets the new platform. It's important to understand and evaluate these changes early. To make testing easier, you can turn changes on and off individually.

We'll be updating the preview system images and SDK regularly throughout the Android 14 release cycle. This initial preview is for developer use only and isn't intended for everyday or consumer use, so we're making it available via manual download only. After you manually install the preview build, you'll automatically get future updates over-the-air for all later preview and beta builds. Read more here.

If you plan to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and do not want to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise, you may encounter a time period when the build date of Android 13 Beta is updated, which will prevent you from moving directly to Android 14 Developer Preview without performing a data wipe.

We'll also invite consumers to try Android 14 when we release the beta, and we'll open registration for the Android Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

Posted by Dave Burke, VP of Engineering

Source: https://android-developers.googleblog.com/2023/02/first-developer-preview-android14.html