Author Archives: Android Developers

Bringing the best of Chrome to Android developers and users

Posted by Victor Gallet, Product ManagerWhen adding a web experience to your Android app, simply launching a browser from your app forces users to leave your app, with the risk of abandonment for that session. WebViews allow you to build your own in-app browser, but can be a complex process with higher maintenance overhead. To help developers provide a better in-app web experience, Chrome launched Custom Tabs, which are now supported by most major browsers on Android.

Today, we’re announcing two new features that bring the best of Chrome to Android developers and users.

Multitasking between your app and the web

Moving image showing customizable height with partial custom tabs on a phone screen
Developers can customize tab height with Partial Custom Tabs

To keep users engaged with your app, Chrome now gives you more control over tab height with Partial Custom Tabs. You can customize the tab in pixels for a partial overlay, allowing users to simultaneously interact with your native app and the web. Partial Custom Tabs are currently supported by a handful of browsers, including Chrome, and we look forward to additional browser support soon. If your users’ browser does not support Partial Custom Tabs, users will simply see the supported full-screen Custom Tab.


Giving users the best of Chrome

With Chrome Custom Tabs, you’ll give users a fast, safe, and seamless way to experience the web. Your users will know that when they open the web from your app, it will be “running in Chrome” so they can use their most loved Chrome features like saved passwords and autofill.
Moving image showing Google password Manager and autofill features on a phone screen
Developers can customize tab height with Partial Custom Tabs

To add web to your Android app using Custom Tabs, check out our docs on developer.chrome.com.

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.

Improving user privacy by requiring opt-in to send X-Requested-With header from WebView

Posted by Peter Birk Pakkenberg, Software Engineer

X-Requested-With (XRW) is a nonstandard header.

When a user installs and runs an application that uses a WebView to embed web content, the WebView will add the X-Requested-With header on every request sent to servers, with a value of the application APK name. It is then left to the receiving web server to determine if and how to use this information.

We want to protect the user's privacy by only sending this header on requests if the app developer explicitly opts-in to share with services embedded within the WebView. We are introducing new and purpose-built methods of client attestation that solve important safety use cases in a privacy-sensitive manner.

To let current online services that depend on this header migrate away from using it, we will run a Deprecation Origin Trial, while removing the header for general traffic.

Why are we making this change?

In early use cases, the X-Requested-With header was used to detect click fraud from malicious apps. It was also used to let a server know it's interacting with AJAX requests and needn't reply with HTML. The header was quickly adopted by common frameworks (jQuery, Dojo, Django) as a defense against CSRF attacks. However, several vulnerabilities (such as browser extensions impersonating websites) appeared around its use.

Android WebView adopted the X-Requested-Header with the application name as the value, as a way to allow online services to detect deceptive apps that were using hidden webviews to generate fake traffic. While this problem still exists today, the header as it is currently implemented does not fully solve the problem, as apps can easily change the value being sent on some requests in later Android versions.

The header, as currently implemented by default in Android WebView, does not follow the principle of meaningful consent of all parties exchanging the information and the Android Platform Security Model’s definition of multi-party consent.

APK name also contains specific information about the context in which the user is consuming the web content, and can leak the identity of the app to the online service.

How does this proposal affect the header?

It's important to note that the non-WebView use cases will not change because of this proposal, as clients and servers still can and will set the header in normal JavaScript environments.

Even today, WebView will not overwrite the header if the header has already been set on an AJAX request by a JavaScript framework.

This removal only targets the WebView use case, which adds the header to every HTTP request made by the browser (that is, not the XMLHttpRequest use case).

What is the impact of removing this feature?

Today content owners may decide to rely on X-Requested-With to attribute traffic and control access without employing their own authentication. Other services use it for reporting of aggregate patterns about their user base.

All of these use cases will be affected by the removal of the header on requests, and in the majority of cases where the header is not modified by dishonest apps, it provides useful information to online services.

Given this, we plan to limit disruption during the deprecation and transition to purpose-built replacement signals by offering a Deprecation Origin Trial to maintain the existing behavior.

