Tag Archives: Developer Preview

Android 14 Beta 5

Posted by Dave Burke, VP of Engineering
Android 14 logo

With the official release of Android 14 only weeks away, today we're bringing you Beta 5, the last scheduled update in our Android 14 beta program. It's the last chance to make sure your apps are ready and provide feedback before non-beta users start getting Android 14. To enable you to test your applications on devices spanning multiple form factors, Beta 5 is available for Pixel Tablet and Pixel Fold, in addition to the rest of the supported Pixel family and the Android emulator.

What's in Beta 5?

Beta 5 is our third Platform Stable Android 14 release, which means that the developer APIs and all app-facing behaviors are final for you to review and integrate into your apps, and you can publish apps on Google Play targeting Android 14's SDK version 34. It includes the latest fixes and optimizations, giving you everything you need to complete your testing.

Image of timeline showing Android 14 release is on schedule with Platform Stability testing happening in August

Get your apps, libraries, tools, and game engines ready!

The official Android 14 release is just weeks ahead, so please finish your final compatibility testing and publish any necessary updates to ensure a smooth app experience ahead of the final release of Android 14.

If you develop an SDK, library, tool, or game engine, it's even more important to release any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please make sure to let your developers know if updates are needed to fully support Android 14.

Testing your app involves installing your production app onto a device running Android 14 Beta 5; you can use Google Play or other means. Work through all the app's flows and look for functional or UI issues. Review the behavior changes to focus your testing. Each release of Android contains changes to the platform that improve privacy, security, and the overall user experience, and these changes can affect your apps. Here are some top changes to test:

Remember to exercise libraries and SDKs that your app is using in your compatibility testing. You may need to update to current SDK versions or reach out to the developer for help.

Once you’ve published the compatible version of your current app, you can start the process to update your app's targetSdkVersion. Review the behavior changes that apply when your app targets Android 14 and use the compatibility framework to help detect issues quickly.

Get started with Android 14

Today's Beta 5 release has everything you need to try Android 14 features, test your apps, and give us feedback. You can enroll any supported Pixel device here to get this and future Android 14 Beta and feature drop Beta updates over-the-air, and 64-bit Android Emulator system images will be available soon in the Android Studio SDK Manager.

For the best development experience with Android 14, we recommend that you use the latest release of Android Studio Hedgehog. Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility – learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes – Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.
  • Update your app with the Android SDK Upgrade Assistant - Android Studio Hedgehog now filters and identifies the specific Android 14 API changes that are relevant to your app, and walks you through the steps to upgrade your targetSdkVersion with the Android SDK Upgrade Assistant.

We’ll update the beta system images regularly throughout the Android 14 release cycle.

If you are already enrolled in the Android 14 Beta program and your device is supported, Beta 5 will be made available to you as an Over The Air update without taking any additional action.

For complete information on how to get the Beta, visit the Android 14 developer site.

Android 14 Beta 4

Posted by Dave Burke, VP of Engineering
Android 14 logo

Today we're bringing you Android 14 Beta 4, continuing our work on polish and performance as we get closer to the general availability release of Android 14. Beta 4 is available for Pixel Tablet and Pixel Fold, in addition to the rest of the supported Pixel family, so you can test your applications on devices spanning multiple form factors and directly experience the work we're doing to improve the large-screen and foldable device experience.

Platform Stability

Beta 4 is our second Platform Stable Android 14 release, which means that the developer APIs and all app-facing behaviors are final for you to review and integrate into your apps, and you can publish apps on Google Play to devices running Android 14 at the official API level.

It's a good time to finish compatibility testing and publish any necessary updates to ensure a smooth app experience ahead of the final release of Android 14 later this year.

image of timeline illustrates that we are in July and on track with Platform Stability for Android 14 ahead of final release

If you develop an SDK, library, tool, or game engine, it's even more important to release any necessary updates now to prevent your downstream app and game developers from being blocked with compatibility issues. Also, when you release a compatible update, please make sure to let your developers know.

App Compatibility

Each release of Android contains changes to the platform that improve privacy, security, and the overall user experience. These changes can affect your apps. Testing your app involves installing your production app onto a device running Android 14 Beta 4; you can use Google Play or other means. Work through all the app's flows and look for functional or UI issues. Review the behavior changes to focus your testing.

Get started with Android 14

Today's Beta 4 release has everything you need to try Android 14 features, test your apps, and give us feedback. The easiest way to get started is using the 64-bit Android Emulator system images for the Pixel Tablet or Pixel Fold configurations found in the latest preview of the Android Studio SDK Manager. You can also enroll any supported Pixel device here — including the new Pixel 7a, Pixel Tablet, and the Pixel Fold — to get this and future Android 14 Beta and feature drop Beta updates over-the-air.

For the best development experience with Android 14, we recommend that you use the latest release of Android Studio Hedgehog which includes the Android SDK Upgrade Assistant to help with your migration. Once you’re set up, here are some of the things you should do:
  • Try the new features and APIs. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility – learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes – Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.
  • Update your app with the Android SDK Upgrade Assistant - Android Studio Hedgehog now filters and identifies the specific Android 14 API changes that are relevant to your app, and walks you through the steps to upgrade your targetSdkVersion with the Android SDK Upgrade Assistant.
screengrab of Android SDK Updgrade Assistant in Android Studio Hedgehog
Android SDK Upgrade Assistant in Android Studio Hedgehog

We’ll update the beta system images regularly throughout the Android 14 release cycle.

If you are already enrolled in the Android 14 Beta program and your device is supported, Beta 4 will be made available to you as an Over The Air update without taking any additional action.

For complete information on how to get the Beta, visit the Android 14 developer site.

