Tag Archives: latest

Making permissions auto-reset available to billions more devices

Posted by Peter Visontay, Software Engineer; Bessie Jiang, Software Engineer

Contributors: Inara Ramji, Software Engineer; Rodrigo Farell, Interaction Designer; James Kelly, Product Manager; Henry Chin, Program Manager.

Illustration of person holding phone

Most users spend a lot of time on their smartphones. Whether working, playing games, or connecting with friends, people often use apps as the primary gateway for their digital lives. In order to work, apps often need to request certain permissions, but with dozens of apps on any given device, it can be tough to keep up with the permissions you’ve previously granted – especially if you haven’t used an app for an extended period of time.

In Android 11, we introduced the permission auto-reset feature. This feature helps protect user privacy by automatically resetting an app’s runtime permissions – which are permissions that display a prompt to the user when requested – if the app isn’t used for a few months. Starting in December 2021, we are expanding this to billions more devices. This feature will automatically be enabled on devices with Google Play services that are running Android 6.0 (API level 23) or higher.

The feature will be enabled by default for apps targeting Android 11 (API level 30) or higher. However, users can enable permission auto-reset manually for apps targeting API levels 23 to 29.

So what does this mean for developers?


Exceptions

Some apps and permissions are automatically exempted from revocation, like active Device Administrator apps used by enterprises, and permissions fixed by enterprise policy.


Request user to disable auto-reset

If needed, developers can ask the user to prevent the system from resetting their app's permissions. This is useful in situations where users expect the app to work primarily in the background, even without interacting with it. The main use cases are listed here.


Comparing current and new behavior

Current behavior New behavior
Permissions are automatically reset on Android 11 (API level 30) and higher devices. Permissions are automatically reset on the following devices:
  • Devices with Google Play services that are running a version between Android 6.0 (API level 23) and Android 10 (API level 29), inclusive.
  • All devices running Android 11 (API level 30) and higher devices.
Permissions are reset by default for apps targeting Android 11 or later. The user can manually enable auto-reset for apps targeting Android 6.0 (API level 23) or later. No change from the current behavior.
Apps can request the user to disable auto-reset for the app. No change from the current behavior.


Necessary code changes

If an app targets at least API 30, and asks the user to disable permission auto-reset, then developers will need to make a few simple code changes. If the app does not disable auto-reset, then no code changes are required.

Note: this API is only intended for apps whose targetSDK is API 30 or higher, because permission auto-reset only applies to these apps by default. Developers don’t need to change anything if the app‘s targetSDK is API 29 or lower.

The table below summarizes the new, cross-platform API (compared to the API published in Android 11):

Action Android 11 API
(works only on Android 11 and later devices)
New, cross-platform API
(works on Android 6.0 and later devices, including Android 11 and later devices)
Check if permission auto-reset is enabled on the device Check if Build.VERSION.SDK_INT >= Build.VERSION_CODES.R Call androidx.core.content.PackageManagerCompat.getUnusedAppRestrictionsStatus()
Check if auto-reset is disabled for your app Call PackageManager.
isAutoRevokeWhitelisted()
Call androidx.core.content.
PackageManagerCompat.
getUnusedAppRestrictionsStatus()
Request that the user disable auto-reset for your app Send an intent with action
Intent.ACTION_AUTO_REVOKE_PERMISSIONS
Send an intent created with androidx.core.content.
IntentCompat.
createManageUnusedAppRestrictionsIntent()


This cross-platform API is part of the Jetpack Core library, and will be available in Jetpack Core v1.7.0. This API is now available in beta.

Sample logic for an app that needs the user to disable auto-reset:

val future: ListenableFuture<Int> =
    PackageManagerCompat.getUnusedAppRestrictionsStatus(context)
future.addListener(
  { onResult(future.get()) },
   ContextCompat.getMainExecutor(context)
)