We ask for feedback on existing use cases that currently rely on and may be impacted by these changes.

Next steps and the future of XRW

As we gradually roll out the removal, origins participating in the trial will be exempted (that is, WebView will continue to send the header to these origins for as long as the trial lasts). The deprecation trial is expected to remain active for at least a year to give partners time to adjust for the change.

Further, during the deprecation origin trial, we will be developing new privacy-preserving APIs to match the use cases where the XRW header is being used today, such as client attestation APIs.

Separately from the deprecation trial, we will provide an opt-in API for application developers. This API will allow individual apps to selectively send the header to chosen origins, which can be used to maintain functionality of legacy sites that are not migrating, and the API will remain after the deprecation trial has finished.

Helpful resources

Key areas where we are seeking feedback

  • Key use cases for the XRW header today (e.g., payment authentication, account takeover fraud)
  • How important the XRW header is for each of these use cases
  • Desired capabilities that any new privacy-preserving alternatives would ideally have

#WeArePlay | Meet Valentin from Austria. More stories from Spain, Argentina and Azerbaijan

Posted by Leticia Lago, Developer MarketingIn our first batch of #WeArePlay stories for 2023, discover the inspiring app founders sharing their knowledge with millions around the world: from cooking up the best recipes, learning better ways to stay healthy, finding the best spots for photography or sharing tips to nail that next exam.

First, we begin with Valentin from Austria. With hotelier and restaurateur parents, Valentin grew up learning about the challenges of the hospitality sector. As he was a better programmer than a cook, he decided to not join the industry. But at 22 - whilst successfully working abroad - he felt his life was lacking purpose. Valentin went back to his hometown and, after hearing his parents had troubles with hiring, created a hospitality recruitment app with co-founders Tobias and Juan. When Covid hit however, Gronda transformed into a platform for chefs to share and monetize their recipes, inspiring other culinary lovers. Next, Gronda wants to help ambitious chefs worldwide unleash their full potential.
Next, a few more stories from around the world:
  • Clara runs a longevity clinic in rural Valencia where people learn to live a longer, healthier life. It’s powerful knowledge and she knew it could go far beyond her little village, so with husband Juan and his university friend David, they created their company Hearts Radiant. Their app, Rosita, gives seniors long term physical and mental health plans, some spanning ten years or more.
    #WeArePlay Juan Clara & David Rosita Longevity Cofrentes, Spain Google Play
  • When Noel from Argentina was traveling the world, he discovered he’d missed a beautiful viewing point in Italy. This gave him the idea for NoFilter - an app compiling the best photography spots around the world. Next, Noel wants to launch more features for customized trip planning and offer travelers options to go carbon neutral.
    #WeArePlay Noel Broda Noel Cordoba, Argentina Google Play
  • After a series of hackathons and coding all-nighters, top students Amiraslan and Orkhan launched Oxuyan (“scholar” in Azerbaijani), a platform for publishing exams and testing knowledge. Education had been a ticket to so much opportunity for Amiraslan, including studying abroad and traveling Europe, so his motivation was to make learning accessible to everyone.
    #WeArePlay Amiraslan & Orkhan Oxuyan Baku, Azerbaijan Google Play

    Check out all the stories now at g.co/play/weareplay and stay tuned for even more coming soon.


    How useful did you find this blog post?

Hundreds of thousands of developers are learning Jetpack Compose

Posted by the Android teamJetpack Compose is Android’s modern UI toolkit which is used by many well-known apps such as Pinterest, SoundCloud and Lyft. It enables developers to more intuitively and efficiently build better quality Android apps. To help developers around the world take advantage of these benefits, we launched Compose Camp, an Android meetup series where developers were able to learn Jetpack Compose, network with peers, and work on hands-on coding projects together, with the guidance of “Camp Leaders” who facilitated the sessions.