Android 14 Beta 3 and Platform Stability

Posted by Dave Burke, VP of Engineering
Android 14 logo

With today's Android 14 Beta 3 release, we're continuing into the next phase of the Android development cycle. It builds upon our core themes of privacy, security, performance, developer productivity, and user customization while continuing to improve the large-screen device experience on tablets, foldables, and more.

Beta 3 takes Android 14 to Platform Stability, which means that the developer APIs and all app-facing behaviors are now final for you to review and integrate into your apps. Thank you for all of your continued feedback in getting us to this milestone.

There's a lot to explore in Android 14 and test in your apps. Today with Beta 3, we’re highlighting new accessibility features such as non-linear font scaling, privacy upgrades including partial photos/videos access, new animation support in gesture navigation, and features that further align with the OpenJDK 17 LTS release.


Platform Stability

With Platform Stability in Beta 3, you can confidently develop and release any necessary compatibility updates. Please start your final compatibility testing now and prepare to publish any necessary updates so you can get valuable feedback during the remainder of the beta releases. This will help ensure a smooth app experience ahead of the final release of Android 14 later this year.

image of timeline illustrates that we are in June and on track with Platform Stability for Android 14

If you develop an SDK, library, tool, or game engine, it's even more important to be testing now so you can release your compatible updates as soon as possible to prevent your downstream app and game developers from being blocked with compatibility issues. Also, when you've released a compatible update, please make sure to let your developers know.


App Compatibility

Each release of Android contains changes to the platform that improve privacy, security, and the overall user experience. These changes can affect your apps. Testing your app involves installing your production app onto a device running Android 14 Beta 3; you can use Google Play or other means. Work through all the app's flows and look for functional or UI issues. Review the behavior changes to focus your testing. Changes that may impact your app include:


Non-linear font scaling.
Starting in Android 14, the system supports font scaling up to 200% by default, providing low-vision users with additional accessibility options that align with Web Content Accessibility Guidelines (WCAG). Perform UI testing with the maximum font size enabled (200%) to ensure that your app can accommodate larger font sizes without impacting usability. To get the most out of this feature, make sure that you're not hardcoding sp calculations from Configuration or DisplayMetrics, and use TypedValue's applyDimension() and deriveDimension() to convert between sp and px.

Grant partial access to photos and videos.
Users can now grant partial access to their media library when your app requests any of the visual media permissions (READ_MEDIA_IMAGES or READ_MEDIA_VIDEO) introduced in Android 13 (API level 33). When your app moves to the background, or when the user actively kills your app, the system treats these as one-time-permissions and eventually denies them. If your app is following permissions best practices, this change shouldn't break your app. Android 14 introduces the READ_MEDIA_VISUAL_USER_SELECTED permission to help apps better support the new changes. For a more seamless user experience, we recommend that you consider using the photo picker which provides a safe way for users to grant your app access to selected images and videos that does not require any permissions.

Data safety information is more visible.
To enhance user privacy, Android 14 increases the number of places where the system shows the information you have declared in the Play Console Form. For some permissions, the system runtime permission dialog now includes a clickable section that highlights your app's data sharing practices. This section of the system dialog includes information, such as why your app may decide to share data with third parties, and links users to where they can control your app's data access. We encourage you to review your app's location data sharing policies and take a moment to make any applicable updates to your app's Google Play Data safety section.

Please review the behavior changes section to see all of the changes that may impact the compatibility of your app or game. If you find any issues with libraries and SDKs in your app, try updating to the latest library or SDK version, reaching out to the developer for help if necessary.

Once you’ve published the compatible version of your current app, you can start the process to update your app's targetSdkVersion. Review the behavior changes for apps targeting Android 14 and consider using the compatibility framework to help you detect issues quickly. Here are some of the changes to test for (these apply only to apps with targetSdkVersion set to API 34 or higher):


Foreground service types are required.
If your app targets Android 14, it must specify at least one foreground service type for each foreground service within your app. You should choose a foreground service type that represents your app's use case. The system checks for proper use of foreground service types and confirms that the app has requested the proper runtime permissions or uses the required APIs. For instance, the system expects apps that use the foreground service type FOREGROUND_SERVICE_TYPE_LOCATION type to request either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION. Android 14 introduces foreground service types for health and remote messaging use cases. The system also reserves new types for short services, special use cases, and system exemptions. If a use case in your app isn't associated with any of these types, it's strongly recommended that you migrate your logic to use WorkManager or user-initiated data transfer jobs.

OpenJDK 17 updates.
A few of the changes Android 14 makes to refresh core libraries to align with features in the latest OpenJDK LTS releases can affect app compatibility, including changes to regular expressions, UUID handling, and issues involving ProGuard and the addition of java.lang.ClassValue.

Security changes.
Apps targeting Android 14 can no longer send certain implicit intents to internal components. Runtime registered broadcast receivers must specify export behavior, unless they are receiving only system broadcasts. Dynamically-loaded code files must be marked as read-only. ZipFile(String) and ZipInputStream.getNextEntry() throws a ZipException if zip file entry names contain ".." or start with "/" to prevent the Zip path traversal vulnerability. There are additional restrictions on starting activities from the background, and updated restrictions to calling non-SDK interfaces.

Get started with Android 14

Today's Beta 3 release has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, you can test with devices from our partners, but the easiest way to get started is using the 64-bit Android Emulator system images for the Pixel Tablet or Pixel Fold configurations found in the latest preview of the Android Studio SDK Manager. You can also enroll any supported Pixel device here, including the new Pixel 7a, to get this and future Android 14 Beta and feature drop Beta updates over-the-air.

For the best development experience with Android 14, we recommend that you use the latest release of Android Studio Hedgehog. Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility – learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes – Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the beta system images regularly throughout the Android 14 release cycle.