fun onResult(appRestrictionsStatus: Int) {
  when (appRestrictionsStatus) {
    // Status could not be fetched. Check logs for details.
    ERROR -> { }

    // Restrictions do not apply to your app on this device.
    FEATURE_NOT_AVAILABLE -> { }
    // Restrictions have been disabled by the user for your app.
    DISABLED -> { }

    // If the user doesn't start your app for months, its permissions 
    // will be revoked and/or it will be hibernated. 
    // See the API_* constants for details.
    API_30_BACKPORT, API_30, API_31 -> 
      handleRestrictions(appRestrictionsStatus)
  }
}

fun handleRestrictions(appRestrictionsStatus: Int) {
  // If your app works primarily in the background, you can ask the user
  // to disable these restrictions. Check if you have already asked the
  // user to disable these restrictions. If not, you can show a message to 
  // the user explaining why permission auto-reset and Hibernation should be 
  // disabled. Tell them that they will now be redirected to a page where 
  // they can disable these features.

  Intent intent = IntentCompat.createManageUnusedAppRestrictionsIntent
    (context, packageName)

  // Must use startActivityForResult(), not startActivity(), even if 
  // you don't use the result code returned in onActivityResult().
  startActivityForResult(intent, REQUEST_CODE)
}

The above logic will work on Android 6.0 – Android 10 and also Android 11+ devices. It is enough to use just the new APIs; you won’t need to call the Android 11 auto-reset APIs anymore.


Compatibility with App Hibernation in Android 12

The new APIs are also compatible with app hibernation introduced by Android 12 (API level 31). Hibernation is a new restriction applied to unused apps. This feature is not available on OS versions before Android 12.

The getUnusedAppRestrictionsStatus() API will return API_31 if both permission auto-reset and app hibernation apply to an app.


Launch Timeline

  • September 15, 2021 - The cross-platform auto-reset APIs are now in beta (Jetpack Core 1.7.0 beta library), so developers can start using these APIs today. Their use is safe even on devices that don’t support permission auto-reset (the API will return FEATURE_NOT_AVAILABLE on these devices).
  • October 2021 - The cross-platform auto-reset APIs become available as stable APIs (Jetpack Core 1.7.0).
  • December 2021 - The permission auto-reset feature will begin a gradual rollout across devices powered by Google Play Services that run a version between Android 6.0 and Android 10. On these devices, users can now go to the auto-reset settings page and enable/disable auto-reset for specific apps. The system will start to automatically reset the permissions of unused apps a few weeks after the feature launches on a device.
  • Q1 2022 - The permission auto-reset feature will reach all devices running a version between Android 6.0 and Android 10.

App performance to drive app excellence

Posted by Maru Ahues Bouza, Director Android Developer Relations

hand drawing shapes on a tablet

In our previous blog post in this series, we defined app excellence as “creating an app that provides consistent, effortless, and seamless app user experiences. It is high performing and provides a great experience, no matter the device being used.” Let’s focus on the concept of app performance — what are the features of high performing apps, and how do you achieve app excellence through strong performance?

From a user’s perspective, high-performing apps “just work.” However, the process of creating a high performing app is not always straightforward. To break things down, here are the main dimensions of high performance:

Stability

An app should be robust and reliable. It should not freeze (application not responding, or “ANR”) or crash. Before you launch your app, check out Google Play’s pre-launch report to identify potential stability issues. After deployment, pay attention to the Android Vitals page in the Google Play developer console. Specifically, ANRs are caused by threading issues. The ANR troubleshooting guide can help you diagnose and resolve any ANRs that exist in your app.

Quick loading

Imagine the first experience a user has of your app is…..waiting. At some point, they are going to get distracted or bored, and you have lost a new user. Your app should either load quickly or provide some sort of feedback onscreen such as a progress indicator. You can use data from Android vitals to quantify any issues you may have with start up times. Android vitals considers excessive start up times as:

  • Cold startup takes 5 seconds or longer.
  • Warm startup takes 2 seconds or longer.
  • Hot startup takes 1.5 seconds or longer.

However, these are relatively conservative numbers. We recommend you aim for lower. Here are some great tips on how to test start up performance.

Fast rendering

High quality frame rendering is not just for games. Smooth visual experiences that don’t stall or act sluggish are also important for apps. At a minimum aim to render frames every 16ms to achieve 60 frames per second, but bear in mind there are devices in the market with faster refresh rates. To monitor performance as you test, use the Profile HWUI rendering option. Here are tools to help diagnose rendering issues.

