Category Archives: Android Developers Blog

An Open Handset Alliance Project

How Stripe leveraged Google Play to build an SDK for Tap to Pay on Android

Posted by the Stripe and Android teams

What is Stripe Terminal and what does it offer Android developers?

Stripe Terminal is a set of tools for accepting in-person payments, including developer

interfaces, card readers, and logistics management. Android developers can build in-person commerce experiences with the Terminal Android SDK and the Tap to Pay on Android SDK. The Terminal Android SDK allows users to go to market with Stripe’s pre-certified card readers, and the Tap to Pay on Android SDK enables merchants to accept contactless payments on their existing compatible Android devices. The Tap to Pay on Android SDK eliminates the need for additional hardware, allowing POS providers and their users to quickly scale, increase revenue, and reach new markets. Both SDKs integrate seamlessly with the Stripe platform, so businesses can manage online and in-person payments in one place. Existing Terminal users have integrated Tap to Pay on Android with the Stripe Terminal SDK in just a couple of weeks.

Moving image of a transaction being completed on an Android device with Tap to Pay on Android SDK

Stripe has used Google Play SDK Console since the product’s launch in 2020 to monitor the performance of our SDKs, including the Terminal Android SDK and Android SDK for online payments. Google Play SDK Console is a platform for widely-used commercial SDKs to share important updates with developers—such as critical issues related to recent releases—and provide precise mitigation instructions for out-of-date SDK versions. Features of Google Play SDK Console such as usage statistics, crash reporting, and version reporting make it possible for SDK providers such as Stripe to streamline communication with customers and help keep a pulse on the health of their SDKs.

How have Google Play features shaped the development of the Tap to Pay on Android SDK?

Security was key to the development of the Tap to Pay on Android SDK due to the need to secure sensitive card data for the acceptance of contactless payments on a broad range of consumer devices. We originally incorporated the SafetyNet Attestation API into our broader security strategy for Terminal to address the need for device attestation. Looking ahead to 2023, we plan to use the new Play Integrity API, which replaced SafetyNet Attestation and offers device attestation and other integrity services. The Play Integrity API will also help us meet the recently published PCI MPoC (Mobile Payments on COTS) standard for mobile payment acceptance solutions. This standard requires Stripe to verify that Android applications using the Tap to Pay on Android SDK are unmodified, and that those applications have been installed from a trusted source like the Google Play Store. The Play Integrity API will not only help us meet industry standards, but will also mitigate the risk that a compromised device or application could be used to collect payments, which protects Stripe users and upholds the security of payments made using the Tap to Pay on Android SDK.

In addition to security, ubiquity across Android devices has also been a driving force in the development of the Tap to Pay on Android SDK. A fundamental goal for Stripe was to build a solution that would work on a wide range of consumer and enterprise Android devices. The decision to use the Play Integrity API was therefore also largely influenced by the appeal of Google Mobile Services and the wide range of functionality afforded by its associated APIs and applications.

What is Stripe planning next for the Tap to Pay on Android SDK?

We’re excited to partner with Google as an early adopter of the Play Integrity API for SDKs. This will allow the Stripe SDK to access the Play Integrity API with an API key, streamlining the experience for developers using the SDK as they won’t have to separately integrate with the Integrity API. Google plans to offer this to more SDKs in 2023.

Where can I learn more about Stripe’s Tap to Pay on Android SDK?

Visit our Tap to Pay page for more information. Tap to Pay on Android is currently available through the Stripe Terminal Android SDK in the US, Canada, the UK, Singapore, Australia, and New Zealand. Reach out here to start building.

Source: Android Developers Blog

Feature Engineering in the Google Play Store

Posted by Harini Chandrasekharan, Staff Software Engineer, Google Play

The Google Play Store, launched 10 years ago in 2012 sits at the heart of Android, connecting billions of users with an equally staggering and ever-growing collection of apps and games worldwide.