If you are already enrolled in the Android 14 Beta program and your device is supported, Beta 3 will be made available to you as an Over The Air update without taking any additional action.

For complete information on how to get the Beta, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Android 14 Beta 1

Posted by Dave Burke, VP of Engineering

Illustration of badge style Android 14 logo

Today we're releasing the first Beta of Android 14, building around our core themes of privacy, security, performance, developer productivity, and user customization while continuing to improve the large-screen device experience on tablets, foldables, and more. We've been making steady progress refining the features and stability of Android 14, and it's time to open the experience up to both developers and early-adopters.

Android delivers enhancements and new features year-round, and your feedback on the Android beta program plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the beta, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.


Working across form factors

Android 14 builds on the work done in past releases to support tablets and foldable form factors, and we've been building tools and resources to help polish your app experience, including design inspiration and development guides.


Smarter System UI

In the Android operating system, features are implemented by two separate yet equally important packages: the framework, which provides services, and the System UI, which gives the user control of those services. Each Android release brings new refinements to the system UI, and here are some that you might notice in Beta 1.


New back arrow

Image showing the back arrow indicating gesture navigation on a mobile device

The gesture navigation experience includes a more prominent back arrow while interacting with your app to help improve back gesture understanding and usefulness. The back arrow also compliments the user's wallpaper or device theme.



A superior system sharesheet

Screen image of custom sharesheet with direct share targets


In Android 14, apps can now add custom actions to system sharesheets they invoke. Create your custom ChooserAction using ChooserAction.Builder and specify a list of your ChooserActions as the Intent.EXTRA_CHOOSER_CUSTOM_ACTIONS of the Intent created with Intent.createChooser.

In addition, the system now uses more app signals to determine the ranking of the direct share targets. You provide the signal by calling pushDynamicShortcut to report shortcut usage with the corresponding capability bindings.






More graphics capabilities

Android 14 adds new graphics features that you can use to make your app really stand out.


Paths are now queryable and interpolatable

Android's Path API is a powerful and flexible mechanism for creating and rendering vector graphics. Starting in Android 14, you can query paths to find out what's inside of them. The API updates include functionality to interpolate between paths whose structures match exactly, enabling morphing effects, and an AndroidX library provides backwards compatibility back to API 21. More details here.


Personalization

Per-app language preferences

Android 14 enhances per-app language preferences, allowing for dynamic customization of the set of languages displayed in the Android Settings per-app language list, and giving IMEs a way to know the UI language of the current app. Starting with Android Studio Giraffe Canary 7 and AGP 8.1.0-alpha07, you can configure your app to support per-app language preferences automatically. Based on your project resources, the Android Gradle plugin generates the LocaleConfig file and adds a reference to it in the generated manifest file, so you no longer have to create or update the file manually when your language support changes. See Automatic per-app language support for more information and leave feedback.


Privacy

Limiting visibility to disability-focused accessibility services

Android 14 introduces the accessibilityDataSensitive attribute to allow apps to limit visibility of specified views only to accessibility services that claim to help users with disabilities. Play Protect ensures apps downloaded from the Play Store are truthful about these claims. TalkBack and other services that claim to help users with disabilities will not be affected by this attribute.

Apps can consider using accessibilityDataSensitive to:

  • Protect user data (such as personal details or plaintext passwords) 
  • Prevent critical actions from being executed unintentionally (such as transfering money or checking out in a shopping app)
  •  

App compatibility

If you haven't yet tested your app for compatibility with Android 14, now is the time to do it! With Android 14 now in beta, we're opening up access to early-adopter users as well as developers. In the weeks ahead, you can expect more users to be trying your app on Android 14 and raising issues they find.

To test for compatibility, install your published app on a device or emulator running Android 14 Beta and work through all of the app’s flows. Review the behavior changes to focus your testing. After you’ve resolved any issues, publish an update as soon as possible.

Image of Android 14 preview and release timeline indicating we are on target with Beta release in April

It’s also a good time to start getting ready for your app to target Android 14, by testing with the app compatibility changes toggles in Developer Options.

Partial screenshot of App Compatibility Changes in Developer Options
App compatibility toggles in Developer Options.

Get started with Android 14

Today's Beta release has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using the Android Emulator in a tablet or foldable configuration in the latest preview of the Android Studio SDK Manager. Now that we've entered the beta phase, you can enroll any supported Pixel device here to get this and future Android 14 Beta and feature drop Beta updates over-the-air. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ versions). Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs - your feedback is critical as we finalize the APIs. Report issues in our tracker on the feedback page
  • Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it. 
  • Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview and beta system images and SDK regularly throughout the Android 14 release cycle.

If you are already enrolled in the Android 13 QPR Beta program and your device is supported, Android 14 Beta 1 will be made available to you without taking any additional action.

For complete information on how to get the Beta, visit the Android 14 developer site.

Android 14 Developer Preview 2

Posted by Dave Burke, VP of Engineering

Today, we're releasing the second Developer Preview of Android 14, building on the work of the first developer preview of Android 14 from last month with additional enhancements to privacy, security, performance, developer productivity, and user customization while continuing to refine the large-screen device experience on tablets, foldables, and more.

Android delivers enhancements and new features year-round, and your feedback on the Android 14 developer preview and Quarterly Platform Release (QPR) beta program plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

Working across form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. See get started with building for large screens and learn about foldables for a quick jumpstart on how to get your apps ready. Our app quality guidance for large screens contains detailed checklists to review your app. We've also recently released libraries supporting low latency stylus and motion prediction.

The large screen gallery contains design inspiration for social and communications, media, productivity, shopping, and reading app experiences.