Illustration of a hexagonal shaped, Compose Camp scout badge
To help developers across different experience levels, Compose Camp offered 2 tracks. The beginner track was aimed at individuals new to Android development or coding. In this track, developers learned the basics of building Android apps and how to create UI with Compose. The experienced track was designed to help developers who were already familiar with building for Android, but wanted to learn how to use Jetpack Compose. Developers learned more advanced concepts in layouts, theming, architecture, migration, and more.


Campers around the world

It was great to see hundreds of thousands of you around the world participate in Compose Camp! Whether it was through a Google Developer Group, Google Developer Student Club, with your peers and colleagues, or if you went “solo-camping” and took the course on your own, we saw how many of you were engaged in the learning materials, recorded your sessions so you can help others, and shared your projects on social with #ComposeCamp.
Headshot of Rahul Sain, smiling
We heard from Rahul Sain, an enthusiastic Android developer who was a Compose Camp Leader for GDSC Bhagwan Parshuram Institute of Technology - Delhi. 
“Compose Camp enabled me to educate others about new technologies used by developers, and helped me learn about them in the process. Our college now has a group of fellow developers who concentrate solely on the development of Android apps."
 Rahul has built several of his own apps, including Scribble.io, which he built using Jetpack Compose. 
 “I used Jetpack Compose in my published game, which has received more than 10,000 installs in the first three months of its release!”
Photograph of Madona Wambua smiling and interacting with her students during a Compose Camp session
We also had the opportunity to hear from Madona Wambua, a Google Developer Expert and Senior Android Engineer at Western Governors University, residing in New York. She visited Kenya for an extended vacation, during which she led Compose Camp sessions through the Google Developer Group and Women Techmakers Nairobi chapters. Madona led her students through the beginner track of Compose Camp, and added additional activities to keep students engaged as her fun spin on the program. 
“Compose Camps are engaging and fun! Some of my favorite parts were when the students saw how cool it was to use one language to write the UI, and asked questions about Kotlin. I love teaching; when I see my students solving problems together, sharing ideas, and learning how easy it is to write their UI in Compose, this warms my heart.”

If you’re looking to lead a learning session with your peers, check out the Compose Camp Organizer Guide for everything you need to lead an Android development workshop.


Learning tips from the community

Everyone has different methods for learning something new, so we asked Compose Camp participants to share their favorite tips and tricks for learning Jetpack Compose, and these were some of our favorite answers. We hope they help you on your Android development learning journey:

“Check out the Compose samples and the Now in Android(NiA) app from Android on GitHub. They are great assets for learning Compose best practices! 😍😊” -Odin from Norway

“Use [the] Accompanist animation library to add cool animations in your Compose UI.” -Mansi from GDG Ahmedabad in India

“One magic word for Android developers’ ears, Modifier. Make round edges, draw borders, and set shadows with ease. Learn Modifier, and the flexibility of customization [in] your UI elements is insane.” -Ban from Montenegro

“@PreviewParameter provides sample data for Composables, which allows a preview of the Composable and accelerates development by providing sample data.” -Google Developer Expert Nav Singh from GDG Montreal in Canada

For more tips on learning Compose, check out the Compose Basics series on the Android Developers YouTube channel.
Illustration of three diverse, happy Compose campers looking at a laptop device

Advance your learning and get started with Compose

We recommend using Jetpack Compose if you’re looking to build a new app, and you can use the same development concepts to extend your app to tablets, foldables, and Wear OS. In case you missed Compose Camp or if you’re looking to deepen your learning, you can take the Jetpack Compose for Android Developers or the Android Basics with Compose courses online now. For additional Android learning opportunities in your local area, check out our Google Developer Communities near you.

Happy Composing!

Control when changes to your app are sent for review with new Play Console features

Posted by Steve Suppe, Product Manager, Google Play and Manuel Wang, Product Manager, Google Play; Ashley Marshall, UX Writing Lead, Google Play Google Play Console is constantly evolving to improve how you manage and publish your apps. We know that launch moments are really important to you. Whether that's launching a new version of your app, or updating your store listing – you need the right tools to help you launch with confidence.