Let's take a peek behind the curtains to learn what it takes to design the serving infrastructure of the worlds largest Android marketplace. In the world of consumer facing software, it's not a surprise that out of box engineering solutions fail to meet the requirements that Google scale demands. Therefore every system at Google is carefully crafted and honed with iterative enhancements to meet the unique availability, quality and latency demands of the Google Play Store.

What is feature engineering?

Features can be user-facing such as formats, content, arrangement of content, the page layout or information architecture. Formats represent how app content from our recommendation systems, advertisers, merchandisers and various other sources are presented on UI. The goal is to create tailor-made experiences weaving in the right content and UI to suggest the most relevant apps and games to meet the users where they are in their journey on the play store.

In the domain of consumer facing features, users’ opinions and choices, developer ecosystem and demand often changes faster than infrastructure can. In such an environment, the biggest challenge engineers face is how to be nimble and design infrastructure that’s not only future-proof but also meets the needs of the consumer space within the constraints of scalability and performance. Let’s take a deeper look at some engineering challenges in such a dynamic space.

What does success look like?

In a data driven organization such as the Play store, metrics are built for measuring anything and everything of importance. Here are some of the dimensions that come in handy when measuring and tracking success:

Product/business metrics - These are metrics specific to the product or service under consideration. Running A/B experiments to measure changes to these metrics for the new treatment builds confidence, particularly when decision making involves several tradeoffs.
Performance - Measuring latency, error rates and availability makes the backbone of almost every service and for good reason. Knowing these baseline metrics is essential since this closely tracks user experience and perception of the product.
System health - These are internal system metrics tracking resource utilization and fleet stability.

Challenges in feature engineering infrastructure

Designing backend systems that scale to the requirements of the Play Store that also meet the performance criteria required to make user interactions feel fluid and responsive is paramount. From an engineering perspective, infrastructure needs to continuously evolve to meet the needs of the business. The Play store is no different—the store infrastructure has evolved several times in the last decade to not only support the needs of new features that are available to users today, but also to modernize, eliminate tech debt and most of all reduce latency.

Frequent iteration

Challenge: Features often require large amounts of iteration over time, it's hard to plan engineering infrastructure that meets all the future requirements.

In an experiment driven culture, the optimum approach for rapidly building features at scale often results in tech debt. Tech debt has various forms—relics of past features that did not make it result in layers that are hard to clean up, affect performance, make code error prone and hard to test.

Independent evolution

Challenge: In large organizations spanning 100s of engineers, several features are often being built in parallel and independent of each other.

Infrastructure reuse and sharing innovations are often impossible without significantly compromising on velocity. In a space where the product evolves at a rapid pace there is often a large amount of uncertainty with the different levers and knobs one can build into systems to make them flexible. Too many levers can lead to large system complexity. Too few levers and the cost of iteration is sky high. Finding the balance between the two is one of the core competencies of a feature engineer in this space.

Time to experiment

Challenge: There is often an opportunity cost to pay for time spent building elegant engineering solutions.

Time to experiment is one of the most important metrics to keep in mind when designing solutions for user facing features. Flexible design that enables rapid iteration and meets the latency and other performance SLOs is ideal.

In practice, there is often a large amount of guesswork that goes into estimating impact of a particular user facing change, while we can use past data and learnings confidently to estimate in some scenarios, it's not sufficient for a brand new ambitious, never before tried idea.

Feature engineering guiding principles

Let’s see how the Play Store solves these challenges to enable state of the art innovation.

Data driven experiments and launches - understand your success metrics

Optimizing for time to market i.e getting the feature to the user and measuring how it impacts app installs and other store business metrics using A/B experiments is of prime importance. Iterating fast based on data helps tune the final feature to the desired end state. Google has several home grown technologies for running A/B experiments at worldwide scale with seamless integration with metric presentation tools that make running these experiments smooth and easy, so developers can spend more time coding and less in analysis.

Design and experiment with polished MVPs - with a focus on quality