Privacy and security

Privacy and security have always been a core part of Android's mission, built on the foundation of app sandboxing, open source code, and open app development. In Android 14, we’re building the highest quality platform for all by providing a safer device environment and giving users more controls to protect their information.

Selected photos access

We recommend that you use the Photo Picker if your app needs to access media that the user selects; it provides a permissionless experience on devices running Android 4.4 onwards, using a combination of core platform features, Google Play system updates, and Google Play services.

If you cannot use Photo Picker, when your app requests any of the visual media permissions (READ_MEDIA_IMAGES / READ_MEDIA_VIDEO) introduced in SDK 33, Android 14 users can now grant your app access to only selected photos and videos.

In the new dialog, the permission choices will be:

  • Allow access to all photos: the full library of all on-device photos & videos is available
  • Select photos: only the user's selection of photos & videos will be temporarily available via MediaStore
  • Don’t allow: access to all photos and videos is denied

Apps can prompt users to select media again by requesting the media permissions again and having the READ_MEDIA_VISUAL_USER_SELECTED permission declared in their app manifest.

Please test this new behavior with your apps and adapt your UX to handle the new permission and the media file reselection flow.

Credential manager

Android 14 adds Credential Manager as a platform API, and we're supporting it back to Android 4.4 (API level 19) devices through a Jetpack Library with a Google Play services implementation. It aims to make sign-in easier for users with APIs that retrieve and store credentials with user-configured credential providers. In addition to supporting passwords, the API allows your app to sign-in using passkeys, the new industry standard for passwordless sign-in. Passkeys are built on industry standards, can work across different operating systems and browser ecosystems, and can be used with both websites and apps. Developer Preview 2 features improvements in the UI styling for the account selector, along with changes to the API based upon feedback from Developer Preview 1. Learn more here.

Safer implicit intents

For apps targeting Android 14, creating a mutable pending intent with an implicit intent will throw an exception, preventing them from being able to be used to trigger unexpected code paths. Apps need to either make the pending intent immutable or make the intent explicit. Learn more here.

Background activity launching

Android 10 (API level 29) and higher place restrictions on when apps can start activities when the app is running in the background. These restrictions help minimize interruptions for the user and keep them more in control of what's shown on their screen. To further reduce instances of unexpected interruptions, Android 14 gives foreground apps more control over the ability of apps they interact with to start activities. Specifically, apps targeting Android 14 need to grant privileges to start activities in the background when sending a PendingIntent or when binding a Service.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Background optimizations

Developer Preview 2 includes optimizations to Android’s memory management system to improve resource usage while applications are running in the background. Several seconds after an app goes into the cached state, background work is disallowed outside of conventional Android app lifecycle APIs such as foreground services, JobScheduler, or WorkManager. Background work is disallowed an order of magnitude faster than on Android 13.

Fewer non-dismissible notifications

Notifications on Android 14 containing FLAG_ONGOING_EVENT will be user dismissible on unlocked handheld devices. Notifications will stay non-dismissible when the device is locked, and notification listeners will not be able to dismiss these notifications. Notifications that are important to device functionality, like system and device policy notifications, will remain fully non-dismissible.

Improved App Store Experiences

Android 14 introduces several new PackageInstaller APIs which allow app stores to improve their user experience, including the requestUserPreapproval() method that allows the download of APKs to be deferred until after the installation has been approved, the setRequestUpdateOwnership() method that allows an installer to indicate that it is responsible for future updates to an app it is installing, and the setDontKillApp() method that can seamlessly install optional features of an app through split APKs while the app is in use. Also, the InstallConstraints API gives installers a way to ensure that app updates happen at an opportune moment, such as when an app is no longer in use.

If you develop an app store, please give these APIs a try and let us know what you think!

Personalization

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 grant you read access to user preferences for adjusting app information display (getTemperatureUnit, getFirstDayOfWeek). You can also register a BroadcastReceiver on ACTION_LOCALE_CHANGED to handle locale configuration changes when regional preferences change.

App compatibility

We’re working to make updates faster and smoother with each platform release 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 sooner.

Developer Preview 2 is in the period where we're looking for input on our APIs, along with details on how platform changes affect your apps, so now is the time to try new features and give us your feedback.

It’s also a good time to start your compatibility testing and identify any work you’ll need to do. You can test some of them without changing your app's targetSdkVersion using the behavior change toggles in Developer Options. This will help you get a preliminary idea of how your app might be affected by opt-in changes in Android 14.

Image of a partial screen shot of a device showing App compatibility toggles in Developer Options
App compatibility toggles in Developer Options.

Platform Stability is when we’ll deliver final SDK/NDK APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using 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 today by flashing a system image onto 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 the 64-bit system images with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ versions). Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview system images and SDK regularly throughout the Android 14 release cycle. This preview release is for developers only and not intended for daily or consumer use, so it will only available by manual download for new Android 14 developer preview users. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 2 now. Otherwise, you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android 14 Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

The first developer preview of Android 14

Posted by Dave Burke, VP of Engineering

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

Illustration of badge style Android 14 logo

Today we're releasing the first Developer Preview of Android 14, and your feedback in these previews is a critical part of making Android better for everyone. Android 14 continues our work to improve your productivity as developers, along with enhancements to performance, privacy, security, and user customization. This preview is just the beginning, and we’ll have lots more to share as we move through the release cycle.

Android continues to deliver enhancements and new features year-round, and your Android 14 developer preview and Quarterly Platform Release (QPR) beta program feedback plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

Working across devices and form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. To help you build apps that adapt to different screen sizes, we've created window size classes, sliding pane layout, Activity embedding, and box with constraints and more, all supported in Jetpack Compose. With every release, our goal is to make it easier for you to optimize your app across all Android surfaces.