Economical with battery usage

As soon as a user realizes your app is draining their battery, they are going to consider uninstalling. Your app can drain battery through stuck partial wake locks, excessive wakeups, background Wifi scans, or background network usage. Use the Android Studio energy profiler combined with planned background work, to diagnose unexpected battery use. For apps that need to execute background tasks that require a guarantee that the system will run them even if the app exits, WorkManager is a battery friendly Android Jetpack library that runs deferrable, guaranteed background work when the work’s constraints are satisfied.

Using up-to-date SDKs

For both security and performance, it’s important that any Google or third-party SDKs used are up-to-date. Improvements to these SDKs, such as stability, compatibility, or security, should be available to users in a timely manner. You are responsible for the entire code base, including any third party SDKs you may utilize. For Google SDKs, consider using SDKs powered by Google Play services, when available. These SDKs are backward compatible, receive automatic updates, reduce your app package size, and make efficient use of on-device resources.

To learn more, please visit the Android app excellence webpage, where you will find case studies, practical tips, and the opportunity to sign up for our App Excellence summit..

In our next blog posts, we will talk about seamless user experiences across devices. Sign up to the Android developer newsletter here to be notified of the next installment and get news and insights from the Android team.

Wear OS Jetpack libraries now in stable!

Posted by Jeremy Walker, Engineer

jetpack banner

In order to help you develop high quality Wear OS apps, we have been busy updating the Android Jetpack Wear OS libraries and recently delivered the first five stable Jetpack Wear OS libraries:

Library Featured functionality
wear Lay out elements in an arch to support round watches (ArcLayout) and write curved text following the curvature of a device (CurvedText).
wear-input Identify and interact with hardware buttons on the Wear OS device.
wear-ongoing Surface Ongoing Notifications in new Wear specific surfaces (code lab).
wear-phone-interactions Detect the type of phone a watch is paired with (iOS or Android) and handle all Notification bridging options.
wear-remote-interaction Open Android intents on other devices, for example, when a user wants the app on both the phone and watch, open the Play Store on a device where your app isn't installed.

How these compare to the Wearable Support library

The Android Jetpack Wear OS libraries contain all the familiar functionality you’ve grown used to in the old Wearable Support library, better support for Wear OS 3.0, and the features listed above (many of which are written 100% in Kotlin).

As always with Android Jetpack, the new Wear OS libraries help you follow best practices, reduce boilerplate, and create performant, glanceable experiences for your users.

The core stable libraries are available now. The Watch Face and Complications libraries are in alpha and will be released as stable later this year. Once that launches, the Wearable Support Library will officially be deprecated.

We strongly recommend you migrate the libraries within your Wear OS apps from the Wearable Support library to their AndroidX equivalents as we make them available in stable.

Note: The Android Jetpack libraries are meant to be replacements for the Wearable Support Libraries and aren't designed to be used together.

Try them out and let us know what you think!

Thank you!

Bringing richer navigation, charging, parking apps to more Android Auto users

Posted by Madan Ankapura, Product Manager

Illustration of car interior with map, parking and gas symbols

Today, we are releasing the beta of Android for Cars App Library version 1.1. Your Android Auto apps using features that require Car App API level 2+ like map interactivity, vehicle’s hardware data, multiple-length text, long message and sign-in templates, can now be used in cars with Android Auto 6.7+ (which were previously limited to Desktop Head Unit only).

Two Android Auto GIF examples. Left GIF is 2GIS and right GIF is TomTom

With this announcement, we are also completing the transition to Jetpack and will no longer be accepting submissions built with the closed source library (com.google.android.libraries.car.app). If you haven’t already, we encourage you to migrate to the AndroidX library now.

For the entire list of changes in beta01, please see the release notes. To start building your app for the car, check out our updated developer documentation, car quality guidelines and design guidelines.

If you’re interested in joining our Early Access Program to get access to new features early in the future, please fill out this interest form. You can get started with the Android for Cars App Library today, by visiting g.co/androidforcars.