Deciding what to build, whether it meets Google quality standards, understanding engineering costs and the user needs it solves are all important questions that need to be answered before designing anything. Feature Engineering is therefore often done in close collaboration with Product Managers. Aligning on the perfect MVP that can be built in a reasonable amount of engineering time that meets the user journey is the key to a successful product.

Frequently modernize the infrastructure - clean up tech debt

Frequent iterations and a fast MVP development culture often comes with its set of cons, the biggest being tech debt. In optimizing for fast velocity, cutting corners results in obsolete code (due to unlaunchable metrics) or discarded experiment flags. These often make testing, maintaining and impact future development velocity if left unfixed. Additionally, using the latest and greatest frameworks to get to the last milliseconds of latency or making development easier yields great dividends in the long run. Frequently modernizing the infrastructure either via refactoring or full rewrites may traditionally spell signs of poorly designed code, but it's one of the bigger tradeoffs that feature engineers often have to make, because after all what use is all the fancy infrastructure if users don't interact with the feature in the first place!

How useful did you find this blog post?

★ ★ ★ ★ ★

Source: Android Developers Blog

API desugaring supporting Android 13 and java.nio

Posted by Clément Béra, Software engineer

We are happy to announce the release of a new version of API desugaring based on Android 13 and Java 11 language APIs. API desugaring allows developers to use more APIs without requiring a minimum API level for your app. This reduces friction during development. You are now free to use the java.nio APIs no matter which Android version is on the user’s device. For example, libraries such as kotlin.io.path are now available on all Android devices, including devices running Android 7 and lower.

In addition to supporting java.nio, API desugaring of java.time and java.util.stream has been updated to support APIs added up to Android 13. You can use recent APIs in your Android app such as Collectors#toUnmodifiableList.

New API desugaring specifications

To enable API desugaring, you set isCoreLibraryDesugaringEnabled and add the coreLibraryDesugaring dependency in the build.gradle.kts file.

android {
   ...
   compileSdk = 33

   defaultConfig {
       ...
       // Required when setting minSdkVersion to 20 or lower.
       multiDexEnabled = true

       ...
   }

   ...
   compileOptions {
       // Flag to enable support for API desugaring.
       isCoreLibraryDesugaringEnabled = true
      
       // Sets Java compatibility to Java 8
       sourceCompatibility = JavaVersion.VERSION_1_8
       targetCompatibility = JavaVersion.VERSION_1_8

   }
   kotlinOptions {
       jvmTarget = "1.8"
   }
}

dependencies {
 // Dependency required for API desugaring.
 coreLibraryDesugaring("com.android.tools:desugar_jdk_libs_nio:2.0.2")
}

The new version 2.0 release comes in 3 flavors:

com.android.tools:desugar_jdk_libs_nio:2.0.2 - the nio version includes all the desugaring available including the java.nio, java.time, stream, and functions APIs.
com.android.tools:desugar_jdk_libs:2.0.2 - the default version includes desugaring for the java.time, stream, and functions APIs. It’s similar to version 1.x API desugaring already available, but updated with APIs added up to Android 13.
com.android.tools:desugar_jdk_libs_minimal:2.0.2 - the minimal version includes only the java.util.function package and bug fixes on concurrent collections. It’s designed for minimal code size overhead.

Opting into more desugaring features will lead to a larger impact on your app’s code size. The minimal specification has, as its name indicates, a minimal impact on the code size of the app. The nio specification has the most impact.

The new java.nio APIs

The new java.nio APIs supported in API desugaring include:

All the classes and APIs in java.nio.file such as BasicFileAttributes, file manipulation, or usage of java.nio.file.Path.
Some extensions of java.nio.channels, such as the FileChannel#open methods.
A few utility methods such as File#toPath.

The following code snippet illustrates how you can now use the new java.nio APIs on all devices, including devices running Android 7 and lower, through the methods of kotlin.io.path which depend on java.nio.file.Files. A temp file can be created, written into, read, and its basic attributes and its existence can be queried using the new java.nio APIs.