To help streamline getting your apps ready we have updated our app quality guidance for large screens, and provided additional learning opportunities around building for large screens and foldables. The large screen gallery contains proven design patterns along with design inspiration around the markets that your app supports such as social and communications, media, productivity, shopping, and reading apps.

Multi-device experiences are a big part of the future of Android. You can get started today with the Cross device SDK preview, allowing you to build rich experiences that intuitively work across different devices and form factors, and there's more to come.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Updates and additions to JobScheduler and Foreground Services

It's more complicated than necessary to perform some background work, 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 foreground services should be used, reserving them for only the highest priority user-facing tasks so that Android can improve resource consumption and battery life.

In Android 14, we are making changes to existing Android APIs (Foreground Services and JobScheduler) including adding new functionality for user-initiated data transfers, along with an updated requirement to declare foreground service types. The user-initiated data transfer job will make managing user initiated downloads and uploads easier, particularly when they require constraints such as downloading on Wi-Fi only. The requirement to declare foreground service types allows you to clearly define the intent of the background work of your app while making it clear which use-cases are appropriate for foreground services. In addition, Google Play will be rolling out new policies to ensure the appropriate use of these APIs, with more details coming soon.

Optimized broadcasts

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 should not impact your apps, we have adjusted how apps receive context-registered broadcasts once the app goes into a cached state. Broadcasts to context-registered receivers may be queued and only delivered to the app once it comes out of the cached state. Furthermore, some repeating context-registered broadcasts, such as BATTERY_CHANGED, may be merged into one final broadcast before it is delivered once the app comes out of the cached state.

Exact alarms

The invocation of exact alarms can significantly affect the device's resources, such as battery life. So in Android 14, newly installed apps targeting Android 13+ (SDK 33+) that are not clocks or calendars must request the user to grant them the SCHEDULE_EXACT_ALARM special permission before setting exact alarms. Apps can direct users to the settings page via an intent to toggle this permission, but we encourage you to evaluate your use cases and choose more flexibly scheduled alternatives when possible.

Clock and calendar apps targeting Android 13+ (SDK 33+) that rely on exact alarms as part of their core app workflow will be able to declare the USE_EXACT_ALARM normal permission instead (granted on install). Apps will not be able to publish a version of their app to the Play store with this permission in the manifest unless they qualify based on the policy language.

Customization

We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling

Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%.

To mitigate issues where text gets too large, starting in Android 14, a non-linear font scaling curve is automatically applied. This ensures that text that is already large enough doesn’t increase at the same rate as smaller text.
Examples of text scaling showing the differences between the sizing of standard font at 100% (no scaling)on the left, standard scaling (200%) in the middle, and non-linear scaling (200%)on the rightIn Android 14, you should test your app UI with the maximum font size using the Font size option within the Accessibility > Display size and text settings. Ensure that the adjusted large text size setting is reflected in the UI, and that it doesn’t cause text to be cut off. Our documentation has more on best practices.

Per-app language preferences

You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. This allows you to customize the language list per region, run A/B experiments, and provide updated locales if your app utilizes server-side localization pushes.

IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language.

Grammatical Inflection API

The Grammatical Infection API allows you to more easily add support for users who speak languages which have grammatical gender. For example,

Masculine: “Vous êtes abonné à...”

Feminine: “Vous êtes abonnée à…”

Neutral: “Abonnement à…activé”

Grammatical gender is inherent to the language and cannot be easily worked around in some non-English languages. This new API lowers the effort to support viewer gender (who’s viewing the UI; not who’s being talked about) as compared to using the SelectFormat in ICU which must be applied on a per string basis.

To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

Privacy and Security

Runtime receivers

Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Safer implicit intents

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents internally that don't specify a package. Learn more here.

Safer dynamic code loading

Dynamic code loading (DCL) introduces outlets for malware and exploits, since dynamically downloaded executables can be unexpectedly manipulated, causing code injection. Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Block installation of apps

Malware often targets older API levels to bypass security and privacy protections that have been introduced in newer Android versions. To protect against this, starting with Android 14, apps with a targetSdkVersion lower than 23 cannot be installed. This specific version was chosen because some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 (API level 23).

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

You can test apps targeting an older API level using the following ADB command:

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

Credential Manager and Passkeys support

We recently announced the alpha release of Credential Manager, a new Jetpack API that allows you to simplify your users' authentication journey, while also increasing security with support of passkeys. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors and more convenient for users (they require just a biometric swipe to securely sign in on any device). Read more here.

App compatibility

We’re working to make updates faster and smoother with each platform release 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 sooner.

OpenJDK 17 Support - This preview includes access to 300 OpenJDK 17 classes. We are working hard to fully enable Java 17 language features in upcoming developer previews. These include record classes, multi-line strings and pattern matching instanceof. Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that include these changes. This is part of our commitment to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users independent of platform releases.

Easier testing and debugging of changes - To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.
App compatibility toggles in Developer Options
Platform stability milestone - Like last year, we’re letting you know our Platform Stability milestone well in advance, to give you more time to plan for app compatibility work. At this milestone we’ll deliver final SDK/NDK APIs and also final internal APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using 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 today by flashing a system image onto 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 the 64-bit system images with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ versions). Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview system images and SDK regularly throughout the Android 14 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

The first developer preview of Android 14

Posted by Dave Burke, VP of Engineering

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

Illustration of badge style Android 14 logo

Today we're releasing the first Developer Preview of Android 14, and your feedback in these previews is a critical part of making Android better for everyone. Android 14 continues our work to improve your productivity as developers, along with enhancements to performance, privacy, security, and user customization. This preview is just the beginning, and we’ll have lots more to share as we move through the release cycle.