One challenge you’ve shared with us is a lack of predictability and control over the app review process. Previously, it was hard to predict which changes would be sent to Google for review, and which changes would be published immediately. There was also no way to send multiple changes for review together, for example, if you wanted to update your app at the same time as one of your store listing screenshots.

As a result of your feedback, we're making some changes to give you more flexibility and control over the app review process.

Control when changes are sent to Google for review

On the Publishing overview page in Play Console, you’ll soon see a new section called “Changes ready to send for review.” Whenever you save a change in Play Console that is subject to review, it will be listed here – instead of it being automatically sent for review. You can then send these changes for review together, whenever you’re ready.

ALT TEXT
On the Publishing overview page in Play Console, you’ll soon see a new “Changes ready to send for review” section where your changes will be saved  for you to send for review.

How this works with managed publishing

Once you send changes to Google for review, they'll appear in the “Changes in review” section on the Publishing overview page.

If you have managed publishing turned on, these changes will appear in the “Ready to publish” section as soon as they're approved. You can then publish these changes whenever you're ready.

If you have managed publishing turned off, changes will be published automatically as soon as they're approved. We recommend turning managed publishing on when you want more control over app changes or wish to push an app update live at a specific time.

Remove changes that are ready to publish or in review

To give you even more flexibility, we're also adding the ability for you to remove changes that have already been sent for review, or that are ready to publish.

Changes you remove will once again appear in the “Changes ready to send for review” section.

How it works

Here's an example of how we think these new changes will add predictability and control to your app publishing process, and how they will enable more flexible workflows.

Imagine you have a major update to your app that is due to go live and requires several changes to happen at the same time, such as publishing a new release, updating your store listing screenshots, and making changes to your Data safety form. Here's how this would look with all of the new improvements that we've made in Play Console.

1.    Make changes to your app, store listing, and Data safety form in Play Console

You can make changes to all of the different parts of your app at your own pace, with confidence that these changes won't be sent for review or published until you're ready.

2.    Send changes for review when you're ready

On the Publishing overview page, you'll now see all of the changes that have been made. You can send them for review together when you decide you’re ready.

3.    Remove changes if you've made a mistake

Imagine that you've made a change to something else by accident, or your marketing team has told you that some of the screenshots you originally uploaded need to be changed. On the Publishing overview page, you can now remove these changes from the review, make any necessary updates, and send the changes for review – again.

4.     Publish according to your schedule with managed publishing

Plans change all the time. Imagine that your marketing team tells you that your launch date has been delayed by a week. Or, what if you don't want your changes to go live on a weekend, when no one is in the office? You can choose to turn on managed publishing and control exactly when approved changes are published.

We’re really excited to share these upcoming features with you, and hope these changes give you more predictability and control over the app publishing process.


How useful did you find this blog post?

★ ★ ★ ★ ★



Android Studio Electric Eel

Posted by Paris Hsu, Product Manager, Android Developer
Android Studio Electric Eel splash screen

Today, we are ⚡️electrified⚡️ to announce the latest stable release of the official IDE for building Android applications: Android Studio Electric Eel (2022.1.1)!

This release includes updates and new features that cover across design, build & dependencies, emulators & devices, and IntelliJ. Read or watch below to learn more about how they can help you more productively build apps, and download the latest stable version today to try it out for yourself!

Design

