Posted by Jeremy Walker, Developer Relations Engineer
At this year’s Google I/O, we announced we are bringing the best of Jetpack Compose to Wear OS. Well, today, Compose for Wear OS is in Developer Preview after a number of successful alpha releases.
Compose simplifies and accelerates UI development, and the same is true of Compose for Wear OS, with built-in support for Material You to help you create beautiful apps with less code.
In addition, what you’ve learned building mobile apps with Jetpack Compose translates directly to the Wear OS version. Just like mobile, you’re welcome to start testing it out right away, and we want to incorporate your feedback into the early iterations of the libraries before the beta release.
This article will review the main composables we've built and point you towards resources to get started using them.
Let's get started!
Most of the Wear related changes you make will be at the top architectural layers.
That means many of the dependencies you already use with Jetpack Compose don't change when targeting Wear OS. For example, the UI, Runtime, Compiler, and Animation dependencies will remain the same.
However, you will need to use the proper Wear OS Material, Navigation, and Foundation libraries which are different from the libraries you have used before in your mobile app.
Below is a comparison to help clarify the differences:
Wear OS Dependency
(androidx.wear.*)
Comparison
Mobile Dependency
(androidx.*)
androidx.wear.compose:compose-material
instead of
androidx.compose.material:material ₁
androidx.wear.compose:compose-navigation
androidx.navigation:navigation-compose
androidx.wear.compose:compose-foundation
in addition to
androidx.compose.foundation:foundation
1. Developers can continue to use other material related libraries like material ripple and material icons extended with the Wear Compose Material library.
While it's technically possible to use the mobile dependencies on Wear OS, we always recommend using the wear-specific versions for the best experience.
Note: We will be adding more wear composables with future releases. If you feel any are missing, please let us know.
Here's an example build.gradle file:
build.gradle
// Example project in app/build.gradle file dependencies { // Standard Compose dependencies... // Wear specific Compose Dependencies // Developer Preview starts with Alpha 07, with new releases coming soon. def wear_version = "1.0.0-alpha07" implementation "androidx.wear.compose:compose-material:$wear_version" implementation "androidx.wear.compose:compose-foundation:$wear_version" // For navigation within your app... implementation "androidx.wear.compose:compose-navigation:$wear_version" // Other dependencies... }
After you've added the right Wear Material, Foundation, and Navigation dependencies, you are ready to get started.
Let's explore some composables you can start using today.
As a general rule, many of the Wear composables that are equivalent to the mobile versions can use the same code. The code for styling color, typography, and shapes with MaterialTheme is identical to mobile as well.
MaterialTheme
For example, to create a Wear OS button your code looks like this:
Button( modifier = Modifier.size(ButtonDefaults.LargeButtonSize), onClick = { /*...*/ }, enabled = enabledState ) { Icon( painter = painterResource(id = R.drawable.ic_airplane), contentDescription = "phone", modifier = Modifier .size(24.dp) .wrapContentSize(align = Alignment.Center), ) }
The code above is very similar to the mobile side, but the library creates a Wear OS optimized version of the button, that is, a button circular in shape and sized by ButtonDefaults to follow Wear OS Material Guidelines.
ButtonDefaults
Below are several composable examples from the library:
Button
Card
Icon
Text
In addition, we've introduced many new composables that improve the Wear experience:
Chip
ToggleChip
BasicCurvedText
TimeText
We also offer a wear optimized composable for lists, ScalingLazyColumn, which extends LazyColumn and adds scaling and transparency changes to better support round surfaces. You can see in the app below, the content shrinks and fades at the top and bottom of the screen to help readability:
ScalingLazyColumn
LazyColumn
If you look at the code, you can see it's the same as LazyColumn, just with a different name.
val scalingLazyListState: ScalingLazyListState = rememberScalingLazyListState() ScalingLazyColumn( modifier = Modifier.fillMaxSize(), verticalArrangement = Arrangement.spacedBy(6.dp), state = scalingLazyListState, ) { items(messageList.size) { message -> Card(/*...*/) { /*...*/ } } item { Card(/*...*/) { /*...*/ } } }
Wear has its own version of Box, SwipeToDismissBox, which adds support for the swipe-to-dismiss gesture (similar to the back button/gesture on mobile) out of the box.
Box
SwipeToDismissBox
Here's a simple example of the code:
// Requires state (different from Box). val state = rememberSwipeToDismissBoxState() SwipeToDismissBox( modifier = Modifier.fillMaxSize(), state = state ) { swipeBackgroundScreen -> // Can render a different composable in the background during swipe. if (swipeBackgroundScreen) { /* ... */ Text(text = "Swiping Back Content") } else { /* ... */ Text( text = "Main Content") } }
Here's a more complex example of the behavior:
Finally, we also offer a Navigation composable, SwipeDismissableNavHost, which works just like NavHost on mobile but also supports the swipe-to-dismiss gesture out of the box (actually uses SwipeToDismissBox under the hood).
SwipeDismissableNavHost
NavHost
Here's an example (code):
Scaffold provides a layout structure to help you arrange screens in common patterns, just like mobile, but instead of an App Bar, FAB, or Drawer, it supports Wear specific layouts with top-level components like Time, Vignette, and the scroll/position indicator.
Scaffold
Vignette
PositionIndicator
The code is very similar to what you would write on mobile.
We're excited to bring Jetpack Compose to Wear OS and make watch development faster and easier. To dive right in and create an app, check out our quick start guide. To see working examples (both simple and complex), have a look at our sample repo.
The Developer Preview is your opportunity to influence the APIs, so please share your feedback here or join the Slack #compose-wear channel and let us know there!
Posted by Dave Burke, VP of Engineering
Today we’re pushing the source to the Android Open Source Project (AOSP) and officially releasing the latest version of Android. Keep an eye out for Android 12 coming to a device near you starting with Pixel in the next few weeks and Samsung Galaxy, OnePlus, Oppo, Realme, Tecno, Vivo, and Xiaomi devices later this year.
As always, thank you for your feedback during Android 12 Beta! More than 225,000 of you tested our early releases on Pixel and devices from our partners, and you sent us nearly 50,000 issue reports to help improve the quality of the release. We also appreciate the many articles, discussions, surveys, and in-person meetings where you voiced your thoughts, as well as the work you’ve done to make your apps compatible in time for today’s release. Your support and contributions are what make Android such a great platform for everyone.
We’ll also be talking about Android 12 in more detail at this year’s Android Dev Summit, coming up on October 27-28. We’ve just released more information on the event, including a snapshot of the technical Android sessions; read on for more details later in the post.
Here’s a look at some of what’s new in Android 12 for developers. Make sure to check out the Android 12 developer site for details on all of the new features.
Material You - Android 12 introduces a new design language called Material You, helping you to build more personalized, beautiful apps. To bring all of the latest Material Design 3 updates into your apps, try an alpha version of Material Design Components and watch for support for Jetpack Compose coming soon.
Redesigned widgets - We refreshed app widgets to make them more useful, beautiful, and discoverable. Try them with new interactive controls, responsive layouts for any device, and dynamic colors to create a personalized but consistent look. More here.
Notification UI updates - We also refreshed notification designs to make them more modern and useful. Android 12 also decorates custom notifications with standard affordances to make them consistent with all other notifications. More here.
Stretch overscroll - To make scrolling your app’s content more smooth, Android 12 adds a new “stretch” overscroll effect to all scrolling containers. It’s a natural scroll-stop indicator that’s common across the system and apps. More here.
App launch splash screens - Android 12 also introduces splash screens for all apps. Apps can customize the splash screen in a number of ways to meet their unique branding needs. More here.
Faster, more efficient system performance - We reduced the CPU time used by core system services by 22% and the use of big cores by 15%. We’ve also improved app startup times and optimized I/O for faster app loading, and for database queries we’ve improved CursorWindow by as much as 49x for large windows.
Optimized foreground services - To provide a better experience for users, Android 12 prevents apps from starting foreground services while in the background. Apps can use a new expedited job in JobScheduler instead. More here.
More responsive notifications - Android 12’s restriction on notification trampolines helps reduce latency for apps started from a notification. For example, the Google Photos app now launches 34% faster after moving away from notification trampolines. More here.
Performance class - Performance Class is a set of device capabilities that together support demanding use-cases and higher quality content on Android 12 devices. Apps can check for a device’s performance class at runtime and take full advantage of the device’s performance. More here.
Faster machine learning - Android 12 helps you make the most of ML accelerators and always get the best possible performance through the Neural Networks API. ML accelerator drivers are also now updatable outside of platform releases, through Google Play services, so you can take advantage of the latest drivers on any compatible device.
Privacy Dashboard - A new dashboard in Settings gives users better visibility over when your app accesses microphone, camera, and location data. More here.
Approximate location - Users have even more control over their location data, and they can grant your app access to approximate location even if it requests precise location. More here.
Microphone and camera indicators - Indicators in the status bar let users know when your app is using the device camera or microphone. More here.
Microphone and camera toggles - On supported devices, new toggles in Quick Settings make it easy for users to instantly disable app access to the microphone and camera. More here.
Nearby device permissions - Your app can use new permissions to scan for and pair with nearby devices without needing location permission. More here.
Rich content insertion - A new unified API lets you receive rich content in your UI from any source: clipboard, keyboard, or drag-and-drop. For back-compatibility, we’ve added the unified API to AndroidX. More here.
Support for rounded screen corners - Many modern devices use screens with rounded corners. To deliver a great UX on these devices, you can use new APIs to query for corner details and then manage your UI elements as needed. More here.
AVIF image support - Android 12 adds platform support for AV1 Image File Format (AVIF). AVIF takes advantage of the intra-frame encoded content from video compression to dramatically improve image quality for the same file size when compared to older image formats, such as JPEG.
Compatible media transcoding - For video, HEVC format offers significant improvements in quality and compression and we recommend that all apps support it. For apps that can’t, the compatible media transcoding feature lets your app request files in AVC and have the system handle the transcoding. More here.
Easier blurs, color filters and other effects - new APIs make it easier to apply common graphics effects to your Views and rendering hierarchies. You can use RenderEffect to apply blurs, color filters, and more to RenderNodes or Views. You can also create a frosted glass effect for your window background using a new Window.setBackgroundBlurRadius() API, or use blurBehindRadius to blur all of the content behind a window.
Enhanced haptic experiences - Android 12 expands the tools you can use to create informative haptic feedback for UI events, immersive and delightful effects for gaming, and attentional haptics for productivity. More here.
New camera effects and sensor capabilities - New vendor extensions let your apps take advantage of the custom camera effects built by device manufacturers—bokeh, HDR, night mode, and others. You can also use new APIs to take full advantage of ultra high-resolution camera sensors that use Quad / Nona Bayer patterns. More here.
Better debugging for native crashes - Android 12 gives you more actionable diagnostic information to make debugging NDK-related crashes easier. Apps can now access detailed crash dump files called tombstones through the App Exit Reasons API.
Android 12 for Games - With Game Mode APIs, you can react to the players' performance profile selection for your game - like better battery life for a long commute, or performance mode to get peak frame rates. Play as you download will allow game assets to be fetched in the background during install, getting your players into gameplay faster.
Now with today’s public release of Android 12, we’re asking all Android developers to finish your compatibility testing and publish your updates as soon as possible, to give your users a smooth transition to Android 12.
To test your app for compatibility, just install it on a device running Android 12 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:
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.
The #AndroidDevSummit is back! Join us October 27-28 to hear about the latest updates in Android development, including Android 12. This year’s theme is excellent apps, across devices; tune in later this month to learn more about the development tools, APIs and technology to help you be more productive and create better apps that run across billions of devices, including tablets, foldables, wearables, and more.
We’ve just released more information on the event, including a snapshot of the 30+ technical Android sessions; you can take a look at some of those sessions here, and start planning which talks you want to check out. Over the coming weeks, we’ll be asking you to share your top #AskAndroid questions, to be answered live by the team during the event.
The show kicks off at 10 AM PT on October 27 with The Android Show, a 50-minute technical keynote where you’ll hear all the latest news and updates for Android developers. You can learn more and sign up for updates here.
Posted by Wayne Lu, Technical Lead Manager, Android DevRel
We launched the Android Game Development Kit (AGDK) in July, and have collected some top questions from developers - ranging from AGDK libraries and tools, optimizing memory in Android, and implementing graphics.
Firstly, we’ve heard questions from early, rising game developers on how to use our set of AGDK libraries and tools. We have the following recommendations depending on your setup:
After choosing your game engine and workflow, you should look into our tools such as the Android Studio Profiler to inspect your game, Android GPU Inspector to profile graphics and Android Performance Tuner to optimize frame rates and loading times.
Following this, we’ve received questions on developing for Android 12. While you don’t have to do anything special for your game to run on Android 12, we’ve introduced Game Mode API and interventions to help players customise their gaming experience.
Secondly, you’ve asked us how memory access works in Android game development versus Windows. In short, here are a couple of pointers:
Thirdly, we’ve received questions about implementing graphics in Android. You have the following options: OpenGL ES or Vulkan graphics APIs:
Check out the Q&A; video to view the top questions on AGDK and visit g.co/android/AGDK for our latest resources for Android game development.
Posted by Manuel Vicente Vivo, Android Developer Relations Engineer
Contributors: Mauricio Vergara, Product Marketing Manager, Developer Marketing, Marialaura Garcia, Associate Product Marketing Manager, Developer Marketing
Headspace was ready to launch new wellness and fitness features, but their app architecture wasn’t. They spent eight months refactoring to a Model-View-ViewModel architecture, rewriting in Kotlin and improving test coverage from 15 to 80%. The improved app experience increased MAU by 15% and increased review scores from 3.5 to 4.7 between Q2 and Q4 of 2020. To learn more about how Headspace’s focus on Android Excellence impacted their business, read the accompanying case study here.
Headspace has grown into a leader in mindfulness by creating an app which helps millions of people to meditate daily. Mindfulness goes far beyond meditation, it connects to all aspects of a person’s life. That idea prompted the most recent stage in Headspace’s evolution. In 2019, they decided to expand beyond meditation and add new fitness and wellness features to their Android app. Headspace realized that they would need a cross-functional team of engineers and designers to be able to deliver on the new product vision and create an excellent app experience for users. An exciting new phase for the company: their design team started the process by creating prototypes for the new experience, with fresh new designs.
With designs in hand, the only thing stopping Headspace from expanding their app and broadening users’ horizons was their existing Android software architecture. It wasn’t well structured to support all these new features. Headspace’s development team made the case to their leadership that building on the existing code would take longer than a complete rewrite. After sharing the vision and getting everyone on board, the team set out on a collective journey to write a new Android app in pursuit of app excellence.
Headspace’s Android development team first needed a convenient way to standardize how they built and implemented features. "Before we wrote a single line of code, our team spent a week evaluating some important implementation choices for the foundation of our app,” Aram Sheroyan, an Android developer at Headspace explains;
“This was crucial pre-work so that we were all on the same page when we actually started to build."
Immersing themselves in Google’s literature on the latest, best practices for Android development and app architecture, the team found a solution they could all confidently agree on. Google recommended refactoring their app using a new base architecture: model-view-view-model. MVVM is a widely-supported software pattern that is progressively becoming industry standard because it allows developers to create a clear separation of concerns, helping streamline an app’s architecture. “It allowed us to nicely separate our view logic," Sheroyan explained.
With MVVM as the base architecture, they identified Android’s Jetpack libraries, including Dagger and Hilt for dependency injection. The new tools made boilerplate code smaller and easier to structure, not to mention more predictable and efficient. Combined with MVVM, the libraries provided them with a more detailed understanding of how new features should be implemented. The team was also able to improve quality in passing arguments between functions. The app had previously suffered from crashes due to NullPointerException errors and incorrect arguments. Adopting the safeArgs library helped to eliminate errors when passing arguments.
In rewriting the app, the team further made sure to follow the Repository pattern to support a clearer separation of concerns. For example, instead of having one huge class that saves data in shared preferences, they decided that each repository’s local data source should handle the respective logic. This separation of data sources enables the team to test and reproduce business code outside of the live app for unit testing without having to change production code. Separating concerns in this way made the app more stable and the code more modular.
The team also took the opportunity to fully translate their app into the Kotlin programming language, which offered useful helper functions, sealed classes, and extension functions. Removing legacy code and replacing the mix of Java and Kotlin with pure Kotlin code decreased build time for the app. The new architecture also made it easier to write tests and allowed them to increase test coverage from around 15% to more than 80%. This resulted in faster deployments, higher quality code, and fewer crashes.
To capture the new user experience in the app’s reviews, Headspace implemented the Google Play In-App Review API. The new API allowed them to encourage all users to share reviews from within the app. The implementation increased review scores by 24%, and — as store listing reviews are tied to visibility on Google Play — helped draw attention to the app’s recent improvements.
The rewrite took eight months and with it came a new confidence in the code. Now that the codebase had 80%+ unit test coverage, they could develop and test new features with confidence rather than worries. The new architecture made this possible thanks to its improved logic separation, and a more reusable code, making it easier to plan and implement new features.
The build time for the app decreased dramatically and development velocity picked up. The team’s new clarity around best practices and architecture also reduced friction for onboarding new developers, since it was now based on Android industry standards. They could communicate more clearly with potential candidates during the interview process, as they now had a shared architectural language for discussing problem sets and potential solutions.
With velocity came faster implementation of features and an improved retention flow. They could now optimize their upsell process, which led to a 20% increase in the number of paid Android subscribers relative to other platforms where the app is published. The combination of a new app experience and the implementation of the new In-App Review API led to their review scores improving from 3.5 to 4.7 stars between Q2 and Q4 of 2020! Overall, the new focus on Android App Excellence and the improved ratings earned Headspace a 15% increase in MAU globally..
These were just a few of the payoffs from the significant investment Headspace made in app excellence. Their laser focus on quality paid off across the board, enabling them to continue to grow their community of users and lay a solid foundation for the future evolution of their app experience.
If you’re interested in getting your team on board for your own App Excellence journey, check out our condensed case study for product owners and executives linked here. To learn more about how consistent, intuitive app user experiences can grow your business, visit the App Excellence landing page.
Posted by the Android Team
The Android Dev Summit is back! In just a few weeks, join us October 27-28 to hear about the latest updates in Android development. This year’s theme is Excellent apps, across devices, and you can learn about the development tools, APIs and technology to help you be more productive and create better apps that run across billions of devices, including tablets, wearables and more.
The show kicks off at 10 AM PT on October 27 with The Android Show: a technical keynote where you’ll hear all the latest news and updates for Android developers. From there, we have over 30 sessions on a range of technical Android development topics. Plus, we’ve assembled the team that builds Android to get your burning #AskAndroid questions answered live. This year’s Android Dev Summit will be your opportunity to connect digitally with Android developers around the world.
Interested in learning more? Be sure to sign up for updates through our newsletter here.
Posted by Mike Yerou, Software Engineer, Google Play
User management is an important responsibility for businesses of all sizes. The challenge is to make sure that every team member has the right set of permissions to fulfill their responsibilities, but without overexposing unrelated business data.
Over the years, you’ve asked us for better user and permission management tools in Play Console to help you handle growth efficiently and with confidence. And with the redesigned Google Play Console, we did just that. We decluttered the interface to make it easier to find what you want, and added new features to help you manage your teams easier.
The users and permissions page has been redesigned to make it easier for admins to manage their teams.
Permission names and descriptions were rewritten to make it easier to understand what you are — and aren’t — allowing users to do. You’ll also see clearer differentiation between account and app-level permissions.
New search, filtering, and batch-editing capabilities allowed you to quickly view and act on a subset of users.
And finally, to make auditing easier, we added a CSV export functionality for users of a developer account.
New access requests
While admins generally set permissions for users, you told us it would be helpful to allow users to request permissions as they figure out what’s required for their workflow. Well, now they can. Admins will still need to approve the request, but empowering users to ask for the exact permissions they need is a significant time-saver for admins.
In Play Console, users will now see a “Request access” button next to each action that is supported but not enabled due to missing permissions. To request the permission, users need to include an explanation of their need to the admin. Admins will be notified via their Inbox and can grant the permission for the specific user and app, reject it once, or reject it permanently to prevent users misusing the feature. Currently, this function is only supported for app permissions.
Team members can now request access for specific permissions.
New permission groups
When companies reach a certain size, it’s not uncommon for more than one person to have the same role, such as project managers or designers. When that happens, admins may find themselves assigning the same set of permissions over and over again.
To save you time, we recently introduced permission groups. Admins can now create a group with a set of permissions, and when a user is added to that group, they will inherit those permissions automatically. You can even choose to have the permissions in that group expire after a certain date. Users can be in multiple groups, and these groups can have overlapping permissions. We hope you’ll be able to use permission groups to improve your own working practices and encourage greater delegation and ease of user management.
We hope these new changes help you improve admin productivity and help your team get the most out of Play Console. To learn more about managing permissions, check out our Help Center.
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.
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?
Some apps and permissions are automatically exempted from revocation, like active Device Administrator apps used by enterprises, and permissions fixed by enterprise policy.
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.
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):
Build.VERSION.SDK_INT >= Build.VERSION_CODES.R
androidx.core.content.PackageManagerCompat.getUnusedAppRestrictionsStatus()
PackageManager.isAutoRevokeWhitelisted()
Intent.ACTION_AUTO_REVOKE_PERMISSIONS
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.
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.
getUnusedAppRestrictionsStatus()
API_31
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