Android continues to deliver enhancements and new features year-round, and your Android 14 developer preview and Quarterly Platform Release (QPR) beta program feedback plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

Working across devices and form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. To help you build apps that adapt to different screen sizes, we've created window size classes, sliding pane layout, Activity embedding, and box with constraints and more, all supported in Jetpack Compose. With every release, our goal is to make it easier for you to optimize your app across all Android surfaces.

To help streamline getting your apps ready we have updated our app quality guidance for large screens, and provided additional learning opportunities around building for large screens and foldables. The large screen gallery contains proven design patterns along with design inspiration around the markets that your app supports such as social and communications, media, productivity, shopping, and reading apps.

Multi-device experiences are a big part of the future of Android. You can get started today with the Cross device SDK preview, allowing you to build rich experiences that intuitively work across different devices and form factors, and there's more to come.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Updates and additions to JobScheduler and Foreground Services

It's more complicated than necessary to perform some background work, 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 foreground services should be used, reserving them for only the highest priority user-facing tasks so that Android can improve resource consumption and battery life.

In Android 14, we are making changes to existing Android APIs (Foreground Services and JobScheduler) including adding new functionality for user-initiated data transfers, along with an updated requirement to declare foreground service types. The user-initiated data transfer job will make managing user initiated downloads and uploads easier, particularly when they require constraints such as downloading on Wi-Fi only. The requirement to declare foreground service types allows you to clearly define the intent of the background work of your app while making it clear which use-cases are appropriate for foreground services. In addition, Google Play will be rolling out new policies to ensure the appropriate use of these APIs, with more details coming soon.

Optimized broadcasts

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 should not impact your apps, we have adjusted how apps receive context-registered broadcasts once the app goes into a cached state. Broadcasts to context-registered receivers may be queued and only delivered to the app once it comes out of the cached state. Furthermore, some repeating context-registered broadcasts, such as BATTERY_CHANGED, may be merged into one final broadcast before it is delivered once the app comes out of the cached state.

Exact alarms

The invocation of exact alarms can significantly affect the device's resources, such as battery life. So in Android 14, newly installed apps targeting Android 13+ (SDK 33+) that are not clocks or calendars must request the user to grant them the SCHEDULE_EXACT_ALARM special permission before setting exact alarms. Apps can direct users to the settings page via an intent to toggle this permission, but we encourage you to evaluate your use cases and choose more flexibly scheduled alternatives when possible.

Clock and calendar apps targeting Android 13+ (SDK 33+) that rely on exact alarms as part of their core app workflow will be able to declare the USE_EXACT_ALARM normal permission instead (granted on install). Apps will not be able to publish a version of their app to the Play store with this permission in the manifest unless they qualify based on the policy language.

Customization

We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling

Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%.

To mitigate issues where text gets too large, starting in Android 14, a non-linear font scaling curve is automatically applied. This ensures that text that is already large enough doesn’t increase at the same rate as smaller text.
Examples of text scaling showing the differences between the sizing of standard font at 100% (no scaling)on the left, standard scaling (200%) in the middle, and non-linear scaling (200%)on the rightIn Android 14, you should test your app UI with the maximum font size using the Font size option within the Accessibility > Display size and text settings. Ensure that the adjusted large text size setting is reflected in the UI, and that it doesn’t cause text to be cut off. Our documentation has more on best practices.

Per-app language preferences

You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. This allows you to customize the language list per region, run A/B experiments, and provide updated locales if your app utilizes server-side localization pushes.

IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language.

Grammatical Inflection API

The Grammatical Infection API allows you to more easily add support for users who speak languages which have grammatical gender. For example,

Masculine: “Vous êtes abonné à...”

Feminine: “Vous êtes abonnée à…”

Neutral: “Abonnement à…activé”

Grammatical gender is inherent to the language and cannot be easily worked around in some non-English languages. This new API lowers the effort to support viewer gender (who’s viewing the UI; not who’s being talked about) as compared to using the SelectFormat in ICU which must be applied on a per string basis.

To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

Privacy and Security

Runtime receivers

Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Safer implicit intents

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents internally that don't specify a package. Learn more here.

Safer dynamic code loading

Dynamic code loading (DCL) introduces outlets for malware and exploits, since dynamically downloaded executables can be unexpectedly manipulated, causing code injection. Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Block installation of apps

Malware often targets older API levels to bypass security and privacy protections that have been introduced in newer Android versions. To protect against this, starting with Android 14, apps with a targetSdkVersion lower than 23 cannot be installed. This specific version was chosen because some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 (API level 23).

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

You can test apps targeting an older API level using the following ADB command:

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

Credential Manager and Passkeys support

We recently announced the alpha release of Credential Manager, a new Jetpack API that allows you to simplify your users' authentication journey, while also increasing security with support of passkeys. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors and more convenient for users (they require just a biometric swipe to securely sign in on any device). Read more here.

App compatibility

We’re working to make updates faster and smoother with each platform release 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 sooner.

OpenJDK 17 Support - This preview includes access to 300 OpenJDK 17 classes. We are working hard to fully enable Java 17 language features in upcoming developer previews. These include record classes, multi-line strings and pattern matching instanceof. Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that include these changes. This is part of our commitment to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users independent of platform releases.

Easier testing and debugging of changes - To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.
App compatibility toggles in Developer Options
Platform stability milestone - Like last year, we’re letting you know our Platform Stability milestone well in advance, to give you more time to plan for app compatibility work. At this milestone we’ll deliver final SDK/NDK APIs and also final internal APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using 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 today by flashing a system image onto 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 the 64-bit system images with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ versions). Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview system images and SDK regularly throughout the Android 14 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Privacy Sandbox: Developer Preview 5 is here!