Compose Preview updates automatically - In earlier versions of Android Studio, you had to manually refresh Compose Previews after making changes. In Electric Eel, Previews update automatically after you make compatible code changes in the same file, allowing you to iterate on your UI faster. If your code change was incompatible, Previews will show a “Needs Rebuild” status to indicate needing a full build. When your code contains compilation errors during editing, Previews are temporarily paused, and then resumed again when the errors are fixed.
Moving image of a screenshot of Compose Preview updating automatically
Compose Preview updates automatically
Compose Preview device spec - Another update for Compose Preview is that you can now edit the device parameter of the Preview annotation to specify the configuration of the device. You can choose from reference devices or create your own, in which case autocomplete will help you with what options are available and what values they accept. This works together nicely with multipreview annotations, which are available since Dolphin.
Screenshot of Compose preview device spec
Compose Preview Device Spec
Layout Inspector recomposition rendering highlights: To make it easier to quickly see which of your composables are recomposing, Layout inspector now highlights recomposition. This allows you to identify where in the application the most recent activity caused the highest changes in recomposition counts. The UI elements with the most recent changes are temporarily overlaid with a color. This makes it easy to track down unexpected or excessive recompositions happening in your app. You can learn more about using the layout inspector to debug recomposition in Jetpack Compose: Debugging Recomposition.
Moving image of screenshot showing Layout Inspector recomposition rendering highlights
Layout Inspector recomposition rendering highlights
Visual Linting for Views: New for XML layouts, Visual linting now runs in the background to check for issues across different form factors, detecting problems such as overlapping or non-visible elements on a given device configuration.

For example, in the animated screen capture below, you can see that the layout file has two validation problems: a TextView covered by an ImageView on certain screen sizes and an ImageView, which is partially out-of-bounds in some configurations. Clicking on the problem in the Problems panel will open the Layout Validation panel to see your layouts rendered for the various device sizes and highlight the configurations with the selected issue.
Moving image of screenshot showing Visual Linting for Views
Visual Linting for Views
Universal Problems Panel: We have consolidated all the problems reported by various tools within Android Studio into the new Problems panel. This includes visual linting, navigation, and Compose related issues.

Screenshot showing the universal problems panel
Universal Problems Panel

Build & Dependencies

Improved Sync performance with parallel project imports: Parts of Gradle Sync now run in parallel by default; this can result in significant speedups for very large projects. Square has reported that their Gradle Enterprise metrics show an average reduction of 60% in sync times, saving an estimated 1,600 hours in developer productivity per year. Note: These improvements are specific to the time it takes Gradle to build models and don't change the performance of the IDE's processing of those models.

Download impact in Build Analyzer: The Build Analyzer tool provides you insight into what happens during your builds. This now includes a summary of any dependency downloads that happened. You can use this information to determine the impact of downloads on your build, and to spot problems such as downloads happening during incremental builds.

The information of the download impact is broken down by repositories, so you can see where each dependency was downloaded from. You can also see if a repository takes a long time to serve artifacts, or has a high number of failed requests. If that’s the case, you should consider removing the repository, if possible, or moving it lower in your repository configuration, so that other repositories take priority over it.
Moving image of Screenshot showing the build analyzer
Download impact in Build Analyzer
Upgrade Assistant post-upgrade report and rollback support: The Upgrade Assistant that helps you upgrade your project’s Android Gradle Plugin version also got more helpful in Electric Eel. After performing a version upgrade, the assistant will attempt to sync your project, and report whether it was successful. It now also gives you a summary of what steps were executed. Moreover, if the project sync fails after the upgrade, you can use the new Revert button to undo the changes to your build files.
Moving image of Screenshot showing Upgrade Assistant post-upgrade report and rollback support
Upgrade Assistant post-upgrade report and rollback support
SDK Index integration: We announced Google Play SDK Index earlier this year, which provides you information about various SDKs that you can integrate into your app. SDK developers can mark versions of their SDKs as outdated in the SDK index, and this information is now shown directly in Android Studio.

If you’re using a version marked as outdated, you’ll see a lint warning on the dependency in your build file to let you know that you should update it. Similarly, the Project Structure Dialog will show the same warnings on the outdated dependencies, and you can navigate to their Play SDK Index page from there to learn more.
Moving image of Screenshot showing SDK Index integration
SDK Index integration
Baseline Profile fix for App Bundles: Under certain circumstances Baseline Profiles could have been compressed when the app was built as an Android App Bundle. This resulted in the profile not being picked up when installing the app locally. In this local only scenario, benchmark results would be slower than anticipated. The bundletool version shipping with Electric Eel addresses and fixes this problem.

Inspect