Android 12 Beta 5 update, official release is next!

Posted by Dave Burke, VP of Engineering

Android 12 logo

We’re just a few weeks away from the official release of Android 12! As we put the finishing touches on the new version of Android, today we’re bringing you a final Beta update to help you with testing and development. For developers, now is the time to make sure your apps are ready!

You can get Beta 5 today on your Pixel device, including on the Pixel 5a with 5G, by enrolling here for over-the-air updates. If you’re already enrolled, you’ll automatically get the update. You can also try Android 12 Beta 5 on select devices from several of our partners like Sharp. Visit the Android 12 developer site for details.

Watch for more information on the official Android 12 release coming soon!

What’s in Beta 5?

Today’s update includes a release candidate build of Android 12 for Pixel and other devices and the Android Emulator. We reached Platform Stability at Beta 4, so all app-facing surfaces are final, including SDK and NDK APIs, app-facing system behaviors, and restrictions on non-SDK interfaces. With these and the latest fixes and optimizations, Beta 5 gives you everything you need to complete your testing.

timeline

Get your apps ready!

With the official Android 12 release coming next, we’re asking all app and game developers to complete your final compatibility testing and publish your compatibility updates ahead of the final release. For SDK, library, tools, and game engine developers, it’s important to release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates.

To test your app for compatibility, just install it on a device running Android 12 Beta 5 and work through the app flows looking for any functional or UI issues. Review the Android 12 behavior changes for all apps to focus on areas where your app could be affected. Here are some of the top changes to test:

  • Privacy dashboard — A new dashboard in Settings lets users see which apps are accessing which type of data and when. Users can adjust permissions if needed, and they can request details from your app on the reason for access. More here.
  • Microphone & camera indicators — Android 12 shows an indicator in the status bar when an app is using the camera or microphone. More here.
  • Microphone & camera toggles — New toggles in Quick Settings let users instantly disable microphone and camera access for all apps. More here.
  • Clipboard read notification — A toast alerts users when an app reads data from the clipboard unexpectedly. More here.
  • Stretch overscroll — A new “stretch” overscroll effect replaces the previous “glow” overscroll effect systemwide. More here.
  • App splash screens — Android 12 launches apps with a new splash screen animation. More here.
  • Keygen changes — Several deprecated BouncyCastle cryptographic algorithms are removed in favor of Conscrypt versions. If your app uses a 512-bit key with AES, you’ll need to use one of the standard sizes supported by Conscrypt.More here.

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

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

Explore the new features and APIs

Android 12 has a ton of new features to help you build great experiences for users. Check out our Android 12 Beta 2 post for a recap and links to Android 12 talks at Google I/O. For complete details on all of the new features and APIs, visit the Android 12 developer site.

Also make sure to try Android Studio Arctic Fox with your Android 12 development and testing. We’ve added lint checks to help you catch where your code might be affected by Android 12 changes, such as for custom declarations of splash screens, coarse location permission for fine location usage, media formats, and high sensor sampling rate permission. You can give these a try by downloading and configuring the latest version of Android Studio.

Get started with Android 12!

Today’s Beta 5 release has everything you need to try the Android 12 features, test your apps, and give us feedback. Just enroll any supported Pixel device to get the update over-the-air. To get started developing, set up the Android 12 SDK.

You can also get Beta 5 on devices from several of our partners like Sharp. For even broader testing, you can try Beta 5 on Android GSI images, and if you don’t have a device, you can test on the Android Emulator. This update is also available for Android TV, so you can check out the latest TV features and test your apps on the all-new Google TV experience.

What’s next?

Stay tuned for the official Android 12 launch coming in the weeks ahead! Until then, feel free to continue sharing your feedback through our hotlists for platform issues, app compatibility issues, and third-party SDK issues.

A huge thank you to our developer community for helping shape the Android 12 release! You’ve given us thousands of bug reports and shared insights that have helped us adjust APIs, improve features, fix significant bugs, and in general make the platform better for users and developers.

We’re looking forward to seeing your apps on Android 12!

Accelerated Kotlin build times with Kotlin Symbol Processing 1.0