Posted by Fred Chung, Android Developer Relations

Today, we’re releasing the Privacy Sandbox on Android Developer Preview 5 ‒ it’s a major milestone that will become the foundation for upcoming Privacy Sandbox Beta releases.

We appreciate that many of you have tested the Developer Preview and have reported issues and shared your feedback. This feedback has helped us evolve the Privacy Sandbox design. For example, we have modified the SDK Runtime design to allow reflection API usage, and have published additional design proposals on FLEDGE services, mediation, and app-to-web measurement.

Let’s have a look at the specifics in this release.


What’s in Developer Preview 5?

Developer Preview 5 includes additional functionality, data validation enhancements, and API signature changes across the privacy preserving APIs and the SDK Runtime. See the release notes for details.


Attribution Reporting API



FLEDGE on Android API

  • To provide up-to-date data for auctions, you can set up a daily fetch URL to update custom audience AdData lists and other metadata.
  • This release incorporates various API signature changes and additional parameter validation to ensure robustness. Refer to the release notes for details. Be sure to update the sample code and your test projects using previous Developer Preview releases.


SDK Runtime

  • Apps get additional control on runtime enabled SDK lifecycle events, such as when the SDK is unexpectedly terminated by the platform. Implementing the SdkSandboxLifecycleCallback allows the app to take appropriate actions to recover.
  • After successfully loading an SDK, apps now have access to an IBinder interface to facilitate 2-way communications with the runtime-enabled SDK.


Topics API

  • Updated taxonomy for classification of mobile apps.


AdServices permissions

  • App developers must now declare AdServices permissions to access the privacy preserving APIs. Learn more.

In the coming months, we’ll continue to use the Developer Previews to innovate and implement new features. We’ll publish more details about the Beta and these future releases in the coming months.


Get started with Developer Preview 5

With today’s Developer Preview release, we hope to continue working with the industry and developers to get prepared for Privacy Sandbox on Android. The release provides the resources you need to begin early testing of features and share feedback. To get started developing, see instructions to set up the SDK and system images on the emulator or supported Pixel devices.

For more information on the Privacy Sandbox on Android Developer Preview, visit the developer site and sign up for our newsletter to receive regular updates.

Announcing Cross device SDK Developer Preview for building rich multi-device experiences on Android

Posted by Alex Rocha - Developer Relations Engineer Manager, Ryan Ausanka-Crues - Eng Manager, Multi-device development, Stella Loh - Product Manager, Multi-device development

Today we’re launching our Developer Preview of the new Cross device SDK for Android. First announced during the Google I/O ‘22 Multi-device development session, our Cross device SDK allows developers to build rich multi-device experiences with a simple and intuitive set of APIs. This SDK abstracts away the intricacies involved with working with device discovery, authentication, and connection protocols, allowing you to focus on what matters most—building delightful user experiences and connecting these experiences across a variety of form factors and platforms.

What’s in Developer Preview

This initial release contains a set of rich APIs centered around the core functionality of Device discovery, Secure connections, and Multi-device Sessions.

  1. Device discovery: Easily find nearby devices, authorize peer-to-peer communication, and start the target application on receiving devices.
  2. Secure connections: Enable encrypted, low-latency bi-directional data sharing between authorized devices.
  3. Multi-device Sessions: Enable transferring or extending an application’s user experience across multiple devices.

In turn, this will allow you to build compelling cross-device experiences by enabling and simplifying the following use cases:

  • Discovering and authorizing communication with nearby devices.
  • Sharing an app’s current state with the same app on another device.
  • Starting the app on a secondary device without having to keep the app running in background.
  • Establishing secure connections for devices to communicate with each other.
  • Enabling task handoff where the user starts a task on one device, and can easily continue on another device.

Starting today with a Developer Preview for Android phones and tablets, the Cross device SDK will be available later for other Android surfaces and non-Android OSs.

Under The Hood

The Cross device SDK provides a software abstraction layer that handles all aspects of cross-device connectivity, leveraging wireless technologies such as Bluetooth, Wi-Fi, and Ultra-wide band; our SDK does all the heavy-lifting under the hood, offering you a modular,connectivity-agnostic API that supports bi-directional communication between devices and is backward compatible to Android 8. In addition, apps will not have to declare or request Runtime Permissions for any of the underlying connectivity protocols used (such as BLUETOOTH_CONNECT, BLUETOOTH_SCAN, ACCESS_FINE_LOCATION, etc.), and the user can allow apps to connect to only the device(s) they selected.

Getting started with Developer Preview

Head over to our developer guide to get started and try out the Developer Preview of the Cross device SDK for Android. Make sure to check out our Rock Paper Scissor sample app (Kotlin and Java) on GitHub for a demonstration on how to work with the various APIs and our Google I/O ‘22 Multi-device development session for a general overview of the SDK.

Feedback

We’d love to hear from you during this initial Developer Preview launch to help us shape the SDK and influence future roadmapping, so please share your feedback and let us know your experience with the SDK!

Android 13 Beta 3 and Platform Stability

Posted by Dave Burke, VP of Engineering

Android13 Logo

Today we’re releasing the third Beta of Android 13, taking us into the final phase of our cycle where we’re focusing on polish and performance. With Android 13, we’ve built on our core themes of privacy and security, developer productivity, and tablet and large screen support.

There’s a lot to explore in Android 13, from privacy features like the new notification permission and photo picker, to productivity features like themed app icons and per-app language support, as well as modern standards like HDR video, Bluetooth LE Audio, and MIDI 2.0 over USB. We’ve also extended the newer updates we made in 12L, giving you better tools to take advantage of the 270+ million tablet and large screen devices in active use.