import android.util.Log
import java.nio.file.StandardOpenOption.APPEND
import kotlin.io.path.createTempDirectory
import kotlin.io.path.deleteIfExists
import kotlin.io.path.exists
import kotlin.io.path.fileSize
import kotlin.io.path.readLines
import kotlin.io.path.writeLines

...
val TAG = "java.nio Test"
val tempDirectory = createTempDirectory("tempFile")
val tempFile = tempDirectory.resolve("tempFile")
tempFile.writeLines(listOf("first"))
tempFile.writeLines(listOf("second"), options = arrayOf(APPEND))
Log.d(TAG,"Content: ${tempFile.readLines()}")
Log.d(TAG,"Size: ${tempFile.fileSize()}")
Log.d(TAG,"Exists (before deletion): ${tempFile.exists()}")
tempFile.deleteIfExists()
Log.d(TAG,"Exists (after deletion): ${tempFile.exists()}")

// Resulting logcat output.
Content: first second
Size: 13
Exists (before deletion): true
Exists (after deletion): false

A few features however cannot be emulated for devices running Android 7 and lower and instead throw an instance of UnsupportedOperationException or return null. They still work on devices running Android 8 or higher, so existing code guarded by an API level check should work as it used to. See the complete list of APIs available and the known limitations.

The code has been extensively tested, but we are looking for additional inputs from app developers.

Please try out the new version of API desugaring, and let us know how it worked for you!

For additional background see the post Support for newer Java language APIs from when API desugaring was introduced.

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

Source: Android Developers Blog

Enable next generation IDs for better Play Games Services support for all Google accounts

Posted by Laura Nechita, Software Engineering at Google Play and Victor Chen, Product Specialist at Google Play

To further enhance the privacy of users and their multi-platform gaming experience, Play Games Services (PGS) is introducing next generation Player IDs. With this change, the first time a user plays a game, they will always be assigned a unique next generation Player ID that will remain consistent regardless of the device or platform a user plays a game on, but which will vary from game to game.

Existing users, or accounts that have already signed into your game using PGS retain their current PGS Player IDs and are not affected by this change. If you have multiple titles in your portfolio and need a way to identify users across your titles to offer cross-game user experiences, we are also introducing a developer player key. Learn more.

With next generation IDs, it will also enable better Play Games Services support for all accounts, including those under supervision.

Here is a timeline for the rollout:

Feb 16, 2023	You can start testing next generation IDs using PGS test accounts You can publish this feature once you have completed your testing
Apr 15, 2023	Next generation IDs are enabled in draft mode for newly created game projects You can disable next generation IDs on the game properties page in Google Play Console
Feb 2024	Next generation IDs will be turned on in production for all game projects (including existing game projects) If you notice any issues during this period you will have one month to disable next generation IDs and fix the issue
Mar 2024	Next generation IDs are required for all game projects and cannot be disabled

How this affects your game

Next generation IDs are only assigned to users signing in to PGS on your game for the first time.
Users who have already signed in to PGS on your game are not affected.
We are introducing a new developer player key which allows you to identify users across games in your portfolio.

Source: Android Developers Blog

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.

Source: Android Developers Blog

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.

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 right

In 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.

Source: Android Developers Blog

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.

Working across devices and form factors

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

Optimized broadcasts

Exact alarms

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%.

Per-app language preferences

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é”

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

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

Block installation of apps

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

App compatibility

App compatibility toggles in Developer Options

Get started with Android 14

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.

For complete information, visit the Android 14 developer site.

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

Source: Android Developers Blog

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

Sign up for the X-Requested-With in WebView Deprecation origin trial to continue receiving XRW header on webview. Changes to the header are expected to begin in WebView beta 111.
Provide feedback on impacted use cases and needs for replacement signals using the Chromium Bug Tracker.
The status of the roll-out of the header page can be seen on the Chrome Feature Status Page.

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

Source: Android Developers Blog

#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.
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.
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?
★ ★ ★ ★ ★

Source: Android Developers Blog

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.

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!