Posted by Ting-Yuan Huang, Software Engineer and Jiaxiang Chen, Software Engineer

Accelerated Kotlin build times with Kotlin Symbol Processing 1.0 image

Kotlin Symbol Processing (KSP), our new tool for building lightweight compiler plugins in Kotlin, is now stable! KSP offers similar functionality to the Kotlin Annotation Processing Tool (KAPT), however it’s up to 2x faster, offers direct access to Kotlin language constructs, and offers support for multiplatform targets.

Over the past few months, KSP has gone through 32 releases with over 162 bugs reported from the community and fixed by our team. If you were waiting to adopt it, now is the time to check it out.

Why we built KSP

On the Android team, we regularly ask developers: what are your biggest frustrations with writing apps today? One of the top issues that comes up repeatedly is build speed. Over the years we’ve been making steady improvements to the Android build toolchain, and today we’re excited to add to those improvements with KSP. KSP is the next generation of annotation processing in Kotlin: it will dramatically improve build speed for Kotlin developers, and unlike KAPT, it offers support for Kotlin/Native and Kotlin/JS.

Why is KSP faster?

The Kotlin Annotation Processing Tool (KAPT) works with Java’s annotation processing infrastructure to make most Java language annotation processors work in Kotlin out of the box. To do this, KAPT compiles Kotlin code into Java stubs that retain information that Java annotation processors care about. Creating these stubs is costly though, and means the compiler must resolve all the symbols in your program multiple times (once to generate stubs, and then again to do the actual compilation).