Beta 3 takes Android 13 to Platform Stability, which means that the developer APIs and all app-facing behaviors are now final. We’re thankful for all the feedback you’ve shared to help us get to this point! For developers, the focus is now on compatibility testing and quality as you prepare your apps for the official release later in the year!

You can get Beta 3 on your Pixel device by enrolling here for over-the-air updates. If you previously enrolled, you’ll automatically get today’s update. You can also try Android 13 Beta on select devices from several of our partners - learn more at android.com/beta. Read on for a quick look at how to get your app ready, and visit the Android 13 developer site for details.


Platform Stability

With Beta 3, Android 13 reaches Platform Stability, a milestone that means all app-facing behaviors and APIs, including the official API Level 33 SDK and NDK APIs, are now final. So from Beta 3, you can confidently develop and release your compatibility updates knowing that the platform won’t change.

Platform stability timeline with stable at the June mark

We’re asking all app and game developers to start your final compatibility testing now and prepare to publish your compatibility updates as soon as possible ahead of the final release.

For all SDK, library, tools, and game engine developers, it’s even more important to start testing now and release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates. So when you’ve released a compatible update, be vocal and let your developers know!


App compatibility

App compatibility means that your app runs as intended on a new version of the platform. With each release, we make integral changes to the platform that improve privacy and security and the overall user experience across the OS. These can affect your apps, so it’s important to test your app now, make any updates needed, and publish a compatible update to your users ahead of the final release. It’s a basic but critical level of quality that your users will appreciate as they explore what’s new in Android 13.

To test your app for compatibility, just install your production app from Google Play or other source onto a device running Android 13 Beta 3. Work through all of the app’s flows and watch for functional or UI issues. Review the behavior changes to focus your testing. Here are some changes to watch for:

  • Runtime permission for notifications - Android 13 introduces a new runtime permission for sending notifications from an app. Make sure you understand how the new permission works, and plan on targeting Android 13 (API 33) as soon as possible. More here.
  • Clipboard preview - Make sure your app hides sensitive data in Android 13’s new clipboard preview, such as passwords or credit card information. More here.
  • JobScheduler prefetch - JobScheduler now tries to anticipate the next time your app will be launched and will run any associated prefetch jobs ahead of that time. If you use prefetch jobs, test that they are working as expected. More here.

Also remember to test the libraries and SDKs in your app for compatibility. If you find any issues, try updating to the latest version of the library or SDK or reaching out to the developer for help.

Once you’ve published the compatible version of your current app, you can start the process to update your app's targetSdkVersion. Review the behavior changes for apps targeting Android 13 and use the compatibility framework to help you detect issues quickly. Here are some of the changes to test for (these apply only to apps with targetSdkVersion set to API 33 or higher):

  • Nearby device permission for Wi-Fi - Apps that manage a device's connections to nearby access points should use a new NEARBY_WIFI_DEVICES runtime permission for Wi-Fi operations like scanning, without needing access to device location. Some Wi-Fi APIs require your app to have this new permission. More here.
  • Granular media permissions - If your app targets Android 13 and reads media files from common data storage, you must request one or more of the new granular permissions instead of the READ_EXTERNAL_STORAGE permission. More here.
  • Permission changes for body sensors - Android 13 introduces "while in use" access for body sensors. If your app needs to access body sensor information from the background, it must declare a new BODY_SENSORS_BACKGROUND permission. More here.
  • Intent filters block non-matching intents - If your app sends an intent to an exported component of another app targeting Android 13 (API 33) or higher, it now needs to match an intent filter in the receiving app. More here.
  • Media controls derived from PlaybackState - Android 13 derives more media controls from PlaybackState actions, to show a richer set of controls that are consistent across device types. Make sure your app handles these changes. More here

Tablets and large-screens support

Android 13 builds on the tablet optimizations introduced in 12L, so as part of your testing, make sure your apps look their best on tablets and other large-screen devices. You can test with the large screens features by setting up an Android emulator in Android Studio, or you can use a large screen device from our Android 13 Beta partners. Here are some areas to watch for:

  • Taskbar interaction - Check how your app responds when viewed with the new taskbar on large screens. Make sure your app's UI isn't cut off or blocked by the taskbar. More here.
  • Multi-window mode - Multi-window mode is now enabled by default for all apps, regardless of app configuration, so make sure the app handles split-screen appropriately. You can test by dragging and dropping your app into split-screen mode and adjusting the window size. More here.
  • Improved compatibility experience - if your app isn’t optimized for tablets yet, such as using a fixed orientation or not being resizable, check how your app responds to compatibility mode adjustments such as letterboxing. More here.
  • Media projection - If your app uses media projection, check how your app responds while playing back, streaming, or casting media on large screens. Be sure to account for device posture changes on foldable devices as well. More here.
  • Camera preview - For camera apps, check how your camera preview UI responds on large screens when your app is constrained to a portion of the screen in multi-window or split-screen mode. Also check how your app responds when a foldable device's posture changes. More here.

You can read more about the tablet features in Android 13 and what to test here.


Get started with Android 13!

Today’s Beta release has everything you need to test your app and try the Android 13 features. Just enroll your Pixel device to get the update over-the-air. To get started, set up the Android 13 SDK.

You can also test your app with Android 13 Beta on devices from several of our partners. Visit android.com/beta to see the full list of partners, with links to their sites for details on their supported devices and Beta builds, starting with Beta 1. Each partner will handle their own enrollments and support, and provide the Beta updates to you directly. For even broader testing, you can try Android 13 Beta 3 on Android GSI images, and if you don’t have a device, you can test on the Android Emulator.

For complete details on Android 13, visit the Android 13 developer site.