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.
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.
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.
Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.
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.
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.
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.
We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.
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%.
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.
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.
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.
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.
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.
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
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.
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.
adb
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:
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.
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.
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.
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.
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).
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.
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.
Key areas where we are seeking feedback
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.
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?
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.
“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."
“I used Jetpack Compose in my published game, which has received more than 10,000 installs in the first three months of its release!”
“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.
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
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!
Posted by Diego Zavala - Product Manager, Lee Campbell - Tech Lead
Today, we are glad to announce the alpha release of Credential Manager, a new Jetpack API that allows app developers to simplify their users' authentication journey, while also increasing security with support of passkeys.
Credential Manager supports multiple sign-in methods, such as username/password, passkeys, and federated sign-in solutions (e.g., Sign-in with Google) in a single API, thus simplifying the integration for developers. Furthermore, for users, Credential Manager unifies the sign-in interface across authentication methods, making it clearer and easier for users to sign-in to apps, regardless of the method they choose.
Since our update in October 2022, we’ve been expanding support for passkeys - the new industry standard for passwordless authentication - across Android and Chrome. Credential Manager allows users to create passkeys and store them in Google Password Manager. Their passkeys will sync across all of their devices that are signed in to the same Google Account, allowing users to seamlessly sign in to apps that support passkeys across these devices.
Please stay tuned for more updates from us throughout this year, as we roll out third-party password manager support to integrate with Credential Manager.
To make sign-in easier in your app use Credential Manager. Visit this Android Developer guide to learn more.
We'd love to hear your inputs during this alpha release, so please let us know about your experience integrating with Credential Manager, using passkeys, or any other feedback you might have:
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.
As a result of your feedback, we're making some changes to give you more flexibility and control over the app review process.
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.
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.
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.
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 mistakeImagine 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.
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.
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.
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.
★ ★ ★ ★ ★
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)!
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.
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:
Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.
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!
.png)