KSP moves away from the stub generation model by working as a Kotlin compiler plugin — it allows annotation processors to read and analyze source programs and resources directly in Kotlin instead of requiring you to depend on the Java annotation processing infrastructure. This both dramatically improves build speed (up to 2x faster for Room's Kotlin test app) and means that KSP can be used for non-Android and non-JVM environments like Kotlin/Native and Kotlin/JS.

How to get started

To start using KSP, download the KSP playground project from GitHub, which shows how to use KSP both as an annotation processor and as a consuming app/library:

  • Annotation processor: A toy test-processor library that implements the builder pattern as a KSP processor
  • Consuming library: A workload directory that shows how to use the builder processor in a real-world Kotlin project

If you’re an app developer, check out the list of supported libraries and the quickstart guide for moving a module over from KAPT to KSP.

Using Moshi or Room with KSP

If you’re using Moshi or Room in your project, you can already try out KSP by making a quick fix to your module’s build file. For example, to use the KSP version of Room in a Gradle module you can simply replace the KAPT plugin with KSP and swap out the KSP dependency:

apply plugin: 'com.google.devtools.ksp'

dependencies {
  ...
  implementation "androidx.room:room-runtime:$room_version"
  kapt "androidx.room:room-compiler:$room_version"
  ksp "androidx.room:room-compiler:$room_version"

}

Check out the Room release notes for more info.

Conclusion

With the 1.0 release of KSP you will start to see improved build times for your Kotlin projects as you migrate away from libraries based on KAPT. We have also updated a number of Android specific libraries which are ready for you to try today and offer significant performance improvements.

Raising the quality bar with updated guidelines for Wear OS 3.0

Posted by Marcus Leal, Senior Product Manager for Google Play Store

WearOS 3.0 art

Our Modern Android Developer tools and APIs are designed to help you build high quality apps your users love, and this extends to form factors such as wearables. Earlier this year we announced udates to our developer tools APIs to support you in building seamless, high quality apps for your users. Today we’re announcing new guidelines to help support you in building these experiences.

Updated quality guidelines for Wear OS apps

We’ve started by updating our guidelines to give you a better understanding of what we expect of quality apps on Google Play, and what your users will be expecting for Wear OS 3.0. Some of the major changes are summarized below:

  • There are updated quality requirements for notifications, layout, and Wear functionality. Starting October 13th, Wear OS apps will need to meet these requirements to be published on Google Play.
  • Starting October 13th, Watch Faces will need to comply with our updated guidelines. All watch faces still need to comply with Google Play policies in order to publish on Google Play.

Many developers are already meeting these requirements and won’t need to make many of these changes when migrating to Wear OS 3.0. However, we recommend familiarizing yourself with the full updated guidelines here.

Updated screenshot requirements for Wear OS apps

With these quality guideline updates, we’re also rolling out changes to the Play Store to improve the discoverability of Wear OS apps. In July we launched the ability for people to filter for Wear OS and Watch Faces when searching for apps within the Play Store.

We’re now releasing new screenshot requirements for Wear OS apps to help users better understand your Wear OS app’s functionality when discovering new apps. Starting October 13th, Wear OS apps will need to meet these screenshot requirements to be published on Google Play:

  • Upload screenshots with a minimum size of 384 x 384 pixels, and with a 1:1 aspect ratio.
  • Provide screenshots showing only your app interface — screenshots must demonstrate the actual in-app or in-game experience, focusing on the core features and content so users can anticipate what the app or game experience will be like.
  • Don’t frame your screenshots in a Wear OS watch.
  • Don’t include additional text, graphics, or backgrounds in your Wear OS screenshots that are not part of the interface of your app.
  • Don’t include transparent backgrounds or masking.
List of Watch OS dos and don'ts. Do upload screenshots with a minimum size of 384 x 384 pixels, and with a 1:1 aspect ratio. Do provide screenshots showing only your app interface — screenshots must demonstrate the actual in-app or in-game experience, focusing on the core features and content so users can anticipate what the app or game experience will be like. Don’t frame your screenshots in a Wear OS watch.
Don’t include additional text, graphics, or backgrounds in your Wear OS screenshots that are not part of the interface of your app. Don’t include transparent backgrounds or masking.

Similar to mobile, your store listing and the quality of your Wear OS app will influence your search ranking and opportunities for merchandising. In order to put your best foot forward on Google Play, we recommend thinking about the following considerations:

  • Test your app on Wear OS 3.0 devices, and make sure it is working as expected.
  • Make sure your store listing shows that your app is available for Wear OS. One way to do this is to upload a screenshot of your Wear OS app or Watch face in Google Play Console.
  • Most importantly, ensure your Wear OS app meets the new quality requirements.

We hope this transparency helps your development process, and we look forward to seeing more seamless Wear OS experiences on Google Play. Happy Coding!

Working Towards Android App Excellence

Posted by Jacob Lehrbaum Director of Developer Relations, Android

illustration of freckled hand over mobile phone with graphs

Great app experiences are great for business. In fact, nearly three-quarters of Android app users who leave a 5 star review on Google Play mention the quality of their experience with the app1; its speed, design, and usability. At Google, we want to help all developers achieve app excellence, and in turn help you drive user acquisition, retention, and monetization.

So what is “app excellence”? This may sound aspirational, but it is within reach for many apps. It starts with a laser focus on the user, and more specifically, with intuitive user experiences that get people to the main functionality of your app as quickly as possible — but that is just the beginning. Excellent apps are consistent across all of their screens and experiences. They perform well, no matter the device used. App excellence is achievable when all of the stakeholders who influence your app are invested in the experience of using your app.

One of the blockers that gets in the way of app excellence is shared or unclear accountability. Some of the primary measures of app quality, such as crashes and load times, are often seen as the responsibility of one group in the company, such as the engineering team. However, when we talk to best-in-class organizations2 about how they achieve app quality, it is clear that taking a cross-functional approach is key, with engineering, design, product, and business teams working toward a common goal.

So what are some internal best practices behind app excellence?

Make app quality a cross-organizational focus — not just an engineering concern

It’s a way easier conversation for me at the business end because I can say “these competitors’ apps are faster than ours; we need to reduce our load time down from 5 seconds to 4 seconds”.
Software engineer, x-platform app

App excellence helps drive business performance. New features are great, but if they slow down app start-up times or take up too much device space, people will eventually use your app less often or even delete it. Engineers who have built a company-wide focus on quality have often done so by quantifying the impact of quality issues on business performance, through:

  • Case studies showing the impact of responsiveness, APK size, start-up time, and memory usage on business KPIs. Here you can find practical case studies showcasing how developers such as Headspace and Duolingo achieved app excellence.
  • Benchmarking against competitor apps. Check out peer benchmarks and other metrics on the Google Play Console.

Organize teams around features and/or app user journey stages

Companies that organize teams around features — or stages in the user journey — are more likely to deliver consistent experiences across each operating system they support, bring new apps or features to market faster, and deliver a better app experience for all their customers. These teams are often cross-functional groups that span engineering, marketing, ux, and product — and are responsible for the success of a feature or user journey stage3 across all devices and platforms. In addition to better experiences and feature parity, this structure enables alignment of goals across functional areas while reducing silos, and it also helps teams hyper-focus on addressing specific objectives.

Feature organized team graph

Squads focused on business objectives heighten focus on the user.

Use the same devices your customers use

If a majority of your users are on a specific type of device, you can build empathy for their experience if you use the same phone, tablet or smart watch as your primary device. This is especially relevant for senior leadership in your organization who make decisions that impact the day-to-day experience of millions of users. For example, Duolingo has built this into their company DNA. Every Duolingo employee — including their CEO — either uses exclusively or has access to an entry level Android device to reflect a significant portion of their user base.

A user-centric approach to quality and app excellence is essential to business growth. If you are interested in learning how to achieve app excellence, read our case studies with practical tips, and sign up to attend our App Excellence Summit by visiting the Android app excellence webpage.

In subsequent blog posts, we will dig deep into two drivers of excellent app experiences: app performance and how it is linked to user behavior, and creating seamless user experiences across devices. Sign up to the Android developer newsletter here to be notified of the next installment, and get news and insights from the Android team.

Notes


  1. Internal Google Play data, 2021. 

  2. Google App Quality Research, 2021 

  3. The series of steps each user takes as they interact with your app is referred to as the “user journey.” Examples of user journey stages include installs, onboarding, engagement, and retention 

Join the North America Android Study Jams to learn more about developing quality Android apps

Posted by Kübra Zengin, Program Manager

Android Study Jams Logo

Learning about Android development doesn’t mean you have to learn by yourself. Join fellow developers in your community and improve your skills by attending an Android Study Jam! Events are currently taking place across North America.

Android Study Jams are community events where developers come together to learn, create, and collaborate. Participants will follow guided codelabs designed to improve their development skills, all with an extra focus on improving the quality of applications.

These codelabs are created by the Android Developer Relations team at Google with three different tracks.

  1. Track one focuses on developers who are completely new to programming.
  2. Track two is for developers who are already experienced with Android development and are looking to take their skills to the next level.
  3. Track three is for advanced developers who want to learn about Modern Android Development: the Androids team’s recommended tools, APIs, and programming language to help developers more productively build better quality apps. This track will cover :
    • Jetpack Compose
    • Kotlin coroutines
    • Using Hilt and learning the importance of Dependency Injection
    • Advanced WorkManager
    • Advanced Testing Concepts
    • Jetpack Compose Basics

If you want to join an Android Study Jam, meet fellow developers, and learn alongside friends old and new, then check out this link to find an event!

Image with text saying Modern Android Development with 3 phones

Android 12 Beta 4 and Platform Stability

Posted by Dave Burke, VP of Engineering

Android 12 logo

Today we’re bringing you the fourth Beta of Android 12, and moving into the final phase of the release. We’ve built Android 12 with a new UI that adapts to you, performance improvements, privacy and security enhancements, and more. We’re now shifting our focus to polish, performance, and stability. Thanks for all the feedback you’ve shared to help us refine the release and get us to this point.

For developers, Beta 4 takes us to Platform Stability, which means that Android 12’s APIs and all app-facing behaviors are finalized. For apps, the focus is now on compatibility and quality. It’s time to start preparing your compatible app updates in time for the official release later in the year.

You can try Beta 4 today on your Pixel device by enrolling here for over-the-air updates, and if you previously enrolled, you’ll automatically get today’s update. You can also get Android 12 Beta 4 on select devices from several of our partners like ASUS, Oneplus, Oppo, Realme, Sharp, and ZTE - learn more at android.com/beta. Visit the Android 12 developer site for details on how to get started.

Platform Stability

Android 12 Beta 4 has reached Platform Stability, a milestone that means all app-facing surfaces and behaviors are now final in Android 12. This includes not only the official SDK and NDK APIs, but also final app-facing system behaviors and restrictions on non-SDK interfaces that may affect apps. So from Beta 4, you can confidently release your compatibility updates knowing that the platform won’t change. More on the timeline is here.

Android 12 timeline

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

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

App compatibility

For Android, App compatibility means that your app runs as intended on a new version of the platform. You can check your app’s compatibility just by installing the production version of your app on a device or emulator and testing it - if the app looks good and runs properly, then you’re done, it’s compatible!

Testing your app for compatibility is important because with each release, we make integral changes to the platform that improve privacy and security and the overall user experience across the OS. These can affect your apps, so you should take a look at the behavior changes and test against them, then publish a compatible update to your users. It’s a basic but critical level of quality that ensures users have a good app experience.

As people update their devices to Android 12, they want to explore the latest version of Android, and experience it with their favorite apps. If those apps don’t work properly, it’s a major issue, ultimately resulting in uninstalls.

So while there are a ton of new APIs and capabilities to explore, start by testing your current app and releasing a compatible update first.

Get your apps ready

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

  • Privacy dashboard - A new dashboard in Settings lets users see which apps are accessing which type of data and when. Users can adjust permissions if needed, and they can request details from your app on the reason for access. More here.
  • Microphone & camera indicators - Android 12 shows an indicator in the status bar when an app is using the camera or microphone. More here.
  • Microphone & camera toggles - New toggles in Quick Settings let users instantly disable microphone and camera access for all apps. More here.
  • Clipboard read notification - A toast alerts users when an app reads data from the clipboard unexpectedly. More here.
  • Stretch overscroll - A new “stretch” overscroll effect replaces the previous “glow” overscroll effect systemwide. More here.
  • App splash screens - Android 12 launches apps with a new splash screen animation. More here.
  • Keygen changes - Several deprecated BouncyCastle cryptographic algorithms are removed in favor of Conscrypt versions. If your app uses a 512-bit key with AES, you’ll need to use one of the standard sizes supported by Conscrypt. More here.

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

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

  • Foreground service launch restriction - Apps can no longer launch foreground services from the background. For high-priority background tasks, use expedited jobs in WorkManager instead. More here.
  • Approximate location - When apps request permission for precise location, users can now choose to grant either precise or approximate location. More here.
  • New permission for exact alarms - Apps that want to use exact alarms must request a new normal permission, SCHEDULE_EXACT_ALARM. More here.
  • Modern SameSite cookie behaviors in WebView - If your app uses WebView, test your app with the new SameSite cookie behaviors. More here.
  • Safer exporting of components - your app must explicitly specify an android:exported attribute for any app components that use intent filters. More here.
  • Custom notifications - The system applies a standard notification template to fully custom notifications, with affordances for app name, app icon, and expand/collapse data. More here.
  • Notification trampolines restriction - Notifications can no longer launch your app using a “trampoline” - an intermediary broadcast receiver or service that starts the target Activity. More here.

During testing, also watch for uses of restricted non-SDK interfaces in your app and move those to public SDK equivalents instead. You can read about the restricted APIs here.

Get started with Android 12!

Today’s Beta release has everything you need to try the Android 12 features, test your apps, and give us feedback. Just enroll any supported Pixel device to get the update over-the-air. To get started developing, set up the Android 12 SDK.

You can also get Android 12 Beta 4 on devices from some of our partners like ASUS, OnePlus, Oppo, Realme, Sharp, and ZTE. Visit android.com/beta to see the full list of partners participating in Android 12 Beta. For even broader testing, you can try Android 12 Beta 4 on Android GSI images, and if you don’t have a device, you can test on the Android Emulator.

Beta 4 is also available for Android TV, so you can check out the latest TV features and test your apps on the all-new Google TV experience. Try it out with the ADT-3 developer kit. More here.

Watch for one more Beta coming in the weeks ahead as a release candidate for your final testing.

For complete details on Android 12 Beta, visit the Android 12 developer site.