All-new Logcat: Logcat has been rewritten from the ground up to make it easier to parse, query, and track logs. The new Logcat UI has been available to try as an opt-in feature in Dolphin, and it’s now enabled by default in Electric Eel, including a number of quality-of-life and stability fixes. Some highlights include better formatting for logs, a smarter search field with autocomplete support to filter for the logs you want to see, ability to persist log output across app restarts, and options to customize what’s displayed.
Moving image of Screenshot showing Logcat New UI
Logcat New UI
App Quality Insights window: The new App Quality Insights tools let you browse and investigate crash data from Firebase Crashlytics directly in Android Studio without having to jump back and forth between the IDE and a browser.

The IDE displays your top issues, which you can filter to show only the most recent crashes, or crashes from a specific version of your app. For each issue, you can see the number of affected users and the stack trace, which allows you to quickly navigate to the place in your code where the crash occurred. Moreover, you’ll see gutter icons in your source files, which indicate parts of your code that show up in your app’s top crash reports. Simply click on the link to navigate from the code to the crash report in the App Quality Insights window. To get started, read the official documentation.
Moving image of Screenshot showing App Quality Insights window
App Quality Insights window

Emulators & devices

New "Desktop" category & Desktop AVD: In Electric Eel, you now have the option to create a Desktop emulator. This lets you test how your app behaves on devices such as Chromebooks. There are a handful of interactions that are different on these devices that you should test with your app. For example, apps can be freeform resized or minimized, which your app should handle gracefully.
Moving image of Screenshot showing Testing apps on new Desktop AVDs
Testing apps on new Desktop AVDs
Resizable Emulator (Experimental): The Resizable emulator helps you test your app on different screen sizes without having to run multiple emulators. After creating and launching a resizable emulator, you can use the Display Mode menu to switch between different reference device sizes and see how your app behaves.
Moving image of using the Resizable Emulator
Using the Resizable Emulator
Physical Devices Mirroring (Experimental, Opt-in): You can now mirror your physical device to Android Studio and interact with it similarly to how you’d use an emulator. This is an opt-in feature in Electric Eel so that you can share feedback with us. In order to use it, you need to first go to Preference > Experimental > Device Mirroring to enable it. Then, connect your physical device through ADB (either through wired or wireless), and it will show up in the Running Devices panel. Once mirrored, you can interact with it much like you’re used to with emulators, such as multi-touch, physical buttons, and device rotation. Mouse and keyboard events are forwarded, and you can use the controls on the toolbar to input button presses, or to rotate the device.
You can also drag and drop files onto the mirrored device (just like on an emulator). If the file is an APK, it will be installed, which can be really useful for quickly testing a build. For other file types, the file will be copied to the device’s Download folder.
Moving image of physical devices mirroring in Android Studio
Moving image of physical devices mirroring on Physical Device
Physical Devices Mirroring (Android Studio and Physical Deice)

IntelliJ

IntelliJ Platform Update - Android Studio Electric Eel (2022.1.1) includes the IntelliJ 2022.1 platform release, which has many new features such as Dependency Analyzer to facilitate dependency management and conflict resolution and the Notifications tool window that offers a new, streamlined way to receive notifications from the IDE. It also includes a number of other notable improvements that are covered here.

To recap, Android Studio Electric Eel (2022.1.1) includes these new enhancements & features:

Design

  • Compose Preview updates automatically
  • Compose Preview device spec
  • Layout Inspector recomposition rendering highlights
  • Visual Linting
  • Universal Problems panel

Build & dependencies

  • Improved Sync performance with parallel project imports
  • Download impact in Build Analyzer
  • Upgrade Assistant post-upgrade report and rollback support
  • SDK Index integration
  • Baseline Profile fix for App Bundles

Emulators & devices

  • New "Desktop" category & Desktop AVD
  • Resizable Emulator (Experimental)
  • Physical Devices Mirroring (Experimental, Opt-in)

IntelliJ

  • IntelliJ Platform 2022.1 Update

Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.

Download Studio Today!

It is a good time to download Android Studio Electric Eel (2022.1.1) to incorporate the new features into your workflow. As always, we appreciate any feedback on things you like and issues or features you would like to see. If you find a bug or issue, please file an issue and also check out known-issues. Remember to also follow us on Twitter, Medium, or YouTube for more Android Development updates!

Extending the Android SDK

Posted by Anton Hansson, Software EngineerAndroid 10 and higher support Modular System Components that allow us to expedite functional and security updates to the Android ecosystem outside of major API level releases and make new functionality backward compatible on already-released Android versions. These improvements help make development more flexible and broaden the reach for app developers. We've built a new Extension SDK framework for you to integrate with these APIs, and today, we’re releasing the first public version of the Extension SDK (Extension Level 4).

Faster API and feature introductions

Having the ability to introduce new functionality outside of major API level releases allows faster innovations. As shared in a previous post, beginning this year we plan to roll out the initial Privacy Sandbox on Android Beta release to Android 13 devices. You can start using the Extension SDK to integrate your solutions with the AdServices APIs to prepare for limited production testing. Learn more on how to participate in the Privacy Sandbox Beta release, and set up your development environment with a test device or emulator.

Backward compatibility

Extension SDKs also allow us to extend the support of certain platform functionality to existing Android versions, increasing user reach. For example, the PhotoPicker APIs previously available only on API level 33 (Android T) and above are now also available all the way back to API level 30 (Android R) through the Extension SDK on devices with an R extension version of at least 2.
Moving image showing Photopicker API in action on a cellphone screen

Check for API availability

To help you identify extension API availability, we’ve added additional information to the API reference that indicates for which API levels and the minimum extension versions that the API is available. For example, the API reference for ACTION_PICK_IMAGES indicates its availability on “Android R Extensions version 2” and above.
Action_Pick_Images link Added in API level 33 Also in R Extensions 2
You can query the extension version at runtime in a similar way to how Build.VERSION.SDK_INT is commonly used to check for the Android version. For example, if you need to verify the availability of the PhotoPicker APIs, use the new API SdkExtensions.getExtensionVersion. For the R extensions, the version code (30) that corresponds to R is used:
fun isPhotoPickerAvailable(): Boolean { return SdkExtensions.getExtensionVersion(VERSION_CODES.R) >= 2 }

The alternative check, via Build.VERSION.SDK_INT, would look like this:

fun isPhotoPickerAvailable(): Boolean { return Build.VERSION.SDK_INT >= 33 }

This check is still safe and correct, but this function would return false on some devices where the API is now available. As a result, the SDK_INT check is not optimal, and the extension version check is a better way to check for API availability. All devices with SDK_INT >= 33 also have an R extension version of >= 2, but there are devices with SDK_INT < 33 with R extension versions >= 2.

Similarly, the AdServices API reference may indicate that it’s “added in Ad Services Extensions 4”. The Ad Services extension uses the SdkExtensions.AD_SERVICES constant. The availability check looks like this:

fun isAdServicesAvailable(): Boolean { return SdkExtensions.getExtensionVersion(SdkExtensions.AD_SERVICES) >= 4 }

For developer convenience, we are extending Jetpack to make it easier to work with extension versions. For example, you can use a Jetpack library function to check for PhotoPicker availability, which abstracts away the conditional version checks. We expect to be releasing more Jetpack libraries (such as the Privacy Preserving APIs in the Privacy Sandbox) to aid the correct use of APIs released via Extension SDKs.

Tooling support

To help ensure app quality, we added Extension versions tooling support to Android Lint's NewApi check. Since Android Studio Flamingo, it can auto-generate the correct version checks for APIs that have been launched via SDK extensions. Using these new version checks is completely optional, but adopting them could help lead to more widespread use of new APIs when they exist.
Screen grab of version check in use

Get familiarized with SDK extensions

We’re just beginning the SDK Extension developer journey and plan to make more features available in the future. You can get the latest SDK extension 4 available in the SDK Manager today. Learn more about the SDK Extensions and our documentation on the Privacy Sandbox Beta and the photo picker.