mirror of
https://github.com/android/skills.git
synced 2026-09-14 20:07:09 +08:00
Updates skills (2026-08-24 08:35)
This commit is contained in:
@@ -18,6 +18,7 @@
|
||||
"./camera/camerax",
|
||||
"./device-ai/appfunctions",
|
||||
"./devtools/android-cli",
|
||||
"./identity/restore-credentials",
|
||||
"./identity/verified-email",
|
||||
"./jetpack-compose/adaptive",
|
||||
"./jetpack-compose/migration/migrate-xml-views-to-jetpack-compose",
|
||||
|
||||
@@ -35,6 +35,11 @@
|
||||
"path": "./devtools/android-cli"
|
||||
}
|
||||
},
|
||||
{
|
||||
"source": {
|
||||
"path": "./identity/restore-credentials"
|
||||
}
|
||||
},
|
||||
{
|
||||
"source": {
|
||||
"path": "./identity/verified-email"
|
||||
|
||||
@@ -6,7 +6,7 @@ description: Upgrades, or migrates, an Android project to use Android Gradle Plu
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-18'
|
||||
keywords:
|
||||
- Android Gradle Plugin 9
|
||||
- AGP 9
|
||||
@@ -18,13 +18,23 @@ metadata:
|
||||
|
||||
## Migration guide
|
||||
|
||||
See the [AGP 9 migration guide](references/android/build/releases/agp-9-0-0-release-notes.md) for the major changes, many breaking, in AGP 9 compared to AGP 8.
|
||||
See the [AGP 9 migration guide](references/android/build/releases/agp-9-0-0-release-notes.md) for the major changes, many
|
||||
breaking, in AGP 9 compared to AGP 8.
|
||||
|
||||
## Requirements
|
||||
|
||||
If the user requests to update or migrate to AGP 9, first check the AGP version used in the project. If it is lower than 9, stop and ask the user to run the AGP Upgrade Assistant in Android Studio to update to the latest stable version of AGP, and confirm when done. The user may also request that this requirement be skipped; if this is the case, you should update the version of AGP to the latest stable version as part of the AGP 9 migration. See the [AGP 9 migration guide](references/android/build/releases/agp-9-0-0-release-notes.md) for how to do this.
|
||||
If the user requests to update or migrate to AGP 9, first check the AGP version
|
||||
used in the project. If it is lower than 9, stop and ask the user to run the AGP
|
||||
Upgrade Assistant in Android Studio to update to the latest stable version of
|
||||
AGP, and confirm when done. The user may also request that this requirement be
|
||||
skipped; if this is the case, you should update the version of AGP to the latest
|
||||
stable version as part of the AGP 9 migration. See the
|
||||
[AGP 9 migration guide](references/android/build/releases/agp-9-0-0-release-notes.md) for how to do this.
|
||||
|
||||
Each version of AGP has its own set of compatibilities with other tools, such as Gradle, JDK, and Kotlin. The release notes for each of these versions will include a **Compatibility** table indicating the minimum versions for these tools.
|
||||
Each version of AGP has its own set of compatibilities with other tools, such as
|
||||
Gradle, JDK, and Kotlin. The release notes for each of these versions will
|
||||
include a **Compatibility** table indicating the minimum versions for these
|
||||
tools.
|
||||
|
||||
Do not use this skill for KMP projects, as they are unsupported.
|
||||
|
||||
@@ -34,7 +44,8 @@ If AGP is already at 9 or higher, then do the following:
|
||||
|
||||
### Step 1: Update dependencies
|
||||
|
||||
If KSP (`com.google.devtools.ksp`) is used in the project, ensure it is on version 2.3.6 or higher.
|
||||
If KSP (`com.google.devtools.ksp`) is used in the project, ensure it is on
|
||||
version 2.3.6 or higher.
|
||||
|
||||
If Hilt is used in the project, ensure it is on version 2.59.2 or higher.
|
||||
|
||||
@@ -46,15 +57,19 @@ See [the guide](references/android/build/migrate-to-built-in-kotlin.md) for deta
|
||||
|
||||
See [the guide](references/android/build/releases/agp-9-0-0-release-notes.md) for detailed information.
|
||||
|
||||
See also [gradle-recipes](references/recipes.md) for examples on how to migrate old code to code that is compatible with AGP 9 and the new DSL.
|
||||
See also [gradle-recipes](references/recipes.md) for examples on how to migrate old code to code
|
||||
that is compatible with AGP 9 and the new DSL.
|
||||
|
||||
### Step 4. Migrate kapt to KSP or legacy-kapt
|
||||
|
||||
If KSP (`com.google.devtools.ksp`) or kapt (`org.jetbrains.kotlin.kapt`) are used in the project, see [KSP, kapt, and legacy-kapt](references/ksp-kapt.md) for detailed migration steps.
|
||||
If KSP (`com.google.devtools.ksp`) or kapt (`org.jetbrains.kotlin.kapt`) are
|
||||
used in the project, see [KSP, kapt, and legacy-kapt](references/ksp-kapt.md) for detailed migration
|
||||
steps.
|
||||
|
||||
### Step 5. BuildConfig
|
||||
|
||||
If any Android module contains custom BuildConfig fields, see [BuildConfig](references/buildconfig.md) for detailed information.
|
||||
If any Android module contains custom BuildConfig fields, see [BuildConfig](references/buildconfig.md)
|
||||
for detailed information.
|
||||
|
||||
### Step 6. Update gradle.properties
|
||||
|
||||
@@ -84,4 +99,5 @@ After migration, verify the following:
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Paparazzi v2.0.0-alpha04 and lower versions have issues with AGP 9. See [references/paparazzi-gradle-9.md](references/paparazzi-gradle-9.md) for details.
|
||||
Paparazzi v2.0.0-alpha04 and lower versions have issues with AGP 9. See
|
||||
[references/paparazzi-gradle-9.md](references/paparazzi-gradle-9.md) for details.
|
||||
|
||||
+79
-25
@@ -1,20 +1,33 @@
|
||||
Android Gradle plugin 9.0 introduces built-in Kotlin support and enables it by default. That means you no longer have to apply the `org.jetbrains.kotlin.android` (or `kotlin-android`) plugin in your build files to compile Kotlin source files. With built-in Kotlin, your build files are simpler and you can avoid compatibility issues between AGP and the `kotlin-android` plugin.
|
||||
Android Gradle plugin 9.0 introduces built-in Kotlin support and enables it
|
||||
by default. That means you no longer have to apply the
|
||||
`org.jetbrains.kotlin.android` (or `kotlin-android`) plugin in your build files
|
||||
to compile Kotlin source files.
|
||||
With built-in Kotlin, your build files are simpler and you can avoid
|
||||
compatibility issues between AGP and the `kotlin-android` plugin.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Built-in Kotlin replaces the `kotlin-android` plugin only. If you are writing a Kotlin Multiplatform (KMP) library module, you still need to apply the `org.jetbrains.kotlin.multiplatform` plugin and the [`com.android.kotlin.multiplatform.library`](https://developer.android.com/kotlin/multiplatform/plugin) plugin. Also, using the `org.jetbrains.kotlin.multiplatform` plugin together with the `com.android.library` or `com.android.application` plugin is no longer allowed when built-in Kotlin is enabled.
|
||||
|
||||
## Enable built-in Kotlin
|
||||
|
||||
You need AGP 9.0 or higher to have built-in Kotlin support. AGP 9.0 already enables built-in Kotlin for all your modules where you apply AGP, so you don't need to do anything to enable it. However, if you previously [opted out of built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin) by setting `android.builtInKotlin=false` in the `gradle.properties` file, you need to remove that setting or set it to `true`.
|
||||
You need AGP 9.0 or higher to have built-in Kotlin support.
|
||||
AGP 9.0 already enables built-in Kotlin for all your modules where you apply
|
||||
AGP, so you don't need to do anything to enable it. However, if you previously
|
||||
[opted out of built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin) by setting `android.builtInKotlin=false`
|
||||
in the `gradle.properties` file, you need to remove that setting or set it to
|
||||
`true`.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** You can also enable built-in Kotlin for [one module at a time](https://developer.android.com/build/migrate-to-built-in-kotlin#module-by-module-migration).
|
||||
|
||||
Built-in Kotlin requires some changes to your project, so after you have built-in Kotlin enabled, follow the next steps to migrate your project.
|
||||
Built-in Kotlin requires some changes to your project, so after you
|
||||
have built-in Kotlin enabled, follow the next steps to migrate your project.
|
||||
|
||||
## Migration steps
|
||||
|
||||
After you upgrade your project from an older AGP version to AGP 9.0 or after you manually [enable built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#enable-built-in-kotlin), you might see the following error message:
|
||||
After you upgrade your project from an older AGP version to AGP 9.0 or after
|
||||
you manually [enable built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#enable-built-in-kotlin), you might see the following error
|
||||
message:
|
||||
|
||||
Failed to apply plugin 'org.jetbrains.kotlin.android'.
|
||||
> Cannot add extension with name 'kotlin', as there is an extension already registered with that name.
|
||||
@@ -24,7 +37,8 @@ After you upgrade your project from an older AGP version to AGP 9.0 or after you
|
||||
Failed to apply plugin 'com.jetbrains.kotlin.android'
|
||||
> The 'org.jetbrains.kotlin.android' plugin is no longer required for Kotlin support since AGP 9.0.
|
||||
|
||||
This error occurs because built-in Kotlin requires some changes to your project. To resolve this error, follow these steps:
|
||||
This error occurs because built-in Kotlin requires some changes to your project.
|
||||
To resolve this error, follow these steps:
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If you're not yet ready to migrate your project, you can also [opt out of built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin).
|
||||
@@ -36,7 +50,10 @@ This error occurs because built-in Kotlin requires some changes to your project.
|
||||
|
||||
### 1. Remove the `kotlin-android` plugin
|
||||
|
||||
Remove the `org.jetbrains.kotlin.android` (or `kotlin-android`) plugin from the module-level build files where you apply it. The exact code to remove depends on whether you use [version catalogs](https://docs.gradle.org/current/userguide/version_catalogs.html) to declare plugins.
|
||||
Remove the `org.jetbrains.kotlin.android` (or `kotlin-android`) plugin from
|
||||
the module-level build files where you apply it.
|
||||
The exact code to remove depends on
|
||||
whether you use [version catalogs](https://docs.gradle.org/current/userguide/version_catalogs.html) to declare plugins.
|
||||
|
||||
### With version catalogs
|
||||
|
||||
@@ -120,7 +137,8 @@ plugins {
|
||||
}
|
||||
```
|
||||
|
||||
If you use version catalogs, also remove the plugin definition from the version catalog TOML file (usually `gradle/libs.versions.toml`):
|
||||
If you use version catalogs, also remove the plugin definition from the
|
||||
version catalog TOML file (usually `gradle/libs.versions.toml`):
|
||||
|
||||
```toml
|
||||
[plugins]
|
||||
@@ -129,11 +147,16 @@ kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "KOTLIN_VE
|
||||
|
||||
### 2. Migrate the `kotlin-kapt` plugin if necessary
|
||||
|
||||
The `org.jetbrains.kotlin.kapt` (or `kotlin-kapt`) plugin is incompatible with built-in Kotlin. If you use `kapt`, we recommend that you [migrate your project to KSP](https://developer.android.com/build/migrate-to-ksp).
|
||||
The `org.jetbrains.kotlin.kapt` (or `kotlin-kapt`) plugin is incompatible with
|
||||
built-in Kotlin. If you use `kapt`, we recommend that you
|
||||
[migrate your project to KSP](https://developer.android.com/build/migrate-to-ksp).
|
||||
|
||||
If you can't migrate to KSP yet, replace the `kotlin-kapt` plugin with the `com.android.legacy-kapt` plugin, using the same version as your Android Gradle plugin.
|
||||
If you can't migrate to KSP yet, replace the `kotlin-kapt` plugin with the
|
||||
`com.android.legacy-kapt` plugin, using the same version as your Android Gradle
|
||||
plugin.
|
||||
|
||||
For example, with version catalogs, update your version catalog TOML file as follows:
|
||||
For example, with version catalogs, update your version catalog TOML
|
||||
file as follows:
|
||||
|
||||
```toml
|
||||
[plugins]
|
||||
@@ -193,7 +216,8 @@ plugins {
|
||||
|
||||
### 3. Migrate the `android.kotlinOptions{}` DSL if necessary
|
||||
|
||||
If you use the `android.kotlinOptions{}` DSL, you need to migrate it to the [`kotlin.compilerOptions{}`](https://kotlinlang.org/docs/gradle-compiler-options.html#migrate-from-kotlinoptions-to-compileroptions) DSL.
|
||||
If you use the `android.kotlinOptions{}` DSL, you need to
|
||||
migrate it to the [`kotlin.compilerOptions{}`](https://kotlinlang.org/docs/gradle-compiler-options.html#migrate-from-kotlinoptions-to-compileroptions) DSL.
|
||||
|
||||
For example, update this code:
|
||||
|
||||
@@ -250,9 +274,15 @@ kotlin {
|
||||
|
||||
### 4. Migrate the `kotlin.sourceSets{}` DSL if necessary
|
||||
|
||||
When you use the `kotlin-android` plugin, AGP lets you add additional Kotlin source directories using either the [`android.sourceSets{}`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/AndroidSourceSet) DSL or the [`kotlin.sourceSets{}`](https://kotlinlang.org/api/kotlin-gradle-plugin/kotlin-gradle-plugin-api/org.jetbrains.kotlin.gradle.plugin/-kotlin-source-set/) DSL. With the `android.sourceSets{}` DSL, you can add the directories to either the `AndroidSourceSet.kotlin` set or the `AndroidSourceSet.java` set.
|
||||
When you use the `kotlin-android` plugin, AGP lets you add additional Kotlin
|
||||
source directories using either the [`android.sourceSets{}`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/AndroidSourceSet) DSL or the
|
||||
[`kotlin.sourceSets{}`](https://kotlinlang.org/api/kotlin-gradle-plugin/kotlin-gradle-plugin-api/org.jetbrains.kotlin.gradle.plugin/-kotlin-source-set/) DSL.
|
||||
With the `android.sourceSets{}` DSL, you can add the directories to either the
|
||||
`AndroidSourceSet.kotlin` set or the `AndroidSourceSet.java` set.
|
||||
|
||||
With built-in Kotlin, the only supported option is to add the directories to the `AndroidSourceSet.kotlin` set using the `android.sourceSets{}` DSL. If you use unsupported options, migrate them as follows:
|
||||
With built-in Kotlin, the only supported option is to add the directories to the
|
||||
`AndroidSourceSet.kotlin` set using the `android.sourceSets{}` DSL.
|
||||
If you use unsupported options, migrate them as follows:
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -292,7 +322,10 @@ android.sourceSets.named("main") {
|
||||
}
|
||||
```
|
||||
|
||||
If you want to add a Kotlin source directory to a specific variant or if the directory is generated by a task, you can use the [`addStaticSourceDirectory`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/SourceDirectories#addStaticSourceDirectory(kotlin.String)) or [`addGeneratedSourceDirectory`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/SourceDirectories#addGeneratedSourceDirectory(org.gradle.api.tasks.TaskProvider,kotlin.Function1)) methods in the [variant API](https://developer.android.com/build/extend-agp#variant-api-artifacts-tasks):
|
||||
If you want to add a Kotlin source directory to a specific variant or if the
|
||||
directory is generated by a task, you can use the
|
||||
[`addStaticSourceDirectory`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/SourceDirectories#addStaticSourceDirectory(kotlin.String)) or [`addGeneratedSourceDirectory`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/SourceDirectories#addGeneratedSourceDirectory(org.gradle.api.tasks.TaskProvider,kotlin.Function1)) methods
|
||||
in the [variant API](https://developer.android.com/build/extend-agp#variant-api-artifacts-tasks):
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -314,36 +347,57 @@ androidComponents.onVariants { variant ->
|
||||
|
||||
## Report issues
|
||||
|
||||
If you encounter issues after completing the previous steps, review the known issues in [issue #438678642](https://issuetracker.google.com/438678642) and give us feedback if needed.
|
||||
If you encounter issues after completing the previous steps,
|
||||
review the known issues in [issue #438678642](https://issuetracker.google.com/438678642) and give us
|
||||
feedback if needed.
|
||||
|
||||
## Opt out of built-in Kotlin
|
||||
|
||||
If you are unable to migrate your project to use built-in Kotlin, set `android.builtInKotlin=false` in the `gradle.properties` file to temporarily disable it. When you do that, the build shows a warning reminding you to migrate to built-in Kotlin as you won't be able to disable built-in Kotlin in AGP 10.0.
|
||||
If you are unable to migrate your project to use built-in Kotlin, set
|
||||
`android.builtInKotlin=false` in the `gradle.properties` file to temporarily
|
||||
disable it.
|
||||
When you do that, the build shows a warning reminding you to migrate to built-in
|
||||
Kotlin as you won't be able to disable built-in Kotlin in AGP 10.0.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** You also need to set `android.newDsl=false` to opt out of the [new DSL](https://developer.android.com/r/tools/new-dsl) because the `kotlin-android` plugin is not compatible with it.
|
||||
|
||||
Once you're ready to migrate your project, [enable built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#enable-built-in-kotlin) and follow the [migration steps](https://developer.android.com/build/migrate-to-built-in-kotlin#migration-steps).
|
||||
Once you're ready to migrate your project, [enable built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#enable-built-in-kotlin)
|
||||
and follow the [migration steps](https://developer.android.com/build/migrate-to-built-in-kotlin#migration-steps).
|
||||
|
||||
## Module-by-module migration
|
||||
|
||||
The `android.builtInKotlin` Gradle property lets you enable or disable built-in Kotlin for all your modules where you apply AGP.
|
||||
The `android.builtInKotlin` Gradle property lets you enable or disable built-in
|
||||
Kotlin for all your modules where you apply AGP.
|
||||
|
||||
If migrating all your modules at once is challenging, you can migrate one module at a time:
|
||||
If migrating all your modules at once is challenging, you can migrate one module
|
||||
at a time:
|
||||
|
||||
1. Set `android.builtInKotlin=false` in the `gradle.properties` file to disable built-in Kotlin for all modules.
|
||||
1. Set `android.builtInKotlin=false` in the `gradle.properties` file to
|
||||
disable built-in Kotlin for all modules.
|
||||
|
||||
2. Apply the `com.android.built-in-kotlin` plugin to the module you want to enable built-in Kotlin, using the same version as your Android Gradle plugin.
|
||||
2. Apply the `com.android.built-in-kotlin` plugin to the module
|
||||
you want to enable built-in Kotlin, using the same version as your
|
||||
Android Gradle plugin.
|
||||
|
||||
3. Follow the previous [migration steps](https://developer.android.com/build/migrate-to-built-in-kotlin#migration-steps) to migrate this module to built-in Kotlin.
|
||||
3. Follow the previous [migration steps](https://developer.android.com/build/migrate-to-built-in-kotlin#migration-steps) to migrate this module to
|
||||
built-in Kotlin.
|
||||
|
||||
4. Once you've migrated all your modules, remove the `android.builtInKotlin=false` setting in `gradle.properties` and the `com.android.built-in-kotlin` plugin in your build files.
|
||||
4. Once you've migrated all your modules, remove the
|
||||
`android.builtInKotlin=false` setting in `gradle.properties`
|
||||
and the `com.android.built-in-kotlin` plugin in your build files.
|
||||
|
||||
## Option to selectively disable built-in Kotlin
|
||||
|
||||
Android Gradle plugin 9.0 enables built-in Kotlin for all modules where it is applied. We recommend disabling built-in Kotlin selectively for modules that don't have Kotlin sources in large projects. This removes both the Kotlin compilation task, which has a small build performance cost, and the automatic dependency on the Kotlin standard library.
|
||||
Android Gradle plugin 9.0 enables built-in Kotlin for all modules where it is
|
||||
applied.
|
||||
We recommend disabling built-in Kotlin selectively for modules that don't have
|
||||
Kotlin sources in large projects.
|
||||
This removes both the Kotlin compilation task, which has a small build
|
||||
performance cost, and the automatic dependency on the Kotlin standard library.
|
||||
|
||||
To disable built-in Kotlin for a module, set `enableKotlin = false` in that module's build file:
|
||||
To disable built-in Kotlin for a module,
|
||||
set `enableKotlin = false` in that module's build file:
|
||||
|
||||
### Kotlin
|
||||
|
||||
|
||||
+234
-75
@@ -1,16 +1,25 @@
|
||||
<br />
|
||||
|
||||
Android Gradle plugin 9.0 is a major release that brings API and behavior changes.
|
||||
Android Gradle plugin 9.0 is a major release that brings API and behavior
|
||||
changes.
|
||||
|
||||
To update to Android Gradle plugin 9.0.1, use the [Android Gradle plugin Upgrade Assistant](https://developer.android.com/build/agp-upgrade-assistant). The AGP upgrade assistant helps preserve existing behaviors when upgrading your project whenever appropriate, so you can upgrade your project to use AGP 9.0 even if you're not ready to adopt all the new defaults in AGP 9.0.
|
||||
To update to Android Gradle plugin 9.0.1, use the
|
||||
[Android Gradle plugin Upgrade Assistant](https://developer.android.com/build/agp-upgrade-assistant). The AGP upgrade assistant helps
|
||||
preserve existing behaviors when upgrading your project whenever appropriate, so
|
||||
you can upgrade your project to use AGP 9.0 even if you're not ready to
|
||||
adopt all the new defaults in AGP 9.0.
|
||||
|
||||
There are also two agent skills available to make the upgrade process easier. For a non-KMP app, try the [AGP 9 upgrade skill](https://github.com/android/skills/tree/main/build/agp/agp-9-upgrade) from the Android skills repository. For a KMP app, try the [AGP 9 upgrade skill](https://github.com/Kotlin/kotlin-agent-skills/tree/main/skills/kotlin-tooling-agp9-migration) from JetBrains. For more information about using skills in Android Studio, see [Extend Agent Mode with skills](https://developer.android.com/studio/gemini/skills).
|
||||
There are also two agent skills available to make the upgrade process easier.
|
||||
For a non-KMP app, try the [AGP 9 upgrade skill](https://github.com/android/skills/tree/main/build-system/agp/agp-9-upgrade) from the
|
||||
Android skills repository. For a KMP app, try the [AGP 9 upgrade
|
||||
skill](https://github.com/Kotlin/kotlin-agent-skills/tree/main/skills/kotlin-tooling-agp9-migration) from JetBrains. For more information about using skills
|
||||
in Android Studio, see [Extend Agent Mode with skills](https://developer.android.com/studio/gemini/skills).
|
||||
|
||||
## Compatibility
|
||||
|
||||
The maximum API level that Android Gradle plugin 9.0 supports is API level 36.1. Here is other compatibility info:
|
||||
The maximum API level that Android Gradle plugin 9.0 supports is API level 36.1.
|
||||
Here is other compatibility info:
|
||||
|
||||
<br />
|
||||
|
||||
| | Minimum version | Default version | Notes |
|
||||
|---:|:---:|:---:|:---:|
|
||||
@@ -23,25 +32,52 @@ The maximum API level that Android Gradle plugin 9.0 supports is API level 36.1.
|
||||
|
||||
## The `android` DSL classes now only implement the new public interfaces
|
||||
|
||||
Over the last several years, we have introduced [new interfaces](https://developer.android.com/reference/tools/gradle-api) for our DSL and API in order to better control which APIs are public. AGP versions 7.x and 8.x still used the old DSL types (for example `BaseExtension`) which also implemented the new public interfaces, in order to maintain compatibility as work progressed on the interfaces.
|
||||
Over the last several years, we have introduced
|
||||
[new interfaces](https://developer.android.com/reference/tools/gradle-api) for our DSL and API in order to
|
||||
better control which APIs are public. AGP versions
|
||||
7.x and 8.x still used the old DSL types (for example `BaseExtension`) which
|
||||
also implemented the new public interfaces, in order to maintain compatibility
|
||||
as work progressed on the interfaces.
|
||||
|
||||
AGP 9.0 uses our new DSL interfaces exclusively, and the implementations have changed to new types that are fully hidden. This also removes access to the old, deprecated variant API.
|
||||
AGP 9.0 uses our new DSL interfaces exclusively,
|
||||
and the implementations have changed to new types that are fully hidden. This
|
||||
also removes access to the old, deprecated variant API.
|
||||
|
||||
To update to AGP 9.0, you might need to do the following:
|
||||
|
||||
- **Ensure your project is compatible with [built-in Kotlin](https://developer.android.com/build/releases/agp-9-0-0-release-notes#android-gradle-plugin-built-in-kotlin):** The `org.jetbrains.kotlin.android` plugin is not compatible with the new DSL.
|
||||
- **Switch KMP projects to the [Android Gradle Library Plugin for KMP](https://developer.android.com/kotlin/multiplatform/plugin):** Using the `org.jetbrains.kotlin.multiplatform` plugin in the same Gradle subproject as the `com.android.library` and `com.android.application` plugins is not compatible with the new DSL.
|
||||
- **Ensure your project is compatible with [built-in
|
||||
Kotlin](https://developer.android.com/build/releases/agp-9-0-0-release-notes#android-gradle-plugin-built-in-kotlin):** The `org.jetbrains.kotlin.android` plugin is not compatible with the new DSL.
|
||||
- **Switch KMP projects to the
|
||||
[Android Gradle Library Plugin for KMP](https://developer.android.com/kotlin/multiplatform/plugin):**
|
||||
Using the `org.jetbrains.kotlin.multiplatform` plugin in the same Gradle
|
||||
subproject as the `com.android.library` and `com.android.application` plugins
|
||||
is not compatible with the new DSL.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The new KMP integration does not support using KMP and the Android Application plugin in the same Gradle subproject. To migrate, extract your Android app to a separate subproject.
|
||||
|
||||
- **Update your build files:** While the change of interfaces is meant to keep the DSL as similar as possible, there might be [some small changes](https://developer.android.com/build/releases/agp-9-0-0-release-notes#android-gradle-plugin-changed-dsl).
|
||||
- **Update your build files:**
|
||||
While the change of interfaces is meant to keep
|
||||
the DSL as similar as possible, there might be
|
||||
[some small changes](https://developer.android.com/build/releases/agp-9-0-0-release-notes#android-gradle-plugin-changed-dsl).
|
||||
|
||||
- **Update your custom build logic to reference the new DSL and API:** Replace any references to the internal DSL with the public DSL interfaces. In most cases this will be a one-to-one replacement. Replace any use of the `applicationVariants` and similar APIs with the new [`androidComponents` API](https://developer.android.com/build/extend-agp#variant-api-artifacts-tasks). This might be more complex, as the `androidComponents` API is designed to be more stable to keep plugins compatible longer. Check our [Gradle Recipes](https://github.com/android/gradle-recipes/tree/agp-9.0) for examples.
|
||||
- **Update your custom build logic to reference the new DSL and API:**
|
||||
Replace any references to the internal DSL with the public DSL interfaces.
|
||||
In most cases this will be a one-to-one replacement.
|
||||
Replace any use of the `applicationVariants` and similar APIs with the new
|
||||
[`androidComponents` API](https://developer.android.com/build/extend-agp#variant-api-artifacts-tasks).
|
||||
This might be more complex, as the `androidComponents` API
|
||||
is designed to be more stable to keep plugins compatible longer. Check our
|
||||
[Gradle Recipes](https://github.com/android/gradle-recipes/tree/agp-9.0)
|
||||
for examples.
|
||||
|
||||
- **Update third-party plugins:** Some third-party plugins might still depend on interfaces or APIs that are no longer exposed. Migrate to versions of those plugins which are compatible with AGP 9.0.
|
||||
- **Update third-party plugins:**
|
||||
Some third-party plugins might still depend on interfaces or APIs that are
|
||||
no longer exposed. Migrate to versions of those plugins which are compatible
|
||||
with AGP 9.0.
|
||||
|
||||
The switch to the new DSL interfaces prevents plugins and Gradle build scripts using various deprecated APIs, including:
|
||||
The switch to the new DSL interfaces prevents plugins and Gradle build scripts
|
||||
using various deprecated APIs, including:
|
||||
|
||||
| Deprecated API in the `android` block | Function | Replacement |
|
||||
|---|---|---|
|
||||
@@ -54,43 +90,73 @@ The switch to the new DSL interfaces prevents plugins and Gradle build scripts u
|
||||
| `generatePureSplits` | Generate configuration splits for instant apps. | The ability to ship configuration splits is now built in to Android app bundles. |
|
||||
| `aidlPackagedList` | AIDL files to package in the AAR to expose it as API for libraries and apps that depend on this library. | This is still exposed on [`LibraryExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/LibraryExtension) but not on the other extension types. |
|
||||
|
||||
If you update to AGP 9.0 and see the following error message, it means that your project is still referencing some of the old types:
|
||||
If you update to AGP 9.0 and see the following error message, it means that
|
||||
your project is still referencing some of the old types:
|
||||
|
||||
java.lang.ClassCastException: class com.android.build.gradle.internal.dsl.ApplicationExtensionImpl$AgpDecorated_Decorated
|
||||
cannot be cast to class com.android.build.gradle.BaseExtension
|
||||
|
||||
If you are blocked by incompatible third-party plugins, you can opt out and get back the old implementations for the DSL, as well as the old variant API. While doing this, the new interfaces are also available, and you can still update your own build logic to the new API. To opt out, include this line in your `gradle.properties` file:
|
||||
If you are blocked by incompatible third-party plugins, you can opt out and
|
||||
get back the old implementations for the DSL, as well as the old variant API.
|
||||
While doing this, the new interfaces are also available, and you can still
|
||||
update your own build logic to the new API. To opt out, include this line in
|
||||
your `gradle.properties` file:
|
||||
|
||||
android.newDsl=false
|
||||
|
||||
Alternatively, for a more gradual migration, AGP 9.4 lets you opt out individual modules. To learn how, see [Variant API module opt-out](https://developer.android.com/build/releases/agp-9-4-0-release-notes#new-dsl-opt-out).
|
||||
Alternatively, for a more gradual migration, AGP 9.4 lets you opt out individual
|
||||
modules. To learn how, see [Variant API module opt-out](https://developer.android.com/build/releases/agp-9-4-0-release-notes#new-dsl-opt-out).
|
||||
|
||||
The previous classes are marked as deprecated in AGP 9.0. This means projects that opt out of the `newDsl` flag will see deprecation warnings, including on the `android` block itself.
|
||||
The previous classes are marked as deprecated in AGP 9.0. This means projects
|
||||
that opt out of the `newDsl` flag will see deprecation warnings, including on
|
||||
the `android` block itself.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Caution:** The ability to opt-out will be removed in AGP 10.0 (mid-2026).
|
||||
|
||||
You can also start upgrading to the new APIs before upgrading to AGP 9.0. The new interfaces have been present for many AGP versions and so you can have a mix of new and old. The [AGP API reference docs](https://developer.android.com/reference/tools/gradle-api) show the API surface for each AGP version, and when each class, method and field was added.
|
||||
You can also start upgrading to the new APIs before upgrading to AGP 9.0. The
|
||||
new interfaces have been present for many AGP versions and so you can have a mix
|
||||
of new and old. The [AGP API reference docs](https://developer.android.com/reference/tools/gradle-api) show the API
|
||||
surface for each AGP version, and when each class, method and field was
|
||||
added.
|
||||
|
||||
We're reaching out to the authors of commonly used plugins to help them adapt and release plugins that are fully compatible with the new modes, and will continue to enhance the AGP Upgrade Assistant in Android Studio to guide you through the migration.
|
||||
We're reaching out to the authors of commonly used plugins to help them adapt
|
||||
and release plugins that are fully compatible with the new modes, and will
|
||||
continue to enhance the AGP Upgrade Assistant in Android Studio to guide you
|
||||
through the migration.
|
||||
|
||||
If you find that the new DSL or Variant API are missing capabilities or features, please file an [issue](https://issuetracker.google.com/issues/new?component=192708&template=840533) as soon as possible.
|
||||
If you find that the new DSL or Variant API are missing capabilities or
|
||||
features, please file an [issue](https://issuetracker.google.com/issues/new?component=192708&template=840533) as soon as possible.
|
||||
|
||||
## Built-in Kotlin
|
||||
|
||||
Android Gradle plugin 9.0 introduces built-in Kotlin support and enables it by default. That means you no longer have to apply the `org.jetbrains.kotlin.android` (or `kotlin-android`) plugin in your build files to compile Kotlin source files. This simplifies the Kotlin integration with AGP, avoids the use of deprecated APIs, and improves performance in some cases.
|
||||
Android Gradle plugin 9.0 introduces built-in Kotlin support and enables it
|
||||
by default. That means you no longer have to apply the
|
||||
`org.jetbrains.kotlin.android` (or `kotlin-android`) plugin in your build files
|
||||
to compile Kotlin source files.
|
||||
This simplifies the Kotlin integration with AGP, avoids the use of
|
||||
deprecated APIs, and improves performance in some cases.
|
||||
|
||||
Therefore, when you upgrade your project to AGP 9.0, you need to also [migrate to built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin) or [opt out](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin).
|
||||
Therefore, when you upgrade your project to AGP 9.0, you need to also
|
||||
[migrate to built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin) or [opt out](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin).
|
||||
|
||||
You can also [selectively disable built-in Kotlin support](https://developer.android.com/build/migrate-to-built-in-kotlin#selectively-disable) for Gradle subprojects that don't have Kotlin sources.
|
||||
You can also [selectively disable built-in Kotlin support](https://developer.android.com/build/migrate-to-built-in-kotlin#selectively-disable) for Gradle
|
||||
subprojects that don't have Kotlin sources.
|
||||
|
||||
## Runtime dependency on Kotlin Gradle plugin
|
||||
|
||||
To provide [built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin) support, Android Gradle plugin 9.0 now has a runtime dependency on Kotlin Gradle plugin (KGP) 2.2.10. That means you no longer have to declare a KGP version, and if you use a KGP version lower than 2.2.10, Gradle will automatically upgrade your KGP version to 2.2.10. Likewise, if you use a KSP version lower than 2.2.10-2.0.2, AGP will upgrade it to 2.2.10-2.0.2 to match the KGP version.
|
||||
To provide [built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin) support, Android Gradle plugin 9.0 now has a
|
||||
runtime dependency on Kotlin Gradle plugin (KGP) 2.2.10.
|
||||
That means you no longer have to declare a KGP version, and if you use a KGP
|
||||
version lower than 2.2.10, Gradle will automatically upgrade your KGP version to
|
||||
2.2.10.
|
||||
Likewise, if you use a KSP version lower than 2.2.10-2.0.2, AGP will upgrade it
|
||||
to 2.2.10-2.0.2 to match the KGP version.
|
||||
|
||||
### Upgrade to a higher KGP version
|
||||
|
||||
To use a higher version of KGP or KSP, add the following to your top-level build file:
|
||||
To use a higher version of KGP or KSP, add the following to your top-level build
|
||||
file:
|
||||
|
||||
buildscript {
|
||||
dependencies {
|
||||
@@ -104,9 +170,13 @@ To use a higher version of KGP or KSP, add the following to your top-level build
|
||||
|
||||
### Downgrade to a lower KGP version
|
||||
|
||||
You can only downgrade the KGP version if you've [opted out of built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin). This is because AGP 9.0 enables built-in Kotlin by default, and built-in Kotlin requires KGP 2.2.10 or higher.
|
||||
You can only downgrade the KGP version if you've
|
||||
[opted out of built-in Kotlin](https://developer.android.com/build/migrate-to-built-in-kotlin#opt-out-of-built-in-kotlin).
|
||||
This is because AGP 9.0 enables built-in Kotlin by default, and built-in Kotlin
|
||||
requires KGP 2.2.10 or higher.
|
||||
|
||||
To use a lower version of KGP or KSP, declare that version in your top-level build file using a [strict version](https://docs.gradle.org/current/userguide/dependency_versions.html#sec:strict-version) declaration:
|
||||
To use a lower version of KGP or KSP, declare that version in your top-level
|
||||
build file using a [strict version](https://docs.gradle.org/current/userguide/dependency_versions.html#sec:strict-version) declaration:
|
||||
|
||||
buildscript {
|
||||
dependencies {
|
||||
@@ -129,13 +199,17 @@ Note that the minimum KGP version you can downgrade to is 2.0.0.
|
||||
|
||||
## IDE support for test fixtures
|
||||
|
||||
AGP 9.0 brings full Android Studio IDE support for [test fixtures](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/TestFixtures).
|
||||
AGP 9.0 brings full Android Studio IDE support for
|
||||
[test fixtures](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/TestFixtures).
|
||||
|
||||
## Fused Library Plugin
|
||||
|
||||
The Fused Library Plugin (Preview) lets you publish multiple libraries as a single Android Library AAR. This can make it easier for your users to depend on your published artifacts.
|
||||
The Fused Library Plugin (Preview) lets you publish multiple
|
||||
libraries as a single Android Library AAR. This can make it easier for your
|
||||
users to depend on your published artifacts.
|
||||
|
||||
For information about getting started, see [Publish multiple Android libraries as one with Fused Library](https://developer.android.com/build/publish-library/fused-library).
|
||||
For information about getting started, see
|
||||
[Publish multiple Android libraries as one with Fused Library](https://developer.android.com/build/publish-library/fused-library).
|
||||
|
||||
## Behavior changes
|
||||
|
||||
@@ -146,7 +220,8 @@ Android Gradle plugin 9.0 has the following new behaviors:
|
||||
| Android Gradle plugin 9.0 uses NDK version `r28c` by default. | Consider specifying the NDK version you want to use explicitly. |
|
||||
| Android Gradle plugin 9.0 by default requires consumers of a library to use the same or higher compile SDK version. | Use the same or higher compile SDK when consuming a library. If this is not possible, or you want to give consumers of a library you publish more time to switch, set [`AarMetadata.minCompileSdk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/AarMetadata#minCompileSdk()) explicitly. |
|
||||
|
||||
AGP 9.0 includes updates to the following Gradle properties' defaults. This gives you the choice to preserve the AGP 8.13 behavior when upgrading:
|
||||
AGP 9.0 includes updates to the following Gradle properties' defaults.
|
||||
This gives you the choice to preserve the AGP 8.13 behavior when upgrading:
|
||||
|
||||
| Property | Function | Change from AGP 8.13 to AGP 9.0 | Recommendation |
|
||||
|---|---|---|---|
|
||||
@@ -161,7 +236,7 @@ AGP 9.0 includes updates to the following Gradle properties' defaults. This give
|
||||
| `android.onlyEnableUnitTestForTheTestedBuildType` | Only creates unit test components for the tested build type. In the default project this results in a single unit test for debug, where the previous behavor was to have unit tests run for debug or release. | `false` → `true` | If your project doesn't require tests to run for both debug and release, no change is required. |
|
||||
| `android.proguard.failOnMissingFiles` | Fails the build with an error if any of the keep files specified in the AGP DSL don't exist on disk. Before this change typos in filenames would result in files being silently ignored. | `false` → `true` | Remove any invalid proguard files declarations |
|
||||
| `android.r8.optimizedResourceShrinking` | Allows R8 to keep fewer Android resources by considering classes and Android resources together. | `false` → `true` | If your project's keep rules are already complete, no change is required. |
|
||||
| `android.r8.strictFullModeForKeepRules` | Allows R8 to keep less by not implicitly keeping the default constructor when a class is kept. That is, `-keep class A` no longer implies `-keep class A { <init>(); }` | `false` → `true` | If your project's keep rules are already complete, no change is required. Replace `-keep class A` with `-keep class A { <init>(); }` in your project's keep rules for any cases where you need the default constructor to be kept. |
|
||||
| `android.r8.strictFullModeForKeepRules` | Allows R8 to keep less by not implicitly keeping the default constructor when a class is kept. That is, `-keep class A` no longer implies `-keep class A { <init>(); }` | `false` → `true` | If your project's keep rules are already complete, no change is required. <br /> Replace `-keep class A` with `-keep class A { <init>(); }` in your project's keep rules for any cases where you need the default constructor to be kept. |
|
||||
| `android.defaults.buildfeatures.resvalues` | Enables [`resValues`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasAndroidResources#resValues()) in all subprojects | `true` → `false` | Enable `resValues` in only the subprojects that need it by setting the following in those projects' Gradle build files: ``` android { buildFeatures { resValues = true } } ``` |
|
||||
| `android.defaults.buildfeatures.shaders` | Enables [shader compilation](https://developer.android.com/ndk/guides/graphics/shader-compilers) in all subprojects | `true` → `false` | Enable shader compilation in only the subprojects that contain shaders to be compiled by setting the following in those projects' Gradle build files: ``` android { buildFeatures { shaders = true } } ``` |
|
||||
| `android.r8.proguardAndroidTxt.disallowed` | In AGP 9.0, `getDefaultProguardFile()` will only support `proguard-android-optimize.txt` rather than `proguard-android.txt`. This is to prevent accidental usage of the `dontoptimize` flag, which is included in `proguard-android.txt`. | `false` → `true` | You can explicitly specify `dontoptimize` in a custom proguardFile if you want to avoid optimization, alongside using `proguard-android-optimize.txt`. Make sure to remove the `dontoptimize` flag from this file if possible, as it reduces R8 optimization benefits. If not, opt out by setting `android.r8.globalOptionsInConsumerRules.disallowed=false`. |
|
||||
@@ -185,9 +260,16 @@ Android Gradle plugin 9.0 has the following breaking DSL changes:
|
||||
|
||||
- The parameterization of [`CommonExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/CommonExtension) has been removed.
|
||||
|
||||
In itself, this is only a source-level breaking change to help avoid future source-level breaking changes, but it also means that the block methods need to move from [`CommonExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/CommonExtension) to [`ApplicationExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/ApplicationExtension), [`LibraryExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/LibraryExtension), [`DynamicFeatureExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/DynamicFeatureExtension) and [`TestExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/TestExtension).
|
||||
In itself, this is only a source-level breaking change to help
|
||||
avoid future source-level breaking changes, but it also means that
|
||||
the block methods need to move from [`CommonExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/CommonExtension) to
|
||||
[`ApplicationExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/ApplicationExtension), [`LibraryExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/LibraryExtension),
|
||||
[`DynamicFeatureExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/DynamicFeatureExtension) and [`TestExtension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/TestExtension).
|
||||
|
||||
When upgrading your project to AGP 9.0, refactor Gradle plugin code which uses those parameters or the block methods. For example the following plugin is updated to remove the type parameter and not rely on the removed block methods:
|
||||
When upgrading your project to AGP 9.0, refactor Gradle plugin code
|
||||
which uses those parameters or the block methods. For example the following
|
||||
plugin is updated to remove the type parameter and not rely on the
|
||||
removed block methods:
|
||||
|
||||
**AGP 8.13**
|
||||
|
||||
@@ -213,7 +295,8 @@ Android Gradle plugin 9.0 has the following breaking DSL changes:
|
||||
}
|
||||
}
|
||||
|
||||
For plugins which target a range of AGP versions, using the getter directly is binary compatible with AGP versions lower than 9.0.
|
||||
For plugins which target a range of AGP versions, using the getter directly
|
||||
is binary compatible with AGP versions lower than 9.0.
|
||||
|
||||
## Removed DSL
|
||||
|
||||
@@ -221,37 +304,50 @@ Android Gradle plugin 9.0 removes:
|
||||
|
||||
- [`AndroidSourceSet.jni`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/AndroidSourceSet#jni(kotlin.Function1)), because it was not functional.
|
||||
|
||||
- [`AndroidSourceSet.wearAppConfigurationName`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/AndroidSourceSet#wearAppConfigurationName()), as it relates to the removed embedded Wear OS app support.
|
||||
- [`AndroidSourceSet.wearAppConfigurationName`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/AndroidSourceSet#wearAppConfigurationName()), as it relates to the
|
||||
removed embedded Wear OS app support.
|
||||
|
||||
- [`BuildType.isRenderscriptDebuggable`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/BuildType#isRenderscriptDebuggable()), because it was not functional.
|
||||
|
||||
- [`DependencyVariantSelection`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/DependencyVariantSelection). It is replaced By [`DependencySelection`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/DependencySelection), which is exposed as [`kotlin.android.localDependencySelection`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/KotlinMultiplatformAndroidLibraryExtension#localDependencySelection(kotlin.Function1))
|
||||
- [`DependencyVariantSelection`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/DependencyVariantSelection). It is replaced By
|
||||
[`DependencySelection`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/DependencySelection), which is exposed as
|
||||
[`kotlin.android.localDependencySelection`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/KotlinMultiplatformAndroidLibraryExtension#localDependencySelection(kotlin.Function1))
|
||||
|
||||
- [`Installation.installOptions(String)`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/Installation#installOptions(kotlin.String)). It is replaced by the mutable property of [`Installation.installOptions`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/Installation#installOptions()).
|
||||
- [`Installation.installOptions(String)`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/Installation#installOptions(kotlin.String)). It is replaced by the
|
||||
mutable property of [`Installation.installOptions`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/Installation#installOptions()).
|
||||
|
||||
- The experimental, but never stabilized [`PostProcessing`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/PostProcessing) block.
|
||||
|
||||
- [`ProductFlavor.setDimension`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/ProductFlavor#setDimension(kotlin.String)), which is replaced by the [`dimension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/ProductFlavor#dimension()) property
|
||||
- [`ProductFlavor.setDimension`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/ProductFlavor#setDimension(kotlin.String)), which is replaced by the
|
||||
[`dimension`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/dsl/ProductFlavor#dimension()) property
|
||||
|
||||
- `LanguageSplitOptions`, which was only useful for [Google Play Instant](https://developer.android.com/topic/google-play-instant), which is deprecated.
|
||||
- `LanguageSplitOptions`, which was only useful for
|
||||
[Google Play Instant](https://developer.android.com/topic/google-play-instant), which is deprecated.
|
||||
|
||||
- [`DensitySplit`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/DensitySplit), because the feature is no longer supported. Replacement is to use [App Bundles](https://developer.android.com/guide/app-bundle).
|
||||
- [`DensitySplit`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/dsl/DensitySplit), because the feature is no longer supported.
|
||||
Replacement is to use [App Bundles](https://developer.android.com/guide/app-bundle).
|
||||
|
||||
## Removed APIs
|
||||
|
||||
Android Gradle plugin 9.0 removes:
|
||||
|
||||
- [`AndroidComponentsExtension.finalizeDSl`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/AndroidComponentsExtension#finalizeDSl(org.gradle.api.Action)). It is replaced by [`finalizeDsl`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/DslLifecycle#finalizeDsl(kotlin.Function1))
|
||||
- [`AndroidComponentsExtension.finalizeDSl`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/AndroidComponentsExtension#finalizeDSl(org.gradle.api.Action)). It is replaced by
|
||||
[`finalizeDsl`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/DslLifecycle#finalizeDsl(kotlin.Function1))
|
||||
|
||||
- [`Component.transformClassesWith`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Component#transformClassesWith(java.lang.Class,com.android.build.api.instrumentation.InstrumentationScope,kotlin.Function1)). It is replaced by [`Instrumentation.transformClassesWith`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/Instrumentation#transformClassesWith(java.lang.Class,com.android.build.api.instrumentation.InstrumentationScope,kotlin.Function1))
|
||||
- [`Component.transformClassesWith`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Component#transformClassesWith(java.lang.Class,com.android.build.api.instrumentation.InstrumentationScope,kotlin.Function1)). It is replaced by
|
||||
[`Instrumentation.transformClassesWith`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/Instrumentation#transformClassesWith(java.lang.Class,com.android.build.api.instrumentation.InstrumentationScope,kotlin.Function1))
|
||||
|
||||
- [`Component.setAsmFramesComputationMode`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Component#setAsmFramesComputationMode(com.android.build.api.instrumentation.FramesComputationMode)). It is replaced by [`Instrumentation.setAsmFramesComputationMode`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Instrumentation#setAsmFramesComputationMode(com.android.build.api.instrumentation.FramesComputationMode))
|
||||
- [`Component.setAsmFramesComputationMode`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Component#setAsmFramesComputationMode(com.android.build.api.instrumentation.FramesComputationMode)). It is replaced by
|
||||
[`Instrumentation.setAsmFramesComputationMode`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Instrumentation#setAsmFramesComputationMode(com.android.build.api.instrumentation.FramesComputationMode))
|
||||
|
||||
- [`ComponentBuilder.enabled`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/ComponentBuilder#enabled()). It is replaced by [`ComponentBuilder.enable`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/ComponentBuilder#enable()).
|
||||
- [`ComponentBuilder.enabled`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/ComponentBuilder#enabled()). It is replaced by
|
||||
[`ComponentBuilder.enable`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/ComponentBuilder#enable()).
|
||||
|
||||
- [`DependenciesInfoBuilder.includedInApk`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/DependenciesInfoBuilder#includedInApk()). Is is replaced by [`includeInApk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/DependenciesInfoBuilder#includeInApk())
|
||||
- [`DependenciesInfoBuilder.includedInApk`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/DependenciesInfoBuilder#includedInApk()). Is is replaced by
|
||||
[`includeInApk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/DependenciesInfoBuilder#includeInApk())
|
||||
|
||||
- [`DependenciesInfoBuilder.includedInBundle`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/DependenciesInfoBuilder#includedInBundle()). Is is replaced by [`includeInBundle`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/DependenciesInfoBuilder#includeInBundle())
|
||||
- [`DependenciesInfoBuilder.includedInBundle`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/DependenciesInfoBuilder#includedInBundle()). Is is replaced by
|
||||
[`includeInBundle`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/DependenciesInfoBuilder#includeInBundle())
|
||||
|
||||
- [`GeneratesApk.targetSdkVersion`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/GeneratesApk#targetSdkVersion()). Is is replaced by [`targetSdk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/GeneratesApk#targetSdk())
|
||||
|
||||
@@ -261,25 +357,43 @@ Android Gradle plugin 9.0 removes:
|
||||
|
||||
- [`Variant.targetSdkVersion`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Variant#targetSdkVersion()). Is is replaced by [`targetSdk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/Variant#targetSdk())
|
||||
|
||||
- [`Variant.unitTest`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Variant#unitTest()), as it was not applicable to the [`com.android.test`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/gradle/TestPlugin) plugin. `unitTest` is available on [`VariantBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantBuilder) subtypes extending [`HasUnitTest`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTest).
|
||||
- [`Variant.unitTest`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/Variant#unitTest()), as it was not applicable to the
|
||||
[`com.android.test`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/gradle/TestPlugin) plugin.
|
||||
`unitTest` is available on [`VariantBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantBuilder) subtypes extending
|
||||
[`HasUnitTest`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTest).
|
||||
|
||||
- [`VariantBuilder.targetSdk`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#targetSdk()) and [`targetSdkPreview`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#targetSdkPreview()), as they were not meaningful in libraries. Use [`GeneratesApkBuilder.targetSdk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/GeneratesApkBuilder#targetSdk()) or [`GeneratesApkBuilder.targetSdkPreview`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/GeneratesApkBuilder#targetSdkPreview()) instead.
|
||||
- [`VariantBuilder.targetSdk`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#targetSdk()) and [`targetSdkPreview`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#targetSdkPreview()),
|
||||
as they were not meaningful in libraries. Use
|
||||
[`GeneratesApkBuilder.targetSdk`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/GeneratesApkBuilder#targetSdk()) or
|
||||
[`GeneratesApkBuilder.targetSdkPreview`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/GeneratesApkBuilder#targetSdkPreview())
|
||||
instead.
|
||||
|
||||
- [`VariantBuilder.enableUnitTest`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#enableUnitTest()), as it was not applicable to the [`com.android.test`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/gradle/TestPlugin) plugin. `enableUnitTest` is available on [`VariantBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantBuilder) subtypes extending [`HasUnitTestBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTestBuilder).
|
||||
- [`VariantBuilder.enableUnitTest`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#enableUnitTest()), as it was not applicable to the
|
||||
[`com.android.test`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/gradle/TestPlugin) plugin.
|
||||
`enableUnitTest` is available on [`VariantBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantBuilder) subtypes extending
|
||||
[`HasUnitTestBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTestBuilder).
|
||||
|
||||
- [`VariantBuilder.unitTestEnabled`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#unitTestEnabled()) is removed in favor of the more consistently named [`enableUnitTest`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTestBuilder#enableUnitTest()) on the [`VariantBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantBuilder) subtypes extending [`HasUnitTestBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTestBuilder).
|
||||
- [`VariantBuilder.unitTestEnabled`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantBuilder#unitTestEnabled()) is removed in favor of the more
|
||||
consistently
|
||||
named [`enableUnitTest`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTestBuilder#enableUnitTest()) on the [`VariantBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantBuilder) subtypes
|
||||
extending [`HasUnitTestBuilder`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/HasUnitTestBuilder).
|
||||
|
||||
- [`VariantOutput.enable`](https://developer.android.com/reference/tools/gradle-api/8.13/com/android/build/api/variant/VariantOutput#enable()). Is is replaced by [`enabled`](https://developer.android.com/reference/tools/gradle-api/9.0/com/android/build/api/variant/VariantOutput#enabled())
|
||||
|
||||
- The deprecated and disabled `FeaturePlugin` and `FeatureExtension`.
|
||||
|
||||
- The deprecated and disabled `BaseExtension.registerTransform` APIs, which only remained to allow compiling against the latest AGP version while targeting running on AGP 4.2 or lower.
|
||||
- The deprecated and disabled `BaseExtension.registerTransform` APIs, which
|
||||
only remained to allow compiling against the latest AGP version while
|
||||
targeting running on AGP 4.2 or lower.
|
||||
|
||||
## Removed Gradle properties
|
||||
|
||||
The following Gradle properties were initially added as ways to globally disable features that were enabled by default.
|
||||
The following Gradle properties were initially added as ways to globally
|
||||
disable features that were enabled by default.
|
||||
|
||||
These features have been disabled by default since AGP 8.0 or lower. Enable these features in only the sub-projects that use them for a more efficient build.
|
||||
These features have been disabled by default since AGP 8.0 or lower. Enable
|
||||
these features in only the sub-projects that use them for a more efficient
|
||||
build.
|
||||
|
||||
| Property | Function | Replacement |
|
||||
|---|---|---|
|
||||
@@ -290,7 +404,8 @@ These features have been disabled by default since AGP 8.0 or lower. Enable thes
|
||||
|
||||
AGP 9.0 throws an error if you set the following Gradle properties.
|
||||
|
||||
The [Android Gradle plugin Upgrade Assistant](https://developer.android.com/build/agp-upgrade-assistant) won't upgrade projects to AGP 9.0 that use these properties.
|
||||
The [Android Gradle plugin Upgrade Assistant](https://developer.android.com/build/agp-upgrade-assistant) won't upgrade projects to
|
||||
AGP 9.0 that use these properties.
|
||||
|
||||
| Property | Function |
|
||||
|---|---|
|
||||
@@ -303,7 +418,11 @@ The following R8 changes are included in AGP 9.0.0.
|
||||
|
||||
### New configuration option `-processkotlinnullchecks`
|
||||
|
||||
We've added the new R8 option `-processkotlinnullchecks` to configure R8 for processing Kotlin null checks. The option takes a mandatory argument that must be one of the following three values: `keep`, `remove_message` and `remove`. The option processes the following null checks added by the Kotlin compiler:
|
||||
We've added the new R8 option `-processkotlinnullchecks` to configure R8 for
|
||||
processing Kotlin null checks. The option takes a mandatory argument that must
|
||||
be one of the following three values: `keep`, `remove_message` and `remove`.
|
||||
The option processes the following null checks added by the Kotlin
|
||||
compiler:
|
||||
|
||||
class kotlin.jvm.internal.Intrinsics {
|
||||
void checkNotNull(java.lang.Object);
|
||||
@@ -323,68 +442,108 @@ We've added the new R8 option `-processkotlinnullchecks` to configure R8 for pro
|
||||
void checkNotNullParameter(java.lang.Object, java.lang.String);
|
||||
}
|
||||
|
||||
The option values, ordered from the weakest to the strongest, have the following effect:
|
||||
The option values, ordered from the weakest to the strongest, have the
|
||||
following effect:
|
||||
|
||||
- `keep` doesn't change the checks.
|
||||
- `remove_message` rewrites each check method call to a call to `getClass()` on the first argument of the call (effectively keeping the null check, but without any message).
|
||||
- `remove` completely removes the checks.
|
||||
|
||||
By default R8 uses `remove_message`. Any specification of `-processkotlinnullchecks` will override that. If specified multiple times the strongest value is used.
|
||||
By default R8
|
||||
uses `remove_message`. Any specification of `-processkotlinnullchecks`
|
||||
will override that. If specified multiple times the strongest value is
|
||||
used.
|
||||
|
||||
### Stop propagating keep info to companion methods
|
||||
|
||||
When keep rules match interface methods that are subject to desugaring, R8 previously internally transferred the *disallow optimization* and *disallow shrinking* bits to the synthesized companion methods.
|
||||
When keep rules match interface methods that are subject to desugaring,
|
||||
R8 previously internally transferred the *disallow optimization* and *disallow
|
||||
shrinking* bits to the synthesized companion methods.
|
||||
|
||||
Starting with AGP 9.0, keep rules no longer apply to companion methods. This is consistent with the fact that keep rules are not applicable to other compiler synthesized fields/methods/classes.
|
||||
Starting with AGP 9.0, keep rules no longer apply to
|
||||
companion methods. This is consistent with the fact that keep rules are
|
||||
not applicable to other compiler synthesized fields/methods/classes.
|
||||
|
||||
By transferring the *disallow optimization* and *disallow shrinking* bits to the companion methods, the following use case was previously supported:
|
||||
By transferring the *disallow optimization* and *disallow shrinking* bits to
|
||||
the companion methods, the following use case was previously supported:
|
||||
|
||||
1. Compile a library with `default`/`static`/`private` interface methods to DEX with `minSdk` \< 24 and rules that keep the interface methods.
|
||||
2. Compile an app with the library on classpath and `-applymapping`.
|
||||
3. Merge the app and the library.
|
||||
|
||||
Note that this only works with `-applymapping` since the `disallow obfuscation` bit is not transferred to the companion methods---that is, the companion classes generated from step 1 would have obfuscated method names.
|
||||
Note that this only works with `-applymapping` since the `disallow
|
||||
obfuscation` bit is not transferred to the companion methods---that is, the
|
||||
companion classes generated from step 1 would have obfuscated method
|
||||
names.
|
||||
|
||||
Going forward this use case is no longer supported for `minSdk` \< 24. The workaround is to do the following:
|
||||
Going forward this use case is no longer supported for `minSdk` \<
|
||||
24. The workaround is to do the following:
|
||||
|
||||
1. Desugar the library with `default`/`static`/`private` interface methods to class files with `minSdk` \< 24.
|
||||
2. Compile the desugared artifact using R8 and rules that keep the interface methods on the companion classes.
|
||||
3. Compile the app with the library on classpath.
|
||||
4. Merge the app and the desugared artifact.
|
||||
|
||||
Another side effect of this is that it is no longer possible to keep the inner class and enclosing method attributes for anonymous and local classes inside interface companion methods.
|
||||
Another side effect of this is that it is no longer possible to keep the
|
||||
inner class and enclosing method attributes for anonymous and local classes
|
||||
inside interface companion methods.
|
||||
|
||||
### Change the default emitted source file to `r8-map-id-<MAP_ID>`
|
||||
|
||||
This change is in AGP starting from 8.12.0.
|
||||
|
||||
The default emitted source file attribute for a class changes from `SourceFile` to `r8-map-id-<MAP_ID>` when retracing is required (that is, when either obfuscation or optimization is enabled).
|
||||
The default emitted source file attribute for a class changes from
|
||||
`SourceFile` to `r8-map-id-<MAP_ID>` when retracing is required (that is,
|
||||
when either obfuscation or optimization is enabled).
|
||||
|
||||
Given an obfuscated stack trace, the new source file attribute makes it possible to extract the ID of the mapping file that is required for retracing, which can be used to support [automated retracing of stack traces in Logcat](https://developer.android.com/studio/preview/features#logcat-retrace).
|
||||
Given an obfuscated stack trace, the new source file attribute makes it
|
||||
possible to extract the ID of the mapping file that is required for
|
||||
retracing, which can be used to support
|
||||
[automated retracing of stack traces in Logcat](https://developer.android.com/studio/preview/features#logcat-retrace).
|
||||
|
||||
If a custom source file attribute is used (`-renamesourcefileattribute`) this custom source file attribute continues to take precedence.
|
||||
If a custom source file attribute is used (`-renamesourcefileattribute`)
|
||||
this custom source file attribute continues to take precedence.
|
||||
|
||||
In ProGuard compatibility mode (when `gradle.properties` contains `android.enableR8.fullMode=false`), emitting a source file attribute of `r8-map-id-<MAP_ID>` only takes effect if the `SourceFile` attribute is *not* kept. Apps that use ProGuard compatibility mode and want to include the mapping file ID in their stack traces should remove `-keepattributes SourceFile` (or migrate to R8 full mode).
|
||||
In ProGuard compatibility mode (when `gradle.properties` contains
|
||||
`android.enableR8.fullMode=false`), emitting a source file attribute of
|
||||
`r8-map-id-<MAP_ID>` only takes effect if the `SourceFile`
|
||||
attribute is *not* kept. Apps that use ProGuard compatibility mode and want
|
||||
to include the mapping file ID in their stack traces should remove
|
||||
`-keepattributes SourceFile` (or migrate to R8 full mode).
|
||||
|
||||
The map ID used in `r8-map-id-<MAP_ID>` is the full map hash, and not a 7 character prefix of the map hash which was previously used.
|
||||
The map ID used in `r8-map-id-<MAP_ID>` is the full map hash, and not a 7
|
||||
character prefix of the map hash which was previously used.
|
||||
|
||||
### Enable use of minimized synthetic names in L8 desugaring
|
||||
|
||||
The name of synthetic classes generated by D8 normally contains the substring `$$ExternalSynthetic` that tells you that this is a synthetic generated by D8. Moreover, the name of the synthetic also encodes the synthetic kind (for example, `Backport`, `Lambda`). This has a negative impact on the resulting DEX size, since the class names take up more space in the string pool.
|
||||
The name of synthetic classes generated by D8 normally contains the substring
|
||||
`$$ExternalSynthetic` that tells you that this is a synthetic generated by D8.
|
||||
Moreover, the name of the synthetic also encodes the synthetic kind (for
|
||||
example, `Backport`, `Lambda`). This has a negative impact on the resulting DEX
|
||||
size, since the class names take up more space in the string pool.
|
||||
|
||||
AGP 9.0 configures L8 (core library desugaring) so that the DEX file containing all `j$` classes uses a new shortened class name format for synthetic classes. The new class name uses a numeric ID (for example, `$1`).
|
||||
AGP 9.0 configures L8 (core library desugaring) so that the DEX
|
||||
file containing all `j$` classes uses a new shortened class name format
|
||||
for synthetic classes. The new class name uses a numeric ID (for example, `$1`).
|
||||
|
||||
### Remove support for `-addconfigurationdebugging`
|
||||
|
||||
AGP 9.0 removes support for `-addconfigurationdebugging`. The compiler now reports a warning if the flag is used.
|
||||
AGP 9.0 removes support for `-addconfigurationdebugging`. The compiler now
|
||||
reports a warning if the flag is used.
|
||||
|
||||
### Remove support for generating L8 rules from D8/R8
|
||||
|
||||
This change is only relevant for developers using the D8/R8 command line or APIs directly.
|
||||
This change is only relevant for developers using the D8/R8 command line or
|
||||
APIs directly.
|
||||
|
||||
R8 9.0 removes support for generating keep rules for L8 from D8 and R8. You should instead use `TraceReferences` for this purpose.
|
||||
R8 9.0 removes support for generating keep rules for L8 from D8 and R8.
|
||||
You should instead use `TraceReferences` for this purpose.
|
||||
|
||||
More specifically, the methods `D8Command.builder.setDesugaredLibraryKeepRuleConsumer` and `R8Command.Builder.setDesugaredLibraryKeepRuleConsumer` are removed, and the support for `--desugared-lib-pg-conf-output` is removed from the command line options of D8 and R8.
|
||||
More specifically, the methods
|
||||
`D8Command.builder.setDesugaredLibraryKeepRuleConsumer` and
|
||||
`R8Command.Builder.setDesugaredLibraryKeepRuleConsumer` are removed, and the
|
||||
support for `--desugared-lib-pg-conf-output` is removed from the command line
|
||||
options of D8 and R8.
|
||||
|
||||
## Fixed issues
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
When an Android module contains custom BuildConfig fields, the following steps are necessary to ensure a correct build.
|
||||
When an Android module contains custom BuildConfig fields, the following steps
|
||||
are necessary to ensure a correct build.
|
||||
|
||||
### Step 1: Enable the buildConfig build feature
|
||||
|
||||
@@ -36,9 +37,11 @@ In custom build-logic using `CommonExtension`:
|
||||
|
||||
### Step 2: Migrate to the new API
|
||||
|
||||
Use the **addCustomBuildConfigFields** recipe from the [gradle-recipes](https://developer.android.com/agents/skills/build-system/agp/agp-9-upgrade/references/recipes) repository.
|
||||
Use the **addCustomBuildConfigFields** recipe from the [gradle-recipes](https://developer.android.com/agents/skills/build-system/agp/agp-9-upgrade/references/recipes)
|
||||
repository.
|
||||
|
||||
**IMPORTANT:** For `BuildConfigField`s with a type of `String`, the `value` field *must* include quotation marks as part of the String. For example:
|
||||
**IMPORTANT:** For `BuildConfigField`s with a type of `String`, the `value` field
|
||||
*must* include quotation marks as part of the String. For example:
|
||||
|
||||
BuildConfigField(
|
||||
type = "String",
|
||||
@@ -46,4 +49,6 @@ Use the **addCustomBuildConfigFields** recipe from the [gradle-recipes](https://
|
||||
comment = "Optional comment",
|
||||
)
|
||||
|
||||
It is an **error** if the `value` field doesn't include quotation marks as part of the String. For example, `value = "Some value"` **is an error** . This is because the `value` is written out literally.
|
||||
It is an **error** if the `value` field doesn't include quotation marks as
|
||||
part of the String. For example, `value = "Some value"` **is an error** . This is
|
||||
because the `value` is written out literally.
|
||||
@@ -1,23 +1,39 @@
|
||||
When migrating to built-in Kotlin, it is important to consider usage of `kapt` and the `org.jetbrains.kotlin.kapt` (also known as the `kotlin("kapt")`) plugin. The goal is to migrate as many `kapt` usages to `ksp` as possible.
|
||||
When migrating to built-in Kotlin, it is important to consider usage of `kapt`
|
||||
and the `org.jetbrains.kotlin.kapt` (also known as the `kotlin("kapt")`) plugin.
|
||||
The goal is to migrate as many `kapt` usages to `ksp` as possible.
|
||||
|
||||
Follow these steps when migrating `kapt`:
|
||||
|
||||
## 1. Remove all references to the `org.jetbrains.kotlin.kapt` plugin
|
||||
|
||||
The `org.jetbrains.kotlin.kapt` (also known as `kotlin("kapt")`) plugin is incompatible with built-in Kotlin. Remove it when migrating to built-in Kotlin.
|
||||
The `org.jetbrains.kotlin.kapt` (also known as `kotlin("kapt")`) plugin is
|
||||
incompatible with built-in Kotlin. Remove it when migrating to built-in Kotlin.
|
||||
|
||||
## 2. Check each usage of `kapt`
|
||||
|
||||
Check each usage of `kapt` to see if it is compatible with `ksp`. To check if a dependency is compatible with `ksp`, inspect the dependency's jar. For it to be compatible with `ksp`, the jar must have a file, `services/com.google.devtools.ksp.processing.SymbolProcessorProvider`. If it does not, it is **incompatible** with `ksp`.
|
||||
Check each usage of `kapt` to see if it is compatible with `ksp`. To check if a
|
||||
dependency is compatible with `ksp`, inspect the dependency's jar. For it to be
|
||||
compatible with `ksp`, the jar must have a file,
|
||||
`services/com.google.devtools.ksp.processing.SymbolProcessorProvider`. If it
|
||||
does not, it is **incompatible** with `ksp`.
|
||||
|
||||
For example, the `androidx.room:room-compiler` library is compatible with KSP since version 2.3.0-beta02. We can verify this by finding the jar file in the Gradle caches directory, which is typically located at `~/.gradle/caches/modules-2/files-2.1/` on Linux and Mac. In this specific case, the `androidx.room:room-compiler` dependency is located at `~/.gradle/caches/modules-2/files-2.1/androidx.room/room-compiler/`.
|
||||
For example, the `androidx.room:room-compiler` library is compatible with KSP
|
||||
since version 2.3.0-beta02. We can verify this by finding the jar file in the
|
||||
Gradle caches directory, which is typically located at
|
||||
`~/.gradle/caches/modules-2/files-2.1/` on Linux and Mac. In this specific case,
|
||||
the `androidx.room:room-compiler` dependency is located at
|
||||
`~/.gradle/caches/modules-2/files-2.1/androidx.room/room-compiler/`.
|
||||
|
||||
More generally, you can find a dependency by looking in `~/.gradle/caches/modules-2/files-2.1/group-name/artifact-name/`.
|
||||
More generally, you can find a dependency by looking in
|
||||
`~/.gradle/caches/modules-2/files-2.1/group-name/artifact-name/`.
|
||||
|
||||
## 3. Migrate to KSP where possible
|
||||
|
||||
For each usage of `kapt` that is compatible with `ksp`, use `ksp`. The prior step explains how to check compatibility.
|
||||
For each usage of `kapt` that is compatible with `ksp`, use `ksp`. The prior
|
||||
step explains how to check compatibility.
|
||||
|
||||
## 4. Apply legacy-kapt
|
||||
|
||||
If a Gradle module has `kapt` dependencies that cannot be migrated to `ksp` because they are incompatible (see step 2), then leave that dependency alone and apply the `com.android.legacy-kapt` plugin.
|
||||
If a Gradle module has `kapt` dependencies that cannot be migrated to `ksp`
|
||||
because they are incompatible (see step 2), then leave that dependency alone and
|
||||
apply the `com.android.legacy-kapt` plugin.
|
||||
@@ -1,10 +1,19 @@
|
||||
If Paparazzi is used in the project, update it to version 2.0.0-alpha04 or higher.
|
||||
If Paparazzi is used in the project, update it to version 2.0.0-alpha04 or
|
||||
higher.
|
||||
|
||||
Paparazzi version 2.0.0-alpha04 and lower is not fully compatible with Gradle 9, and Gradle 9 is required by AGP 9. This means that, without workarounds, projects that use Paparazzi v2.0.0-alpha04 and lower cannot migrate to AGP 9.
|
||||
Paparazzi version 2.0.0-alpha04 and lower is not fully compatible with Gradle
|
||||
9, and Gradle 9 is required by AGP 9. This means that, without workarounds,
|
||||
projects that use Paparazzi v2.0.0-alpha04 and lower cannot migrate to AGP 9.
|
||||
|
||||
At time of writing, there are no higher versions of Paparazzi. That is, v2.0.0-alpha04 is the latest release.
|
||||
At time of writing, there are no higher versions of Paparazzi. That is,
|
||||
v2.0.0-alpha04 is the latest release.
|
||||
|
||||
The issue is due to Paparazzi using internal classes from Gradle that tend to move in breaking ways without warning. This specific issue is related to HTML test reports. To work around it, disable those HTML test reports. Here are two examples of how to do this, one for Kotlin DSL and the other for Groovy DSL. Any module that has the paparazzi plugin (`app.cash.paparazzi`) applied must apply one of these two workarounds.
|
||||
The issue is due to Paparazzi using internal classes from Gradle that tend to
|
||||
move in breaking ways without warning. This specific issue is related to HTML
|
||||
test reports. To work around it, disable those HTML test reports. Here
|
||||
are two examples of how to do this, one for Kotlin DSL and the other for Groovy
|
||||
DSL. Any module that has the paparazzi plugin (`app.cash.paparazzi`) applied
|
||||
must apply one of these two workarounds.
|
||||
|
||||
Kotlin DSL:
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
When migrating to AGP's new DSL, any Gradle code (plugins or logic in build scripts) that relied on the old DSL will stop working. Such code must be migrated.
|
||||
When migrating to AGP's new DSL, any Gradle code (plugins or logic in build
|
||||
scripts) that relied on the old DSL will stop working. Such code must be
|
||||
migrated.
|
||||
|
||||
## Guidelines
|
||||
|
||||
@@ -6,9 +8,14 @@ When migrating to AGP's new DSL, any Gradle code (plugins or logic in build scri
|
||||
- **DO NOT** use AGP internals in migrated code.
|
||||
- **DO** use only public APIs in migrated code.
|
||||
|
||||
In some cases, there is a one-to-one replacement for the old code. Some examples are in [the AGP 9.0.0 release notes](https://developer.android.com/build/releases/agp-9-0-0-release-notes).
|
||||
In some cases, there is a one-to-one replacement for the old code. Some examples
|
||||
are in [the AGP 9.0.0 release notes](https://developer.android.com/build/releases/agp-9-0-0-release-notes).
|
||||
|
||||
In other cases, there is no direct one-to-one replacement. For these situations, the [gradle-recipes repo](https://github.com/android/gradle-recipes) is a great resource. You can checkout one of its AGP 9.x branches, such as `agp-9.0`, `agp-9.1`, or `agp-9.2`. These branches contain recipes for common situations in Android projects. The following table lists the compatibility for recipes for each version of AGP.
|
||||
In other cases, there is no direct one-to-one replacement. For these situations,
|
||||
the [gradle-recipes repo](https://github.com/android/gradle-recipes) is a great resource. You can checkout one of its
|
||||
AGP 9.x branches, such as `agp-9.0`, `agp-9.1`, or `agp-9.2`. These branches
|
||||
contain recipes for common situations in Android projects. The following table
|
||||
lists the compatibility for recipes for each version of AGP.
|
||||
|
||||
## Compatibility table
|
||||
|
||||
@@ -49,4 +56,7 @@ In the old DSL, an APK could be renamed very simply. Here's an example:
|
||||
}
|
||||
}
|
||||
|
||||
However, with AGP 9 and the new DSL, `applicationVariants` is no longer available. You must instead react to artifact creation using the `androidComponents.onVariants` API. A complete example of this is available in the **gradle-recipes** repository in the `listenToArtifacts` recipe.
|
||||
However, with AGP 9 and the new DSL, `applicationVariants` is no longer
|
||||
available. You must instead react to artifact creation using the
|
||||
`androidComponents.onVariants` API. A complete example of this is available in
|
||||
the **gradle-recipes** repository in the `listenToArtifacts` recipe.
|
||||
+17
-9
@@ -7,7 +7,7 @@ description: Provide technical guidance for Android camera development with Came
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-14'
|
||||
keywords:
|
||||
- recipe
|
||||
- Android
|
||||
@@ -26,17 +26,20 @@ metadata:
|
||||
- ImageAnalysis.
|
||||
---
|
||||
|
||||
This skill provides procedural guidance and standard patterns for building camera applications on Android, with a focus on CameraX, including its `Camera2Interop` utilities, and Media3 integrations.
|
||||
This skill provides procedural guidance and standard patterns for building
|
||||
camera applications on Android, with a focus on CameraX, including its
|
||||
`Camera2Interop` utilities, and Media3 integrations.
|
||||
|
||||
## Core workflows
|
||||
|
||||
### Handling immutable API patterns
|
||||
|
||||
Various Android camera and media APIs, especially CameraX `VideoCapture`, use a **fluent, immutable builder-like pattern** where methods return a new instance. Failing to reassign these results in settings, such as audio, being ignored.
|
||||
Various Android camera and media APIs, especially CameraX `VideoCapture`, use a
|
||||
**fluent, immutable builder-like pattern** where methods return a new instance.
|
||||
Failing to reassign these results in settings, such as audio, being ignored.
|
||||
|
||||
**Pattern: Reassignment is required**
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// WRONG
|
||||
@@ -59,7 +62,6 @@ run {
|
||||
pending = pending.withAudioEnabled() // Reassignment
|
||||
val active = pending.start(exec, listener)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -75,7 +77,9 @@ When migrating legacy camera codebases to the CameraX Jetpack library:
|
||||
|
||||
### Comprehensive feature blueprinting
|
||||
|
||||
For multi-step features that involve multiple files and hardware-level wiring, follow the [Structural Blueprinting](references/expert-blueprints.md) approach to avoid system timeouts. Such complex features include:
|
||||
For multi-step features that involve multiple files and hardware-level wiring,
|
||||
follow the [Structural Blueprinting](references/expert-blueprints.md) approach to avoid
|
||||
system timeouts. Such complex features include:
|
||||
|
||||
- **Manual controls** : Break down into the `ViewModel` state, the controller layer, and the `Camera2Interop` wiring in the session.
|
||||
- **RAW capture**: Separate JPEG and RAW output configurations into discrete build steps.
|
||||
@@ -102,16 +106,20 @@ See [modern-apis](references/modern-apis.md) for current recommendations.
|
||||
|
||||
### Code quality and architectural rules
|
||||
|
||||
Adhere to the following Android ecosystem standard patterns when building your camera implementations:
|
||||
Adhere to the following Android ecosystem standard patterns when building your
|
||||
camera implementations:
|
||||
|
||||
- **Testing, fakes over mocks** : Avoid mocking libraries like `Mockito`, especially for multi-step CameraX interfaces like `ImageProxy`. Build "Fakes" to verify state rather than unreliable implementation details.
|
||||
- **Google Truth assertions** : Use `assertThat` over standard `JUnit` assertions like `assertEquals` for improved readability.
|
||||
- **Explicit test runners** : Always define an explicit `@RunWith` for test classes to ensure the CI environment executes them correctly.
|
||||
- **Semantic UI merging** : When building custom camera controls in Compose, such as a button with an `Icon` and `Text`, use `semantics { mergeDescendants = true }` to ensure screen readers announce them as a single, coherent unit.
|
||||
- **Semantic UI merging** : When building custom camera controls in Compose, such as a button with an `Icon` and `Text`, use `semantics {
|
||||
mergeDescendants = true }` to ensure screen readers announce them as a single, coherent unit.
|
||||
|
||||
## Hardware and device diversity
|
||||
|
||||
Camera apps run on a wide variety of hardware, from mobile phones and foldables to tablets, laptops, and even smart appliances. Have consideration for the specific hardware the app is running on.
|
||||
Camera apps run on a wide variety of hardware, from mobile phones and
|
||||
foldables to tablets, laptops, and even smart appliances. Have consideration
|
||||
for the specific hardware the app is running on.
|
||||
|
||||
- **Form factors**: Account for screen size and orientation changes on foldables and tablets.
|
||||
- **Multi-camera arrays**: Some devices have a rear-facing camera and a front-facing camera. Other devices have multiple rear-facing cameras, such as wide-angle and telephoto lenses.
|
||||
|
||||
@@ -7,9 +7,9 @@
|
||||
|
||||
## Initialize `ProcessCameraProvider`
|
||||
|
||||
Request the `ProcessCameraProvider` and bind use cases to the Activity or Fragment lifecycle.
|
||||
Request the `ProcessCameraProvider` and bind use cases to the Activity or
|
||||
Fragment lifecycle.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val context = LocalContext.current
|
||||
@@ -36,7 +36,6 @@ LaunchedEffect(context, lifecycleOwner) {
|
||||
)
|
||||
val cameraControl = camera.cameraControl
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -51,25 +50,21 @@ Use `androidx.camera.view.PreviewView`.
|
||||
|
||||
1. **Set up preview**:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
preview.setSurfaceProvider(previewView.surfaceProvider)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
2. **Handle tap-to-focus**:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val factory = previewView.meteringPointFactory
|
||||
val point = factory.createPoint(x, y) // x, y from touch event
|
||||
val action = FocusMeteringAction.Builder(point, FocusMeteringAction.FLAG_AF).build()
|
||||
cameraControl?.startFocusAndMetering(action)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -80,7 +75,6 @@ Use `androidx.camera.compose.CameraXViewfinder`.
|
||||
|
||||
1. **Set up preview and SurfaceRequest**:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
var surfaceRequest by remember { mutableStateOf<SurfaceRequest?>(null) }
|
||||
@@ -89,14 +83,12 @@ Use `androidx.camera.compose.CameraXViewfinder`.
|
||||
setSurfaceProvider { request -> surfaceRequest = request }
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
2. **Render viewfinder**:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
surfaceRequest?.let { request ->
|
||||
@@ -106,14 +98,12 @@ Use `androidx.camera.compose.CameraXViewfinder`.
|
||||
modifier = Modifier
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
3. **Handle tap-to-focus in Compose**:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Inside your tap gesture handler...
|
||||
@@ -125,14 +115,12 @@ Use `androidx.camera.compose.CameraXViewfinder`.
|
||||
val point = factory.createPoint(surfaceCoords.x, surfaceCoords.y)
|
||||
val action = FocusMeteringAction.Builder(point, FocusMeteringAction.FLAG_AF).build()
|
||||
cameraControl?.startFocusAndMetering(action)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
4. **Update target rotation for Compose**:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
LaunchedEffect(configuration) {
|
||||
@@ -142,16 +130,15 @@ Use `androidx.camera.compose.CameraXViewfinder`.
|
||||
preview.targetRotation = rotation
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Capture a photo
|
||||
|
||||
Use the `ImageCapture` use case to take the picture. The `ImageProxy` handles rotation directly.
|
||||
Use the `ImageCapture` use case to take the picture. The `ImageProxy` handles
|
||||
rotation directly.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
imageCapture.takePicture(
|
||||
@@ -183,16 +170,15 @@ imageCapture.takePicture(
|
||||
}
|
||||
}
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Switch cameras
|
||||
|
||||
To flip between front and rear cameras, change the `CameraSelector` and retrigger the `ProcessCameraProvider` logic.
|
||||
To flip between front and rear cameras, change the `CameraSelector` and
|
||||
retrigger the `ProcessCameraProvider` logic.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
lensFacing = if (lensFacing == CameraSelector.LENS_FACING_BACK) {
|
||||
@@ -200,7 +186,6 @@ lensFacing = if (lensFacing == CameraSelector.LENS_FACING_BACK) {
|
||||
} else {
|
||||
CameraSelector.LENS_FACING_BACK
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
Camera2 offers granular control but introduces boilerplate: managing `CameraDevice` states, `CameraCaptureSession` lifecycles, background threads, `HandlerThread`, and manual orientation calculations.
|
||||
Camera2 offers granular control but introduces boilerplate: managing
|
||||
`CameraDevice` states, `CameraCaptureSession` lifecycles, background threads,
|
||||
`HandlerThread`, and manual orientation calculations.
|
||||
|
||||
CameraX simplifies this by binding high-level `UseCase`s such as `Preview`, `ImageCapture`, and `ImageAnalysis` directly to Android lifecycles, handling thread management and device-specific workarounds automatically.
|
||||
CameraX simplifies this by binding high-level `UseCase`s such as `Preview`,
|
||||
`ImageCapture`, and `ImageAnalysis` directly to Android lifecycles, handling
|
||||
thread management and device-specific workarounds automatically.
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
@@ -17,9 +21,10 @@ Migrating to CameraX removes manual setup code:
|
||||
|
||||
## Initialize `ProcessCameraProvider`
|
||||
|
||||
Request the `ProcessCameraProvider` and bind your use cases to the `LifecycleOwner` activity or fragment. This replaces the `CameraManager.openCamera` flow.
|
||||
Request the `ProcessCameraProvider` and bind your use cases to the
|
||||
`LifecycleOwner` activity or fragment. This replaces the
|
||||
`CameraManager.openCamera` flow.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val context = LocalContext.current
|
||||
@@ -51,7 +56,6 @@ LaunchedEffect(context, lifecycleOwner) {
|
||||
imageAnalysis
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -60,17 +64,17 @@ LaunchedEffect(context, lifecycleOwner) {
|
||||
|
||||
## Implement the preview and tap-to-focus
|
||||
|
||||
CameraX handles surface configuration automatically. Choose based on your UI toolkit:
|
||||
CameraX handles surface configuration automatically. Choose based on your UI
|
||||
toolkit:
|
||||
|
||||
### Option A: For Android Views
|
||||
|
||||
Use `androidx.camera.view.PreviewView` in your layout, and bind it to the `Preview` use case.
|
||||
Use `androidx.camera.view.PreviewView` in your layout, and bind it to the
|
||||
`Preview` use case.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
preview.setSurfaceProvider(previewView.surfaceProvider)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -79,7 +83,6 @@ preview.setSurfaceProvider(previewView.surfaceProvider)
|
||||
|
||||
Use `androidx.camera.compose.CameraXViewfinder`.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
var surfaceRequest by remember { mutableStateOf<SurfaceRequest?>(null) }
|
||||
@@ -88,7 +91,6 @@ val preview = remember {
|
||||
setSurfaceProvider { request -> surfaceRequest = request }
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -97,9 +99,10 @@ val preview = remember {
|
||||
|
||||
## Capture a photo
|
||||
|
||||
Replace `ImageReader` capture flows and `CaptureRequest.Builder.TEMPLATE_STILL_CAPTURE` with the `ImageCapture` use case. CameraX handles the rotation natively using the returned `ImageProxy`.
|
||||
Replace `ImageReader` capture flows and
|
||||
`CaptureRequest.Builder.TEMPLATE_STILL_CAPTURE` with the `ImageCapture` use
|
||||
case. CameraX handles the rotation natively using the returned `ImageProxy`.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
imageCapture.takePicture(
|
||||
@@ -131,7 +134,6 @@ imageCapture.takePicture(
|
||||
}
|
||||
}
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -140,9 +142,9 @@ imageCapture.takePicture(
|
||||
|
||||
## Implement image analysis
|
||||
|
||||
If you were using `ImageReader` in Camera2 to access raw frames, e.g., for QR scanning or ML,, replace it with the CameraX `ImageAnalysis` use case.
|
||||
If you were using `ImageReader` in Camera2 to access raw frames, e.g., for QR
|
||||
scanning or ML,, replace it with the CameraX `ImageAnalysis` use case.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
imageAnalysis.setAnalyzer(cameraExecutor) { imageProxy ->
|
||||
@@ -155,7 +157,6 @@ imageAnalysis.setAnalyzer(cameraExecutor) { imageProxy ->
|
||||
imageProxy.close()
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -164,9 +165,10 @@ imageAnalysis.setAnalyzer(cameraExecutor) { imageProxy ->
|
||||
|
||||
## Use Camera2 interop
|
||||
|
||||
If your app requires specific Camera2 configuration options, such as custom exposure modes or flash settings, that aren't exposed directly in CameraX, use `Camera2Interop` to apply them to your CameraX use cases.
|
||||
If your app requires specific Camera2 configuration options, such as custom
|
||||
exposure modes or flash settings, that aren't exposed directly in CameraX,
|
||||
use `Camera2Interop` to apply them to your CameraX use cases.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Use Camera2Interop to set Camera2-specific capture options
|
||||
@@ -178,7 +180,6 @@ extender.setCaptureRequestOption(
|
||||
CaptureRequest.FLASH_MODE,
|
||||
CaptureRequest.FLASH_MODE_TORCH
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
Complex camera features often fail due to "Agent Stall" or timeouts when attempted in a single turn. Use these blueprints to break tasks into manageable phases.
|
||||
Complex camera features often fail due to "Agent Stall" or timeouts when
|
||||
attempted in a single turn. Use these blueprints to break tasks into manageable
|
||||
phases.
|
||||
|
||||
## Manual controls
|
||||
|
||||
@@ -52,4 +54,5 @@ Complex camera features often fail due to "Agent Stall" or timeouts when attempt
|
||||
|
||||
## Low-light capture
|
||||
|
||||
For guidance on Night Mode Extensions and Low Light Boost, [low-light.md](https://developer.android.com/agents/skills/camera/camerax/references/low-light).
|
||||
For guidance on Night Mode Extensions and Low Light Boost,
|
||||
[low-light.md](https://developer.android.com/agents/skills/camera/camerax/references/low-light).
|
||||
@@ -1,4 +1,6 @@
|
||||
Foldable devices introduce unique challenges for camera applications, including dynamic layout changes, multiple display orientations, and physical device postures, such as tabletop and book modes.
|
||||
Foldable devices introduce unique challenges for camera applications, including
|
||||
dynamic layout changes, multiple display orientations, and physical device
|
||||
postures, such as tabletop and book modes.
|
||||
|
||||
## Manage fold states and postures
|
||||
|
||||
@@ -14,9 +16,9 @@ Foldable devices introduce unique challenges for camera applications, including
|
||||
|
||||
### Detect posture changes
|
||||
|
||||
Use the Jetpack WindowManager library to observe the device's hinge state and fold layout.
|
||||
Use the Jetpack WindowManager library to observe the device's hinge state and
|
||||
fold layout.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
lifecycleScope.launch {
|
||||
@@ -31,14 +33,15 @@ lifecycleScope.launch {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Handle tabletop mode
|
||||
|
||||
In Tabletop mode, horizontal fold, you should move the viewfinder to the top half of the screen and the controls to the bottom half to prevent the user from seeing a "bent" image.
|
||||
In Tabletop mode, horizontal fold, you should move the viewfinder to the top
|
||||
half of the screen and the controls to the bottom half to prevent the user from
|
||||
seeing a "bent" image.
|
||||
|
||||
- **Identify orientation:** Check `FoldingFeature.orientation`.
|
||||
- **Calculate geometry:** Use `FoldingFeature.bounds` to identify the hinge's physical location on the screen.
|
||||
@@ -46,9 +49,9 @@ In Tabletop mode, horizontal fold, you should move the viewfinder to the top hal
|
||||
|
||||
### Coordinate mapping and `Viewport`
|
||||
|
||||
When the UI layout changes due to a fold, you **must** update the `Viewport` to ensure that tap-to-focus and image capture coordinates remain accurate.
|
||||
When the UI layout changes due to a fold, you **must** update the `Viewport` to
|
||||
ensure that tap-to-focus and image capture coordinates remain accurate.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val viewport = ViewPort.Builder(Rational(viewfinder.width, viewfinder.height), display.rotation)
|
||||
@@ -59,14 +62,14 @@ val useCaseGroup = UseCaseGroup.Builder()
|
||||
.addUseCase(preview)
|
||||
.setViewPort(viewport)
|
||||
.build()
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Rear display mode
|
||||
|
||||
Some foldables allow using the rear camera with the cover display while the device is unfolded.
|
||||
Some foldables allow using the rear camera with the cover display while the
|
||||
device is unfolded.
|
||||
|
||||
- **Verification:** If available through OEM SDKs or Android 14 (API level 34) or higher, check `DeviceState.REAR_DISPLAY_STATE`.
|
||||
- **Logic:** Handle preview detachment and reattachment on different display surfaces with varying aspect ratios.
|
||||
|
||||
@@ -1,8 +1,11 @@
|
||||
Many Android APIs are designed with immutability in mind to prevent race conditions in async environments. However, this often trips up developers used to mutable builder patterns.
|
||||
Many Android APIs are designed with immutability in mind to prevent race
|
||||
conditions in async environments. However, this often trips up developers used
|
||||
to mutable builder patterns.
|
||||
|
||||
## Common immutable classes
|
||||
|
||||
The following classes use fluent APIs that **return a new instance**. You must reassign the variable.
|
||||
The following classes use fluent APIs that **return a new instance**. You must
|
||||
reassign the variable.
|
||||
|
||||
| Class | Methods that return a new instance | Result if not reassigned |
|
||||
|---|---|---|
|
||||
@@ -17,7 +20,6 @@ The following classes use fluent APIs that **return a new instance**. You must r
|
||||
|
||||
To set up video recording, use the following code:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// WRONG
|
||||
@@ -40,7 +42,6 @@ run {
|
||||
pending = pending.withAudioEnabled() // Reassignment
|
||||
val active = pending.start(exec, listener)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -49,13 +50,11 @@ run {
|
||||
|
||||
To set up the viewport, use the following code:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val viewport = ViewPort.Builder(Rational(width, height), displayRotation)
|
||||
.setScaleType(ViewPort.FILL_CENTER)
|
||||
.build()
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -1,4 +1,5 @@
|
||||
This guide covers implementing low-light features using **Night mode extensions** and **Low Light Boost (LLB)**.
|
||||
This guide covers implementing low-light features using **Night mode
|
||||
extensions** and **Low Light Boost (LLB)**.
|
||||
|
||||
## Choosing the right tool
|
||||
|
||||
@@ -12,13 +13,13 @@ This guide covers implementing low-light features using **Night mode extensions*
|
||||
|
||||
## Night mode extension
|
||||
|
||||
CameraX Extensions provide access to the device's built-in computational photography pipeline.
|
||||
CameraX Extensions provide access to the device's built-in computational
|
||||
photography pipeline.
|
||||
|
||||
### Basic setup
|
||||
|
||||
To set up the extension, initialize the extension manager:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Use ListenableFuture.await() extension function for coroutine support
|
||||
@@ -29,7 +30,6 @@ if (extensionsManager.isExtensionAvailable(cameraSelector, ExtensionMode.NIGHT))
|
||||
)
|
||||
cameraProvider.bindToLifecycle(lifecycleOwner, nightSelector, imageCapture, preview)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -42,7 +42,6 @@ if (extensionsManager.isExtensionAvailable(cameraSelector, ExtensionMode.NIGHT))
|
||||
val imageCapture = ImageCapture.Builder()
|
||||
.setPostviewEnabled(true)
|
||||
.build()
|
||||
|
||||
```
|
||||
- **Extension strength** : Let users control the intensity of the night effect.
|
||||
|
||||
@@ -51,7 +50,6 @@ if (extensionsManager.isExtensionAvailable(cameraSelector, ExtensionMode.NIGHT))
|
||||
val extensionsManager = ExtensionsManager.getInstanceAsync(context, cameraProvider).await()
|
||||
val extensionsControl = extensionsManager.getCameraExtensionsControl(camera.cameraControl)
|
||||
extensionsControl?.setExtensionStrength(strength)
|
||||
|
||||
```
|
||||
- **Capture progress** : Show a UI progress bar for long exposures.
|
||||
|
||||
@@ -63,7 +61,6 @@ if (extensionsManager.isExtensionAvailable(cameraSelector, ExtensionMode.NIGHT))
|
||||
} catch (e: ImageCaptureException) {
|
||||
// Handle capture failure
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
*** ** * ** ***
|
||||
@@ -74,7 +71,8 @@ LLB is designed for preview and video streams where you prefer high frame rates.
|
||||
|
||||
### AE mode
|
||||
|
||||
The built-in CameraX way to prioritize brightness. It modifies the hardware's auto-exposure algorithm.
|
||||
The built-in CameraX way to prioritize brightness. It modifies the hardware's
|
||||
auto-exposure algorithm.
|
||||
|
||||
- **Activation** : Use `CameraControl.enableLowLightBoostAsync`.
|
||||
- **Implementation** :
|
||||
@@ -82,7 +80,6 @@ The built-in CameraX way to prioritize brightness. It modifies the hardware's au
|
||||
```kotlin
|
||||
// Enable Low Light Boost (LLB) natively in CameraX 1.4+
|
||||
camera.cameraControl.enableLowLightBoostAsync(true)
|
||||
|
||||
```
|
||||
- **Monitoring** : Observe `CameraInfo.lowLightBoostState` to track when the hardware actively applies the enhancement.
|
||||
|
||||
@@ -115,7 +112,6 @@ To implement Google Play services LLB, follow these core steps:
|
||||
.addUseCase(videoCapture)
|
||||
.addEffect(effect)
|
||||
.build()
|
||||
|
||||
```
|
||||
4. **Scene detection** : Use `session.setSceneDetectorCallback` to receive `boostStrength` updates for real-time UI indicators.
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
When you use ML Kit for features such as face mesh, object detection, or pose detection, the most common failure point is the coordinate disparity between the analysis image and the viewfinder UI.
|
||||
When you use ML Kit for features such as face mesh, object detection, or pose
|
||||
detection, the most common failure point is the coordinate disparity between the
|
||||
analysis image and the viewfinder UI.
|
||||
|
||||
## The mapping mindset
|
||||
|
||||
@@ -14,23 +16,25 @@ When you use ML Kit for features such as face mesh, object detection, or pose de
|
||||
|
||||
### Coordinate transformation matrix
|
||||
|
||||
Android provides the `Viewport` and `UseCaseGroup` APIs to calculate the transformation matrix automatically. **Don't** calculate aspect ratio scaling manually.
|
||||
Android provides the `Viewport` and `UseCaseGroup` APIs to calculate the
|
||||
transformation matrix automatically. **Don't** calculate aspect ratio scaling
|
||||
manually.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val transform = previewView.viewPort?.let { viewPort ->
|
||||
// Use CameraX's built-in coordinate mapper
|
||||
viewPort.getTransformationMatrix(imageProxy.imageInfo.rotationDegrees)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Handling the "double rotation" bug
|
||||
|
||||
ML Kit results, bounding boxes, are relative to the **rotated buffer**. If the device is in portrait, the buffer is often 480x640, landscape, but the screen is 1080x1920.
|
||||
ML Kit results, bounding boxes, are relative to the **rotated buffer**. If the
|
||||
device is in portrait, the buffer is often 480x640, landscape, but the screen
|
||||
is 1080x1920.
|
||||
|
||||
To map the coordinates, use the following workflow:
|
||||
|
||||
@@ -40,20 +44,20 @@ To map the coordinates, use the following workflow:
|
||||
|
||||
### Face mesh and pose normalization
|
||||
|
||||
For high-precision spatial analysis, for example, "Is the user's hand at a specific screen button?", use **normalized coordinates from 0.0 to 1.0**.
|
||||
For high-precision spatial analysis, for example, "Is the user's hand at a
|
||||
specific screen button?", use **normalized coordinates from 0.0 to 1.0**.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Example: Converting a Pose landmark to a Screen Coordinate
|
||||
val screenX = landmark.position.x / analysisWidth * screenWidth
|
||||
val screenY = landmark.position.y / analysisHeight * screenHeight
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
**Warning** : Always account for **mirrored lenses** . If the `LENS_FACING_FRONT` is used, you must flip the X-coordinate: `actualX = screenWidth - screenX`.
|
||||
**Warning** : Always account for **mirrored lenses** . If the `LENS_FACING_FRONT`
|
||||
is used, you must flip the X-coordinate: `actualX = screenWidth - screenX`.
|
||||
|
||||
### Overlays and canvas clipping
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
Always prefer these various abstractions over legacy Camera2 or early CameraX implementations.
|
||||
Always prefer these various abstractions over legacy Camera2 or early CameraX
|
||||
implementations.
|
||||
|
||||
## Compare APIs
|
||||
|
||||
@@ -37,4 +38,5 @@ Add the following dependencies to your `libs.versions.toml` file:
|
||||
androidx-camera-extensions = { group = "androidx.camera", name =
|
||||
"camera-extensions", version.ref = "camerax" }
|
||||
|
||||
Refer to the official [CameraX Release Notes](https://developer.android.com/jetpack/androidx/releases/camera) for the stable versions.
|
||||
Refer to the official [CameraX Release Notes](https://developer.android.com/jetpack/androidx/releases/camera) for the
|
||||
stable versions.
|
||||
@@ -1,4 +1,6 @@
|
||||
Automated testing for camera features is notoriously difficult because you can't easily mock physical hardware, lighting, or motion. This guide provides patterns for reliable, hermetic camera tests.
|
||||
Automated testing for camera features is notoriously difficult because you
|
||||
can't easily mock physical hardware, lighting, or motion. This guide provides
|
||||
patterns for reliable, hermetic camera tests.
|
||||
|
||||
## Develop a testing mindset
|
||||
|
||||
@@ -15,41 +17,42 @@ Automated testing for camera features is notoriously difficult because you can't
|
||||
|
||||
### Fakes over mocks
|
||||
|
||||
**Don't use Mockito.** Relying on mocks for complex, rapidly changing interfaces like `ImageProxy` or `CameraInfo` makes tests brittle. Instead, build "Fake" implementations that verify state rather than behavior.
|
||||
**Don't use Mockito.** Relying on mocks for complex, rapidly changing interfaces
|
||||
like `ImageProxy` or `CameraInfo` makes tests brittle. Instead, build "Fake"
|
||||
implementations that verify state rather than behavior.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Create a Fake ImageProxy for ML Testing (Fakes over Mocks)
|
||||
val fakeImage = FakeImageProxy(w = 640, h = 480)
|
||||
|
||||
// Feed the fake buffer into your analyzer
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Mock camera capabilities
|
||||
|
||||
Use `FakeAppConfig` from `androidx.camera:camera-testing` to simulate specific hardware constraints in tests, such as a device without a flash.
|
||||
Use `FakeAppConfig` from `androidx.camera:camera-testing` to simulate specific
|
||||
hardware constraints in tests, such as a device without a flash.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Use awaitInstance() extension function for coroutine-based provider retrieval
|
||||
val cameraProvider = ProcessCameraProvider.awaitInstance(context)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Use Truth assertions
|
||||
|
||||
Use Google Truth, `assertThat`, instead of standard JUnit assertions. It provides more readable assertion chains and useful failure messages.
|
||||
Use Google Truth, `assertThat`, instead of standard JUnit assertions. It
|
||||
provides more readable assertion chains and useful failure messages.
|
||||
|
||||
### Test asynchronous lifecycles
|
||||
|
||||
Camera initialization is asynchronous. Use `IdlingResource` to ensure your test waits for the `UseCase` to be bound before asserting.
|
||||
Camera initialization is asynchronous. Use `IdlingResource` to ensure
|
||||
your test waits for the `UseCase` to be bound before asserting.
|
||||
|
||||
To test asynchronous lifecycles, use the following pattern:
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
Camera operations are among the most power-intensive tasks on mobile devices. Without proactive management, the system throttle hardware, drop frames, or force-close the camera app.
|
||||
Camera operations are among the most power-intensive tasks on mobile devices.
|
||||
Without proactive management, the system throttle hardware, drop frames, or
|
||||
force-close the camera app.
|
||||
|
||||
## The thermal management strategy
|
||||
|
||||
@@ -14,9 +16,9 @@ Camera operations are among the most power-intensive tasks on mobile devices. Wi
|
||||
|
||||
### Stream use case optimization
|
||||
|
||||
Android 13 (API level 33) introduced `StreamUseCase`. This is the **single most effective** way to tell the hardware how to balance quality versus power.
|
||||
Android 13 (API level 33) introduced `StreamUseCase`. This is the **single most
|
||||
effective** way to tell the hardware how to balance quality versus power.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// In CameraX: Set the hint on your Use Case
|
||||
@@ -28,7 +30,6 @@ val preview = Preview.Builder()
|
||||
)
|
||||
}
|
||||
.build()
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -42,9 +43,9 @@ Review the following key use cases for stream optimization:
|
||||
|
||||
### Monitor thermal status
|
||||
|
||||
Don't wait for a crash. Monitor the `PowerManager` status and react before `THERMAL_STATUS_CRITICAL`.
|
||||
Don't wait for a crash. Monitor the `PowerManager` status and react before
|
||||
`THERMAL_STATUS_CRITICAL`.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val powerManager = context.getSystemService(Context.POWER_SERVICE) as PowerManager
|
||||
@@ -62,7 +63,6 @@ powerManager.addThermalStatusListener { status ->
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
Developing camera features for Wear OS is rarely about the watch's own lens, if it even has one. It's almost always about creating a **Remote Viewfinder** to control the phone's camera.
|
||||
Developing camera features for Wear OS is rarely about the watch's own lens, if
|
||||
it even has one. It's almost always about creating a **Remote Viewfinder** to
|
||||
control the phone's camera.
|
||||
|
||||
## The Wear OS remote mindset
|
||||
|
||||
@@ -15,7 +17,8 @@ Developing camera features for Wear OS is rarely about the watch's own lens, if
|
||||
|
||||
### The circular UI challenge
|
||||
|
||||
Wear OS devices are often round. Standard rectangular layouts clip corner buttons.
|
||||
Wear OS devices are often round. Standard rectangular layouts clip corner
|
||||
buttons.
|
||||
|
||||
Follow these blueprint recommendations:
|
||||
|
||||
@@ -27,7 +30,6 @@ Follow these blueprint recommendations:
|
||||
|
||||
You can't send a raw 60 fps stream over Bluetooth. compress and throttle.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Example: Sending a viewfinder frame to the watch
|
||||
@@ -39,31 +41,30 @@ if (bitmap != null) {
|
||||
}
|
||||
Wearable.getDataClient(context).putDataItem(request.asPutDataRequest())
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
**Optimization** : Cap the watch preview at **10-15 fps** to preserve battery and bandwidth.
|
||||
**Optimization** : Cap the watch preview at **10-15 fps** to preserve battery and
|
||||
bandwidth.
|
||||
|
||||
### Remote triggers and syncing
|
||||
|
||||
Use the `MessageClient` for low-latency commands like "Take Photo" or "Switch Camera."
|
||||
Use the `MessageClient` for low-latency commands like "Take Photo" or "Switch
|
||||
Camera."
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Watch sends a trigger to the phone
|
||||
Wearable.getMessageClient(context).sendMessage(nodeId, "/camera/capture", null)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Rotary input support
|
||||
|
||||
On devices that support it, use the physical crown, Rotary Input, to control **Zoom** or **Exposure**.
|
||||
On devices that support it, use the physical crown, Rotary Input, to control
|
||||
**Zoom** or **Exposure**.
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
Developing camera features for XR devices, headsets, and AR glasses requires a shift from 2D pixel-pushing to 3D spatial awareness.
|
||||
Developing camera features for XR devices, headsets, and AR glasses requires a
|
||||
shift from 2D pixel-pushing to 3D spatial awareness.
|
||||
|
||||
## Understand the XR development mindset
|
||||
|
||||
@@ -14,7 +15,8 @@ Developing camera features for XR devices, headsets, and AR glasses requires a s
|
||||
|
||||
### API selection
|
||||
|
||||
On XR devices, standard `CameraX` implementations are often restricted or insufficient. Always use spatial software development kits (SDKs):
|
||||
On XR devices, standard `CameraX` implementations are often restricted or
|
||||
insufficient. Always use spatial software development kits (SDKs):
|
||||
|
||||
- **ARCore**: Use ARCore for plane detection, depth sensing, and motion tracking.
|
||||
- **OpenXR**: Use OpenXR as the cross-platform standard for VR and AR rendering and input.
|
||||
@@ -24,13 +26,13 @@ On XR devices, standard `CameraX` implementations are often restricted or insuff
|
||||
|
||||
Unlike a 2D viewport, XR passthrough is often system-managed.
|
||||
|
||||
**\[Key requirement\] Frame synchronization**: Synchronize your application's frame clock with the headset's head-mounted display (HMD) pose.
|
||||
**\[Key requirement\] Frame synchronization**: Synchronize your application's
|
||||
frame clock with the headset's head-mounted display (HMD) pose.
|
||||
|
||||
```kotlin
|
||||
// Example: Querying the spatial pose for the current camera frame
|
||||
val headPose = xrSession.getHeadPose(frameTime)
|
||||
val projectionMatrix = headPose.getProjectionMatrix(eyeIndex)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
@@ -9,7 +9,7 @@ description: Analyzes Android apps to identify key user workflows for AppFunctio
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-14'
|
||||
keywords:
|
||||
- AppFunctions
|
||||
- Kotlin
|
||||
@@ -20,19 +20,29 @@ metadata:
|
||||
- MCP
|
||||
---
|
||||
|
||||
Analyzes Android apps to identify key user workflows for AppFunctions such as creating a note, playing media, or sending an automated or AI agent triggered message, voice commands, or system shortcuts, without needing to open the app UI.
|
||||
Analyzes Android apps to identify key user workflows for AppFunctions such as
|
||||
creating a note, playing media, or sending an automated or AI agent triggered
|
||||
message, voice commands, or system shortcuts, without needing to open the app
|
||||
UI.
|
||||
|
||||
Generates Kotlin code to expose these workflows to the Android system, allowing agents to discover and execute them on-device.
|
||||
Generates Kotlin code to expose these workflows to the Android system,
|
||||
allowing agents to discover and execute them on-device.
|
||||
|
||||
Also refines KDoc documentation to ensure AI agents correctly understand and use the provided functionality.
|
||||
Also refines KDoc documentation to ensure AI agents correctly
|
||||
understand and use the provided functionality.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
The app must **`targetSdk 36`** or newer and use **`compileSdk 37`** or newer as AppFunctions, part of the Android platform API, are available from Android 16 onwards. Always use the Jetpack library because it handles backward compatibility.
|
||||
The app must **`targetSdk 36`** or newer and use **`compileSdk 37`** or newer as
|
||||
AppFunctions, part of the Android platform API, are available from Android 16
|
||||
onwards.
|
||||
Always use the Jetpack library because it handles backward compatibility.
|
||||
|
||||
## Workflows
|
||||
|
||||
This skill enables the caller to discover features that will be provided to system agents, implement these with AppFunctions, improve function description for agents, and use ADB commands for local evaluation and testing.
|
||||
This skill enables the caller to discover features that will be provided to
|
||||
system agents, implement these with AppFunctions, improve function description
|
||||
for agents, and use ADB commands for local evaluation and testing.
|
||||
|
||||
The full AppFunction development flow consists of these four steps:
|
||||
|
||||
|
||||
@@ -1,13 +1,16 @@
|
||||
Provides commands to interact with AppFunctions on a connected device or emulator using ADB for AppFunction testing and debugging.
|
||||
Provides commands to interact with AppFunctions on a connected device or
|
||||
emulator using ADB for AppFunction testing and debugging.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Scenario 1: List app functions
|
||||
|
||||
Use this scenario when you want to see which app functions are registered on the device.
|
||||
Use this scenario when you want to see which app functions are registered on
|
||||
the device.
|
||||
|
||||
1. **List all functions** : To view all registered app functions in JSON format, run `adb shell cmd app_function list-app-functions`.
|
||||
2. **Filter by package** : To view functions for a specific package, pipe the output to `grep` or a JSON tool: `adb shell cmd app_function list-app-functions | grep <package_name>`.
|
||||
2. **Filter by package** : To view functions for a specific package, pipe the output to `grep` or a JSON tool: `adb shell cmd app_function
|
||||
list-app-functions | grep <package_name>`.
|
||||
|
||||
### Scenario 2: Invoke app functions
|
||||
|
||||
@@ -16,28 +19,38 @@ If you want to test the execution of an app function, use this scenario.
|
||||
1. **Analyze description** : Before invoking, you must read the `description` field for the function in the `list-app-functions` output. This often contains critical usage constraints, required workflows, or disambiguation rules.
|
||||
2. **Follow constraints**: Follow all instructions in the description, such as asking the user to disambiguate or calling another tool first.
|
||||
3. **Format parameters** : Format the `--parameters` argument as a valid JSON string that represents the function's input arguments.
|
||||
4. **Execute function** : Use `adb shell cmd app_function execute-app-function --package <PACKAGE_NAME> --function <SERVICE_CLASS_NAME#FUNCTION_NAME> --parameters '<PARAMETERS_JSON>'`.
|
||||
4. **Execute function** : Use `adb shell cmd app_function execute-app-function
|
||||
--package <PACKAGE_NAME> --function <SERVICE_CLASS_NAME#FUNCTION_NAME>
|
||||
--parameters '<PARAMETERS_JSON>'`.
|
||||
5. **Handle response** : The command returns the result as a JSON string. To get brief YAML output, use `--brief-yaml`.
|
||||
|
||||
### Scenario 3: Manage function state
|
||||
|
||||
If you need to enable or disable an app function for testing, use this scenario.
|
||||
|
||||
1. **Set enabled state** : Use `adb shell cmd app_function set-enabled --package <PACKAGE_NAME> --function <SERVICE_CLASS_NAME#FUNCTION_NAME> --state <enable|disable|default>`.
|
||||
1. **Set enabled state** : Use `adb shell cmd app_function set-enabled
|
||||
--package <PACKAGE_NAME>
|
||||
--function <SERVICE_CLASS_NAME#FUNCTION_NAME>
|
||||
--state <enable|disable|default>`.
|
||||
|
||||
## Critical constraints
|
||||
|
||||
### Follow metadata descriptions
|
||||
|
||||
**Mandatory** : The `description` field in the app function metadata is a set of instructions for the LLM. If a description says to "disambiguate with the user" or "call another function first," you must perform those steps before execution.
|
||||
**Mandatory** : The `description` field in the app function metadata is a set of
|
||||
instructions for the LLM. If a description says to "disambiguate with the user"
|
||||
or "call another function first," you must perform those steps before execution.
|
||||
|
||||
### JSON escaping
|
||||
|
||||
**Critical** : When passing JSON using `adb shell`, always wrap the JSON string in single quotes to prevent the shell from interpreting special characters or spaces. Example: `--parameters '{"key": "value"}'`.
|
||||
**Critical** : When passing JSON using `adb shell`, always wrap the JSON string
|
||||
in single quotes to prevent the shell from interpreting special characters or
|
||||
spaces. Example: `--parameters '{"key": "value"}'`.
|
||||
|
||||
### Device availability
|
||||
|
||||
The `app_function` service must be available on the device. If `cmd: Can't find service: app_function` is returned, the device doesn't support this feature.
|
||||
The `app_function` service must be available on the device. If `cmd: Can't find
|
||||
service: app_function` is returned, the device doesn't support this feature.
|
||||
|
||||
## Examples
|
||||
|
||||
@@ -45,7 +58,8 @@ The `app_function` service must be available on the device. If `cmd: Can't find
|
||||
|
||||
adb shell cmd app_function help
|
||||
|
||||
If executing the preceding command returns a help page, use the commands and parameters provided to guide the ADB interaction testing tool interactions.
|
||||
If executing the preceding command returns a help page, use the commands and
|
||||
parameters provided to guide the ADB interaction testing tool interactions.
|
||||
|
||||
### Example 2: List all registered app functions
|
||||
|
||||
@@ -77,4 +91,5 @@ If executing the preceding command returns a help page, use the commands and par
|
||||
|
||||
**Cause**: The function ID or package name is incorrect.
|
||||
|
||||
**Solution** : Run `list-app-functions` and search for the relevant identifiers in the JSON output.
|
||||
**Solution** : Run `list-app-functions` and search for the relevant identifiers
|
||||
in the JSON output.
|
||||
@@ -2,10 +2,25 @@ Defines the ubiquitous language for the Android AppFunctions skill suite.
|
||||
|
||||
## Architecture and versioning
|
||||
|
||||
`AppFunctionServiceEntryPoint` API: This compile-time AppFunctions architecture was introduced in version 1.0.0-alpha10. You annotate a wrapper service extending `AppFunctionService` with `@AppFunctionServiceEntryPoint`. KSP then generates XML metadata and routes services at compile time.
|
||||
`AppFunctionServiceEntryPoint` API:
|
||||
This compile-time AppFunctions architecture was introduced in version
|
||||
1.0.0-alpha10. You annotate a wrapper service extending
|
||||
`AppFunctionService` with `@AppFunctionServiceEntryPoint`. KSP then generates
|
||||
XML metadata and routes services at compile time.
|
||||
|
||||
Legacy manual provider API: This deprecated AppFunctions architecture applies to version 1.0.0-alpha09 and earlier. Applications implement `AppFunctionConfiguration.Provider` on the `Application` class. Methods require `AppFunctionContext` as the first parameter. Projects depend on a standalone `appfunctions-service` library.
|
||||
Legacy manual provider API:
|
||||
This deprecated AppFunctions architecture applies to version
|
||||
1.0.0-alpha09 and earlier. Applications implement
|
||||
`AppFunctionConfiguration.Provider` on the `Application` class. Methods
|
||||
require `AppFunctionContext` as the first parameter. Projects depend on
|
||||
a standalone `appfunctions-service` library.
|
||||
|
||||
## Patterns
|
||||
|
||||
Service entry point pattern: Version 1.0.0-alpha10 introduced this architectural pattern. You declare `@AppFunction` methods directly inside an abstract class extending `AppFunctionService`. This class uses `@AppFunctionServiceEntryPoint` and `@AndroidEntryPoint` annotations. These annotations let you inject data sources or repositories directly, without an intermediate business logic delegation layer.
|
||||
Service entry point pattern:
|
||||
Version 1.0.0-alpha10 introduced this architectural pattern. You
|
||||
declare `@AppFunction` methods directly inside an abstract class extending
|
||||
`AppFunctionService`. This class uses `@AppFunctionServiceEntryPoint` and
|
||||
`@AndroidEntryPoint` annotations. These annotations let you inject data
|
||||
sources or repositories directly, without an intermediate business logic
|
||||
delegation layer.
|
||||
@@ -13,11 +13,15 @@ Analyzes Android codebases to identify and recommend high-value AppFunctions.
|
||||
|
||||
### Tool-first thinking
|
||||
|
||||
Avoid recommending functions that are purely informational or redundant with existing system actions. Focus on "mutations" (writing data) or "rich queries" (finding specific entities).
|
||||
Avoid recommending functions that are purely informational or redundant with
|
||||
existing system actions. Focus on "mutations" (writing data) or "rich queries"
|
||||
(finding specific entities).
|
||||
|
||||
### Security and privacy
|
||||
|
||||
Don't recommend exposing functions that handle raw credentials, financial secrets, or irreversible destructive actions without explicit user confirmation steps.
|
||||
Don't recommend exposing functions that handle raw credentials, financial
|
||||
secrets, or irreversible destructive actions without explicit user confirmation
|
||||
steps.
|
||||
|
||||
## Examples
|
||||
|
||||
@@ -25,7 +29,9 @@ Don't recommend exposing functions that handle raw credentials, financial secret
|
||||
|
||||
**Recommended AppFunction** : `playArtistRadio`
|
||||
|
||||
**Rationale**: Lets you start a personalized music stream using a voice command, bypassing several layers of navigation in the "Search" and "Artist" menus.
|
||||
**Rationale**: Lets you start a personalized music stream using a voice
|
||||
command, bypassing several layers of navigation in the "Search" and "Artist"
|
||||
menus.
|
||||
|
||||
**Input required** : `artistName` as a `String`.
|
||||
|
||||
@@ -33,22 +39,33 @@ Don't recommend exposing functions that handle raw credentials, financial secret
|
||||
|
||||
**Recommended AppFunction** : `searchContacts`
|
||||
|
||||
**Rationale** : Serves as a "rich query" to resolve a human-readable contact name, email, or chat group to a unique identifier (`endpointValue`), which is a prerequisite before executing actions like sending messages or initiating calls. Also allows retrieving recently contacted entities when given a blank query.
|
||||
**Rationale** : Serves as a "rich query" to resolve a human-readable contact
|
||||
name, email, or chat group to a unique identifier (`endpointValue`), which is a
|
||||
prerequisite before executing actions like sending messages or
|
||||
initiating calls. Also allows retrieving recently contacted entities when given
|
||||
a blank query.
|
||||
|
||||
**Input required** : Query as a `String`, and Filter Type as a `String` constrained to `"INDIVIDUAL"` or `"GROUP"`.
|
||||
**Input required** : Query as a `String`, and Filter Type as a `String`
|
||||
constrained to `"INDIVIDUAL"` or `"GROUP"`.
|
||||
|
||||
### Example 3: Chat app message sending
|
||||
|
||||
**Recommended AppFunction** : `send`
|
||||
|
||||
**Rationale**: This mutation function lets you send text messages and optional image attachments to a contact or group using natural language commands, for example, "Tell Alice I'm running 5 minutes late." This eliminates multi-step UI navigation across contact lists and conversation threads.
|
||||
**Rationale**: This mutation function lets you send text messages and
|
||||
optional image attachments to a contact or group using natural language
|
||||
commands, for example, "Tell Alice I'm running 5 minutes late." This
|
||||
eliminates multi-step UI navigation across contact lists and conversation
|
||||
threads.
|
||||
|
||||
**Input required** : Endpoint Value as a `String`, Message Body as a `String`, and Image URIs as an optional `List` of URIs.
|
||||
**Input required** : Endpoint Value as a `String`, Message Body as a `String`,
|
||||
and Image URIs as an optional `List` of URIs.
|
||||
|
||||
### Example 4: Chat app voice calling
|
||||
|
||||
**Recommended AppFunction** : `makeCall`
|
||||
|
||||
**Rationale**: Lets you initiate voice calls hands-free to a contact or group using an AI agent without navigating the app's UI.
|
||||
**Rationale**: Lets you initiate voice calls hands-free to a contact or
|
||||
group using an AI agent without navigating the app's UI.
|
||||
|
||||
**Input required** : `endpointValue` as a `String`.
|
||||
@@ -1,19 +1,19 @@
|
||||
Specialized instructions for generating Kotlin implementations of AppFunctions, handling system-wide configuration, and managing build dependencies.
|
||||
Specialized instructions for generating Kotlin implementations of AppFunctions,
|
||||
handling system-wide configuration, and managing build dependencies.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Configure Gradle dependencies and KSP
|
||||
|
||||
Add the following to `build.gradle.kts`. App Functions requires the KSP (Kotlin Symbol Processing) plugin.
|
||||
Add the following to `build.gradle.kts`. App Functions requires the KSP (Kotlin
|
||||
Symbol Processing) plugin.
|
||||
|
||||
1. **Version check** : Use library version `1.0.0-alpha10` or later from maven.google.com.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
implementation(libs.androidx.appfunctions)
|
||||
ksp(libs.androidx.appfunctions.compiler)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -24,9 +24,9 @@ ksp(libs.androidx.appfunctions.compiler)
|
||||
|
||||
### Step 2: Set up app metadata XML
|
||||
|
||||
Describe the app's capabilities to the LLM by defining `res/xml/app_metadata.xml`.
|
||||
Describe the app's capabilities to the LLM by defining
|
||||
`res/xml/app_metadata.xml`.
|
||||
|
||||
<br />
|
||||
|
||||
```xml
|
||||
<AppFunctionAppMetadata xmlns:appfn="http://schemas.android.com/apk/androidx.appfunctions"
|
||||
@@ -36,14 +36,13 @@ Describe the app's capabilities to the LLM by defining `res/xml/app_metadata.xml
|
||||
Constraints:
|
||||
- Title or content must be non-null when creating a task."
|
||||
appfn:displayDescription="@string/user_visible_description" />
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Register the service and reference the app metadata in `AndroidManifest.xml` within the `<application>` tag:
|
||||
Register the service and reference the app metadata in `AndroidManifest.xml`
|
||||
within the `<application>` tag:
|
||||
|
||||
<br />
|
||||
|
||||
```xml
|
||||
<service
|
||||
@@ -64,7 +63,6 @@ Register the service and reference the app metadata in `AndroidManifest.xml` wit
|
||||
<property
|
||||
android:name="android.app.appfunctions.app_metadata"
|
||||
android:resource="@xml/app_metadata" />
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -98,13 +96,16 @@ When generating Kotlin code for AppFunctions, you MUST adhere to these rules:
|
||||
|
||||
### Step 4: Set up dependency injection and service entry points
|
||||
|
||||
In version 1.0.0-alpha10 and later, App Functions use the compile-time `@AppFunctionServiceEntryPoint` architecture. Create an abstract class extending `AppFunctionService` annotated with `@AppFunctionServiceEntryPoint`. KSP generates the concrete service class and XML schema.
|
||||
In version 1.0.0-alpha10 and later, App Functions use the compile-time
|
||||
`@AppFunctionServiceEntryPoint` architecture. Create an abstract class extending
|
||||
`AppFunctionService` annotated with `@AppFunctionServiceEntryPoint`. KSP
|
||||
generates the concrete service class and XML schema.
|
||||
|
||||
#### Recommended approach with Hilt
|
||||
|
||||
Annotate your service with `@AndroidEntryPoint` and inject your data repositories or use cases using standard `@Inject internal lateinit var`:
|
||||
Annotate your service with `@AndroidEntryPoint` and inject your data
|
||||
repositories or use cases using standard `@Inject internal lateinit var`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@RequiresApi(36)
|
||||
@@ -125,16 +126,19 @@ abstract class BaseAppFunctionServiceHeader : AppFunctionService() {
|
||||
return messageRepository.send(name, endpointValue, messageBody)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
#### Framework-agnostic approach with alternative dependency injection or service locators
|
||||
|
||||
While Hilt is recommended, many Android applications implement AppFunctions with alternative dependency injection frameworks (like Koin, Anvil, or manual Service Locators). Because `AppFunctionService` inherits from Android `android.app.Service` (and therefore `Context`), you are able access your application's DI container directly through `applicationContext` in property getters or during service lifecycle execution:
|
||||
While Hilt is recommended, many Android applications implement AppFunctions with
|
||||
alternative dependency injection frameworks (like Koin, Anvil, or manual Service
|
||||
Locators). Because `AppFunctionService` inherits from Android
|
||||
`android.app.Service` (and therefore `Context`), you are able access your
|
||||
application's DI container directly through `applicationContext` in property
|
||||
getters or during service lifecycle execution:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@RequiresApi(36)
|
||||
@@ -159,14 +163,16 @@ abstract class BaseAppFunctionServiceLocator : AppFunctionService() {
|
||||
return messageRepository.send(name, endpointValue, messageBody)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Step 5: Architectural cleanliness
|
||||
|
||||
Don't attempt to make an `AppFunction` class or method OS-agnostic---App Functions are inherently part of the Android platform integration in `androidx.appfunctions`. For architectural cleanliness, use existing application functionality (such as existing repositories, use cases, or domain orchestrators) to execute the behavior within your `@AppFunction` methods rather than creating redundant abstraction layers around the OS service.
|
||||
Don't attempt to make an `AppFunction` class or method OS-agnostic---App Functions are inherently part of the Android platform integration in `androidx.appfunctions`. For architectural cleanliness, use existing
|
||||
application functionality (such as existing repositories, use cases, or domain
|
||||
orchestrators) to execute the behavior within your `@AppFunction` methods rather
|
||||
than creating redundant abstraction layers around the OS service.
|
||||
|
||||
<br />
|
||||
|
||||
@@ -174,17 +180,19 @@ Don't attempt to make an `AppFunction` class or method OS-agnostic---App Functio
|
||||
|
||||
### KSP compliance for serializables
|
||||
|
||||
**Critical constraints** : For `@AppFunctionSerializable` data classes, KSP only extracts documentation if it's written as inline KDoc directly for each property definition. Don't use class-level `@param` or `@property` tags.
|
||||
**Critical constraints** : For `@AppFunctionSerializable` data classes, KSP
|
||||
only extracts documentation if it's written as inline KDoc directly for each
|
||||
property definition. Don't use class-level `@param` or `@property` tags.
|
||||
|
||||
### Package integrity
|
||||
|
||||
Configuration APIs and the `@AppFunction` annotation are located in `androidx.appfunctions`.
|
||||
Configuration APIs and the `@AppFunction` annotation are located in
|
||||
`androidx.appfunctions`.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example: Serializable with inline KDoc
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
/** The parameter to create the task. */
|
||||
@@ -206,7 +214,6 @@ data class Task(
|
||||
/** The content of the task. */
|
||||
val content: String,
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -215,7 +222,6 @@ data class Task(
|
||||
|
||||
### Example: Implementation detail
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@RequiresApi(36)
|
||||
@@ -256,7 +262,6 @@ abstract class BaseTaskAppFunctionService : AppFunctionService() {
|
||||
// Maps internal TaskEntity
|
||||
private fun TaskEntity.toTask() = Task(id = id, title = title, content = description)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
@@ -5,7 +5,8 @@ Optimizes AppFunction KDoc for AI agents and Model Context Protocol.
|
||||
### Workflow: Agent-centric documentation
|
||||
|
||||
1. **Identify the core outcome** : Start the description with a strong imperative verb, for example, "Search", "Create", or "Update". Focus on the *user benefit*, not the code implementation.
|
||||
2. **Workflow dependencies** : Explicitly state if another function must be called first using the standard phrase: **Required workflow: Call "Function A" first to "Objective"**.
|
||||
2. **Workflow dependencies** : Explicitly state if another function must be called first using the standard phrase: **Required workflow: Call "Function
|
||||
A" first to "Objective"**.
|
||||
3. **Parameter documentation** :
|
||||
- For **functions** : Use specific `@param` tags. Isolate validation rules and default values here.
|
||||
- For **serializables** : Use inline KDoc directly for each property declaration. KSP **won't** extract documentation from class-level tags.
|
||||
@@ -13,7 +14,8 @@ Optimizes AppFunction KDoc for AI agents and Model Context Protocol.
|
||||
|
||||
### Workflow: Global app description for server instructions
|
||||
|
||||
When writing the `appfn:description` for `app_metadata.xml`, follow these instructions:
|
||||
When writing the `appfn:description` for `app_metadata.xml`, follow these
|
||||
instructions:
|
||||
|
||||
1. **Capture cross-function relationships**: Explain dependencies or sequences between tools, for example, "Always call 'authenticate' before fetching data.".
|
||||
2. **Document operational patterns**: Guide the LLM on token-conserving usage, for example, "Use 'batch_update' over multiple 'update' calls."
|
||||
@@ -27,15 +29,19 @@ When writing the `appfn:description` for `app_metadata.xml`, follow these instru
|
||||
|
||||
### Descriptive, not imperative
|
||||
|
||||
Describe what the function *does* , not what the LLM *must* do. Avoid phrases like "You must call this..." in favor of "This function provides...".
|
||||
Describe what the function *does* , not what the LLM *must* do. Avoid phrases
|
||||
like "You must call this..." in favor of "This function provides...".
|
||||
|
||||
### No "fluff"
|
||||
|
||||
Remove conversational padding like "This method is used to..." or "Helpful for...". Be concise and technical.
|
||||
Remove conversational padding like "This method is used to..." or "Helpful
|
||||
for...". Be concise and technical.
|
||||
|
||||
### Inline KDoc for serializables
|
||||
|
||||
**Mandatory** : For `@AppFunctionSerializable` classes, documentation must be inline for each property. KSP ignores class-level `@param` or `@property` tags for these classes.
|
||||
**Mandatory** : For `@AppFunctionSerializable` classes, documentation must be
|
||||
inline for each property. KSP ignores class-level `@param` or `@property` tags
|
||||
for these classes.
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
Follow this systematic procedure to migrate Android applications that use the AppFunctions API in version 1.0.0-alpha09 and lower to the compile-time `@AppFunctionServiceEntryPoint` architecture introduced in version `1.0.0-alpha10`.
|
||||
Follow this systematic procedure to migrate Android applications that use the
|
||||
AppFunctions API in version 1.0.0-alpha09 and lower to the compile-time
|
||||
`@AppFunctionServiceEntryPoint` architecture introduced in version
|
||||
`1.0.0-alpha10`.
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
@@ -20,7 +23,9 @@ In version `1.0.0-alpha10` featuring `@AppFunctionServiceEntryPoint`:
|
||||
|
||||
### Strict migration requirements from 1.0.0-alpha09 to 1.0.0-alpha10
|
||||
|
||||
When focusing solely on the mandatory API changes required by the new `@AppFunctionServiceEntryPoint` architecture, the migration consists of four strict requirements that you must complete:
|
||||
When focusing solely on the mandatory API changes required by the new
|
||||
`@AppFunctionServiceEntryPoint` architecture, the migration consists of four
|
||||
strict requirements that you must complete:
|
||||
|
||||
1. **Build dependency consolidation** : Remove the merged `appfunctions-service` dependency while retaining core `appfunctions` and the KSP compiler.
|
||||
2. **Service wrapper creation** : Replace the legacy `AppFunctionConfiguration.Provider` on the `Application` class with an abstract class extending `AppFunctionService`, annotated with `@AppFunctionServiceEntryPoint`.
|
||||
@@ -33,7 +38,10 @@ When focusing solely on the mandatory API changes required by the new `@AppFunct
|
||||
|
||||
### Consolidate AppFunctions build dependencies
|
||||
|
||||
Remove the standalone `appfunctions-service` library from your module build files like `build.gradle.kts` and version catalog like `libs.versions.toml`. In version `1.0.0-alpha10`, all core service capabilities are consolidated directly within the main `appfunctions` artifact.
|
||||
Remove the standalone `appfunctions-service` library from your module build
|
||||
files like `build.gradle.kts` and version catalog like `libs.versions.toml`. In
|
||||
version `1.0.0-alpha10`, all core service capabilities are consolidated directly
|
||||
within the main `appfunctions` artifact.
|
||||
|
||||
// build.gradle.kts
|
||||
dependencies {
|
||||
@@ -58,13 +66,16 @@ Remove the standalone `appfunctions-service` library from your module build file
|
||||
|
||||
### Create a dedicated wrapper service extending `AppFunctionService`
|
||||
|
||||
Instead of annotating standalone business logic classes or implementing manual configuration providers, create an abstract service wrapper across your project, for example `BaseAppFunctionService`, extending `AppFunctionService` and annotated with `@AppFunctionServiceEntryPoint`.
|
||||
Instead of annotating standalone business logic classes or implementing manual
|
||||
configuration providers, create an abstract service wrapper across your project,
|
||||
for example `BaseAppFunctionService`, extending `AppFunctionService` and
|
||||
annotated with `@AppFunctionServiceEntryPoint`.
|
||||
|
||||
#### Recommended approach using Hilt
|
||||
|
||||
Annotate your service with `@AndroidEntryPoint` and inject your data repositories or use cases using standard `@Inject internal lateinit var`:
|
||||
Annotate your service with `@AndroidEntryPoint` and inject your data
|
||||
repositories or use cases using standard `@Inject internal lateinit var`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@RequiresApi(36)
|
||||
@@ -85,16 +96,19 @@ abstract class BaseAppFunctionService : AppFunctionService() {
|
||||
return messageRepository.send(name, endpointValue, messageBody)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
#### Framework-agnostic approach using alternative dependency injection or a service locator
|
||||
|
||||
While Hilt is recommended, many Android applications implement AppFunctions with alternative dependency injection frameworks like Koin, Anvil, or manual Service Locators. Because `AppFunctionService` inherits from Android `android.app.Service` and therefore `Context`, you are able access your application's DI container directly through `applicationContext` in property getters or during service lifecycle execution:
|
||||
While Hilt is recommended, many Android applications implement AppFunctions with
|
||||
alternative dependency injection frameworks like Koin, Anvil, or manual Service
|
||||
Locators. Because `AppFunctionService` inherits from Android
|
||||
`android.app.Service` and therefore `Context`, you are able access your
|
||||
application's DI container directly through `applicationContext` in property
|
||||
getters or during service lifecycle execution:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@RequiresApi(36)
|
||||
@@ -119,7 +133,6 @@ abstract class ServiceLocatorBaseAppFunctionService : AppFunctionService() {
|
||||
return messageRepository.send(name, endpointValue, messageBody)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -131,7 +144,10 @@ abstract class ServiceLocatorBaseAppFunctionService : AppFunctionService() {
|
||||
|
||||
### Simplify method signatures and decouple context
|
||||
|
||||
Remove legacy `AppFunctionContext` parameters from your core methods. When a method requires an Android `Context`, for example when constructing a `PendingIntent`, access `this` directly from your `AppFunctionService` wrapper because the wrapper inherently extends `android.content.Context`.
|
||||
Remove legacy `AppFunctionContext` parameters from your core methods. When a
|
||||
method requires an Android `Context`, for example when constructing a
|
||||
`PendingIntent`, access `this` directly from your `AppFunctionService` wrapper
|
||||
because the wrapper inherently extends `android.content.Context`.
|
||||
|
||||
- suspend fun makeCall(appFunctionContext: AppFunctionContext, contactName: String?): PendingIntent
|
||||
+ suspend fun makeCall(contactName: String?): PendingIntent
|
||||
@@ -140,7 +156,8 @@ Remove legacy `AppFunctionContext` parameters from your core methods. When a met
|
||||
|
||||
### Remove legacy configuration provider
|
||||
|
||||
Update your `Application` class by removing `AppFunctionConfiguration.Provider` and its associated builder entry points:
|
||||
Update your `Application` class by removing
|
||||
`AppFunctionConfiguration.Provider` and its associated builder entry points:
|
||||
|
||||
- abstract class BaseChatApplication : Application(), AppFunctionConfiguration.Provider { ... }
|
||||
+ abstract class BaseChatApplication : Application()
|
||||
@@ -149,15 +166,21 @@ Update your `Application` class by removing `AppFunctionConfiguration.Provider`
|
||||
|
||||
### Avoid redundant abstraction layers
|
||||
|
||||
Don't attempt to make an `AppFunction` class or method OS-agnostic---AppFunctions are inherently part of the Android platform integration through the `androidx.appfunctions` package. For architectural cleanliness, use existing application functionality, such as existing repositories, use cases, or domain orchestrators, to execute the behavior within your `@AppFunction` methods rather than creating redundant abstraction layers around the OS service.
|
||||
Don't attempt to make an `AppFunction` class or method OS-agnostic---AppFunctions
|
||||
are inherently part of the Android platform integration through the
|
||||
`androidx.appfunctions` package. For architectural cleanliness, use existing
|
||||
application functionality, such as existing repositories, use cases, or domain
|
||||
orchestrators, to execute the behavior within your `@AppFunction` methods rather
|
||||
than creating redundant abstraction layers around the OS service.
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
### Consolidate service and metadata manifest declarations
|
||||
|
||||
Register the KSP-generated service declaration and `app_metadata` property inside your module manifest, for example in `src/main/AndroidManifest.xml` within the `<application>` tag:
|
||||
Register the KSP-generated service declaration and `app_metadata` property
|
||||
inside your module manifest, for example in `src/main/AndroidManifest.xml`
|
||||
within the `<application>` tag:
|
||||
|
||||
<br />
|
||||
|
||||
```xml
|
||||
<service
|
||||
@@ -178,7 +201,6 @@ Register the KSP-generated service declaration and `app_metadata` property insid
|
||||
<property
|
||||
android:name="android.app.appfunctions.app_metadata"
|
||||
android:resource="@xml/app_metadata" />
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -187,7 +209,18 @@ Register the KSP-generated service declaration and `app_metadata` property insid
|
||||
|
||||
## Verification and troubleshooting
|
||||
|
||||
1. **Clean rebuild and deploy** : `bash ./gradlew clean installDebug`
|
||||
2. **Verify AppSearch discovery / indexing** : Run the following ADB command to confirm the OS successfully discovered and indexed your functions: `bash adb shell cmd app_function list-app-functions` *If your package doesn't appear, confirm that `android.app.appfunctions.v2` matches the exact asset name generated in `assets/`.*
|
||||
1. **Clean rebuild and deploy** : `bash
|
||||
./gradlew clean installDebug`
|
||||
2. **Verify AppSearch discovery / indexing** : Run the following ADB command to
|
||||
confirm the OS successfully discovered and indexed your functions:
|
||||
`bash
|
||||
adb shell cmd app_function list-app-functions`
|
||||
*If your package doesn't appear, confirm that `android.app.appfunctions.v2`
|
||||
matches the exact asset name generated in `assets/`.*
|
||||
|
||||
3. **Verify execution using ADB** : `bash adb shell "cmd app_function execute-app-function \ --package com.example.chatapp \ --function 'com.example.chatapp.appfunctions.BaseAppFunctionService#send' \ --parameters '{\"name\": \"Alice\", \"endpointValue\": \"1\", \"messageBody\": \"Hello Alice!\"}'"`
|
||||
3. **Verify execution using ADB** :
|
||||
`bash
|
||||
adb shell "cmd app_function execute-app-function \
|
||||
--package com.example.chatapp \
|
||||
--function 'com.example.chatapp.appfunctions.BaseAppFunctionService#send' \
|
||||
--parameters '{\"name\": \"Alice\", \"endpointValue\": \"1\", \"messageBody\": \"Hello Alice!\"}'"`
|
||||
@@ -0,0 +1,340 @@
|
||||
---
|
||||
name: restore-credentials
|
||||
description: Provides knowledge and workflows to implement Android's Restore Credentials
|
||||
feature using the androidx.credentials library. Use this skill to create, sign in
|
||||
with, and delete restore keys, enabling silent user sign-in on new devices after
|
||||
a restore. It covers version compatibility, dependencies, server-side prerequisites,
|
||||
and the complete client-side implementation for creating, retrieving, and clearing
|
||||
restore keys.
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-21'
|
||||
keywords:
|
||||
- Credential Manager
|
||||
- Restore Credentials
|
||||
- backup & restore
|
||||
- backup
|
||||
- restore
|
||||
- implementation
|
||||
---
|
||||
|
||||
## Fundamentals
|
||||
|
||||
The objective is to implement the **Restore Credentials** feature through the
|
||||
Android Credential Manager API (`androidx.credentials`). This allows apps that
|
||||
use or are integrating Credential Manager to silently log users back in when
|
||||
they restore their app on a new device. Restore Credentials operates
|
||||
independently of the app's primary authentication method (passwords, passkeys,
|
||||
federated sign-in) and requires no UI changes to existing sign-in flows.
|
||||
|
||||
### Scope
|
||||
|
||||
**Crucial:** This skill focuses exclusively on the Android client-side
|
||||
integration. It does **not** implement the server-side cryptographic
|
||||
validation logic. The developer must be reminded of this and the
|
||||
[Points to inform the developer about](skill.md) after implementation is done.
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
When instructed to implement Restore Credentials on a developer's application,
|
||||
remember the following:
|
||||
|
||||
1. Before the implementation, you **MUST** read and understand the [Two-Tier
|
||||
Restoration Architecture](skill.md) and review the [DOs and DON'Ts](skill.md).
|
||||
2. After the implementation, you **MUST** present the developer with the [Backend Guidelines](skill.md) as a reminder for their backend setup. It is important that you remind the developer that they still have to implement the backend.
|
||||
|
||||
## Two-Tier Restoration Architecture
|
||||
|
||||
To enable a resilient sign-in experience, retrieve credentials through a
|
||||
**two-tier architecture**:
|
||||
|
||||
1. **Tier 1 (Primary - Background):** Executes automatically during device setup using the app's `BackupAgent.onRestoreFinished()` callback. This provides an invisible restoration before the user opens the app for the first time, allowing background sync and notification delivery.
|
||||
2. **Tier 2 (Secondary - Foreground):** Runs in the Launcher `Activity.onCreate()` to catch failovers if background restoration didn't complete (example: dropped network, delayed restoration) or if `allowBackup` is disabled.
|
||||
|
||||
If `allowBackup` in the manifest is set to true, implement both. Otherwise, only
|
||||
implement tier 2 (Foreground Restoration). Do **NOT** change the value of
|
||||
`allowBackup` in the manifest.
|
||||
|
||||
## DOs and DON'Ts
|
||||
|
||||
**DO:**
|
||||
|
||||
- Do check `AndroidManifest.xml` for the value of allowBackup to determine what you have to implement.
|
||||
- Do implement a fallback for createCredential: always try calling it first with `isCloudBackupEnabled` set to true. If an `E2eeUnavailableException` is thrown, catch it and retry the call with `isCloudBackupEnabled` set to `false`.
|
||||
- Do implement a `BackupAgent` (subclass of `android.app.backup.BackupAgent`) if `allowBackup` is true in the manifest.
|
||||
- Call `clearCredentialState()` when the user signs out. This is a mandatory security measure to log the user out fully.
|
||||
- Do attempt to get the restore key on the first launch of the app on a new device and also within the `BackupAgent.onRestoreFinished()` callback if your app uses it.
|
||||
- Do ensure that a restore credential is created even if the user is already logged in.
|
||||
- Do ensure that the credential retrieval and login in `onRestoreFinished()` is performed synchronously (for example using `runBlocking`).
|
||||
- Do restore notifications in the `BackupAgent` if your app uses them. (For example capture and send FCM token to backend)
|
||||
- Do ensure that if you implement mock network requests or stubs, you replace all placeholders with valid, properly formatted JSON payloads for the credential requests.
|
||||
- Do encapsulate credential creation and retrieval into their own dedicated functions. Because credential creation must be called in multiple places (sign-up, sign-in) and retrieval across multiple tiers (`BackupAgent` and Launcher `Activity`), this prevents code duplication.
|
||||
- Do remind the developer of the [critical guidelines](skill.md) for implementing the backend once you're done with the implementation.
|
||||
- Do generate a separate restore key for each application if the organization has multiple apps with different package names, as a restore key is tied to a unique application package name.
|
||||
|
||||
**DON'T:**
|
||||
|
||||
- DON'T change the value of `allowBackup` in `AndroidManifest.xml`. Restore Credentials functionality is not affected by the allowBackup setting, meaning the user will still be automatically logged in when a Restore Credential exists, even if `allowBackup` is false.
|
||||
- DON'T implement a `BackupAgent` if `allowBackup` is `false` in `AndroidManifest.xml`.
|
||||
- DON'T assume the credential stored in the `GetCredentialResponse` to be of type `PublicKeyCredential`. It has type `RestoreCredential`.
|
||||
- DON'T chain `GetRestoreCredentialOption` with any other `CredentialOption` in the construction of a `GetCredentialRequest`.
|
||||
- DON'T assume `CredentialManager` or the Android system will automatically delete a restore key when a user signs out of the app. You must explicitly call `clearCredentialState` with a `ClearCredentialStateRequest` of `TYPE_CLEAR_RESTORE_CREDENTIAL`.
|
||||
- DON'T remove any existing calls to `clearCredentialState()`. A `ClearCredentialStateRequest` without a type specified only clears all NON-restore credentials.
|
||||
|
||||
## Implementation Guide
|
||||
|
||||
Implement the Android client-side code by using the following guide. Follow it
|
||||
**step-by-step** and don't implement any backend functionality, only remind
|
||||
the user of the [Backend Guidelines](skill.md) once you're done.
|
||||
|
||||
## Version compatibility
|
||||
|
||||
Credential Manager's Restore Credentials works on devices running Android 9 and
|
||||
higher, Google Play services (GMS) core version 24220000 or higher, and version
|
||||
1.5.0 or higher of the `androidx.credentials` library.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Set up a [relying party server](skill.md) similar to the server for [passkeys](skill.md). If
|
||||
you already have a [server](skill.md) set up to handle authentication with passkeys,
|
||||
use the same server-side implementation for restore keys.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** While the server-side implementation is the same for passkeys and restore keys, your client-side app can support restore keys without supporting passkeys. Because restore keys work independently of the authentication method in your app (for example, passwords or Sign in with Google), you don't need to make any additional changes to the existing authentication methods in your app's code.
|
||||
|
||||
## Dependencies
|
||||
|
||||
Add the following dependencies to your app module's `build.gradle` file:
|
||||
|
||||
### Kotlin
|
||||
|
||||
```kotlin
|
||||
dependencies {
|
||||
implementation("androidx.credentials:credentials:1.7.0-alpha03")
|
||||
implementation("androidx.credentials:credentials-play-services-auth:1.7.0-alpha03")
|
||||
}
|
||||
```
|
||||
|
||||
### Groovy
|
||||
|
||||
```groovy
|
||||
dependencies {
|
||||
implementation "androidx.credentials:credentials:1.7.0-alpha03"
|
||||
implementation "androidx.credentials:credentials-play-services-auth:1.7.0-alpha03"
|
||||
}
|
||||
```
|
||||
|
||||
Restore Credentials is available from version 1.5.0 and higher of the
|
||||
androidx.credentials library. However, it's recommended to use the latest stable
|
||||
versions of the dependencies where possible.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The Restore Credentials feature works regardless of whether [`allowBackup`](references/android/guide/topics/manifest/application-element.md) is set in the `manifest`.
|
||||
|
||||
## Overview
|
||||
|
||||
1. [**Create a restore key**](skill.md): To create a restore key, complete the following steps:
|
||||
1. [**Instantiate Credential Manager**](skill.md): Create a `CredentialManager` object.
|
||||
2. [**Get credential creation options from the app server**](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API): Send the client app the details required to create the restore key from your app server.
|
||||
3. [**Create the restore key**](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson): Create a restore key for the user's account if the user is signed in to your app.
|
||||
4. [**Handle the credential creation response**](https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptionsjson): Send the credentials from your client app to your app server for processing, and handle any exceptions.
|
||||
2. [**Sign in with a restore key**](skill.md): To sign in with a restore key, complete the following steps:
|
||||
1. [**Get credential retrieval options from the app server**](skill.md): Send the client app the details required to retrieve the restore key from your app server.
|
||||
2. [**Get the restore key**](skill.md): Request the restore key from Credential Manager when the user sets up a new device. This lets the user sign in without additional input.
|
||||
3. [**Handle the credential retrieval response**](skill.md): Send the restore key from the client app to the app server to sign in the user.
|
||||
3. [**Delete a restore key**](skill.md).
|
||||
|
||||
## Create a restore key
|
||||
|
||||
Your app should cover all cases of a user signing in to ensure active users have
|
||||
a restore key created. Create the restore key in the following scenarios:
|
||||
|
||||
- If the user is signed in and a restore key isn't already created (such as in the `onCreate` method for the main `Activity`).
|
||||
- When the user is signing in or completing a new account registration flow.
|
||||
|
||||
To optimize performance and avoid the overhead of creating or checking for a
|
||||
restore credential on every single login, set a `boolean` flag or a credential
|
||||
creation timestamp in local storage, such as `has_synced_restore_credential`, to
|
||||
track whether the key has already been created.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** A restore key is tied to an application's unique package name. If your organization's main app and sub-apps have different package names, create a separate restore key for each app.
|
||||
|
||||
### Instantiate Credential Manager
|
||||
|
||||
Use your app's activity context to instantiate a `CredentialManager` object.
|
||||
|
||||
// Use your app or activity context to instantiate a client instance of
|
||||
// CredentialManager.
|
||||
private val credentialManager = CredentialManager.create(context)
|
||||
|
||||
### Get credential creation options from your app server
|
||||
|
||||
Use a FIDO-compliant library in your app server to send your client app the
|
||||
information required to create the restore credential, such as information about
|
||||
the user, the app, and additional configuration properties. For more information
|
||||
about the server-side implementation, see [Server-side
|
||||
guidance](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
|
||||
### Create the restore key
|
||||
|
||||
After parsing the public key creation options sent by the server, create a
|
||||
restore key by wrapping these options in a
|
||||
[`CreateRestoreCredentialRequest`](https://developer.android.com/reference/androidx/credentials/CreateRestoreCredentialRequest) object and calling the
|
||||
[`createCredential()`](https://developer.android.com/reference/androidx/credentials/CredentialManager#createCredential(android.content.Context,androidx.credentials.CreateCredentialRequest)) method with the `CredentialManager` object.
|
||||
|
||||
// createRestoreRequest contains the details sent by the server
|
||||
val response = credentialManager.createCredential(context, createRestoreRequest)
|
||||
|
||||
#### Key points about the code
|
||||
|
||||
- The `CreateRestoreCredentialRequest` object contains the following fields:
|
||||
|
||||
- `requestJson`: The credential creation options sent by the app server in the [Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) format for [`PublicKeyCredentialCreationOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson).
|
||||
- `isCloudBackupEnabled`: `Boolean` field to determine if the restore key
|
||||
should be backed up to the cloud. By default, this flag is `true`. This
|
||||
field has these values:
|
||||
|
||||
- `true`: (**Recommended**) This value enables the backup of restore keys to the cloud if the user has Google Backup and end-to-end encryption, such as a screen lock, enabled.
|
||||
- `false`: This value saves the key locally and not in the cloud. The key is not available on the new device if the user chooses to restore from the cloud.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Caution:** It is recommended to set `isCloudBackupEnabled` to `true`. If cloud backup is disabled and the user restores from a cloud backup, the call to retrieve the restore key fails. Users who restore your app with a cloud backup don't receive the restore key and are not automatically signed in.
|
||||
|
||||
### Handle the credential creation response
|
||||
|
||||
The Credential Manager API returns a response of type
|
||||
[`CreateRestoreCredentialResponse`](https://developer.android.com/reference/androidx/credentials/CreateRestoreCredentialResponse). This response holds the public key
|
||||
credential registration response in [JSON format](https://w3c.github.io/webauthn/#authenticatorattestationresponse).
|
||||
|
||||
Send the public key from your app to the relying party server. This public key
|
||||
is similar to the public key generated when you create a passkey. The same code
|
||||
that handles passkey creation on the server can also handle restore key
|
||||
creation. For more information about the server-side implementation, see [the
|
||||
guidance for passkeys](references/android/identity/passkeys/create-passkeys.md).
|
||||
|
||||
During the restore key creation process, handle these exceptions:
|
||||
|
||||
- [`CreateRestoreCredentialDomException`](https://developer.android.com/reference/androidx/credentials/exceptions/restorecredential/CreateRestoreCredentialDomException): This exception occurs if `requestJson` is invalid and does not follow the WebAuthn format for [`PublicKeyCredentialCreationOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson).
|
||||
- [`E2eeUnavailableException`](https://developer.android.com/reference/androidx/credentials/exceptions/restorecredential/E2eeUnavailableException): This exception occurs if `isCloudBackupEnabled` is `true`, but the user's device does not have data backup or end-to-end encryption, such as a screen lock.
|
||||
To ensure that Restore Credentials are created in all cases, you must handle the `E2eeUnavailableException` explicitly by calling `createCredential` with `isCloudBackupEnabled` set to `true`. If `E2eeUnavailableException` is thrown, catch and call `createCredential` again with `isCloudBackupEnabled` set to `false`.
|
||||
- `IllegalArgumentException`: This exception occurs if `createRestoreRequest` is empty or not valid JSON, or if it does not have a valid `user.id` that conforms to the WebAuthn [specifications](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson).
|
||||
|
||||
## Sign in with a restore key
|
||||
|
||||
Use Restore Credentials to silently sign in the user during the device setup
|
||||
process.
|
||||
|
||||
### Get credential retrieval options from the app server
|
||||
|
||||
Send the client app the options required to get the restore key from the server.
|
||||
For similar passkey guidance for this step, see [Sign in with a passkey](references/android/identity/passkeys/sign-in-with-passkeys.md).
|
||||
For more information about the server-side implementation, see the [server-side
|
||||
authentication guide](https://developers.google.com/identity/passkeys/developer-guides/server-authentication#create_credential_request_options).
|
||||
|
||||
### Get the restore key
|
||||
|
||||
To get the restore key on the new device, call the `getCredential()` method on
|
||||
the `CredentialManager` object.
|
||||
|
||||
It is recommended to fetch the restore key in both of the following scenarios:
|
||||
|
||||
- On the first launch of the app on the device. Credential restoration in this scenario is independent of restoration of the app data.
|
||||
- If app data backup and restore is enabled, get the restore key immediately after the app data is restored. Use [`BackupAgent`](https://developer.android.com/reference/android/app/backup/BackupAgent) to configure your app's backup and ensure you complete the `getCredential` functionality within the [`onRestoreFinished`](https://developer.android.com/reference/android/app/backup/BackupAgent#onRestoreFinished()) callback. Don't use the `onRestore` method, as it is only called for key-value backups, whereas `onRestoreFinished` is reliably called for any kind of backup restore. This avoids potential delays when users open their new device for the first time and lets users interact with the app without waiting for them to open your app. For example, this lets your app send the user notifications before they open the app for the first time on the new device, which is particularly relevant for messaging or communications apps.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> **Important:** Notifications aren't automatically restored after the restore credentials are retrieved. If you use Firebase to handle notifications, you must fetch and send the Firebase Cloud Messaging (FCM) token to the backend to successfully resume background messaging and notifications.
|
||||
|
||||
// Fetch the options required to get the restore key
|
||||
val authenticationJson = fetchAuthenticationJson()
|
||||
|
||||
// Create the GetRestoreCredentialRequest object
|
||||
val options = GetRestoreCredentialOption(authenticationJson)
|
||||
val getRequest = GetCredentialRequest(listOf(options))
|
||||
|
||||
val response = credentialManager.getCredential(context, getRequest)
|
||||
|
||||
// Type-check and extract the restore credential
|
||||
val credential = response.credential as RestoreCredential
|
||||
|
||||
The credential manager APIs return a response of type
|
||||
[`GetCredentialResponse`](https://developer.android.com/reference/android/credentials/GetCredentialResponse). The credential contained in this response is
|
||||
explicitly of type `RestoreCredential`, which holds the public key.
|
||||
|
||||
### Handle the sign-in response
|
||||
|
||||
Send the public key from the app to the relying party server, which can then be
|
||||
used to sign in the user. On the server side, this action is similar to signing
|
||||
in using a passkey. The same code that handles sign-in with passkeys on the
|
||||
server can also handle sign-ins with restore keys. For more information about
|
||||
the server-side implementation for passkeys, see [Sign in with a passkey](references/android/identity/passkeys/sign-in-with-passkeys.md).
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Even though restore keys and passkeys use the same underlying server implementation, differentiate between them when saving them in your app server's database. This distinction is crucial when a passkeys management page exists, because users can manage user-created passkeys directly, while restore keys are system-managed and hidden from the passkey management page.
|
||||
|
||||
## Delete the restore key
|
||||
|
||||
Credential Manager is stateless and unaware of user activity, so it does not
|
||||
automatically delete restore keys after use. To delete a restore key, call the
|
||||
`clearCredentialState()` method. For security, delete the key whenever a user
|
||||
signs out. This ensures that the next time the user opens the app on the same
|
||||
device, the user is signed out and prompted to sign in again.
|
||||
|
||||
Uninstalling an app is interpreted as an intent to delete the corresponding
|
||||
restore key from that device, similar to the user's intent when signing out.
|
||||
|
||||
Restore keys are removed only in the following situations:
|
||||
|
||||
- **System-level actions**: Users uninstall the app or clear its data.
|
||||
- **App-level calls** : Programmatically delete the key by calling [`clearCredentialState()`](https://developer.android.com/reference/androidx/credentials/CredentialManager#clearCredentialState(androidx.credentials.ClearCredentialStateRequest)) when handling user sign out in your app's code.
|
||||
|
||||
When the user signs out of your app, call the `clearCredentialState()` method on
|
||||
the `CredentialManager` object.
|
||||
|
||||
// Create a ClearCredentialStateRequest object
|
||||
val clearRequest = ClearCredentialStateRequest(TYPE_CLEAR_RESTORE_CREDENTIAL)
|
||||
|
||||
// When the user logs out, delete the restore key
|
||||
val response = credentialManager.clearCredentialState(clearRequest)
|
||||
|
||||
## Backend Guidelines
|
||||
|
||||
When designing the backend database and API layer to support Restore
|
||||
Credentials, developers must account for FIDO2/WebAuthn assumptions and specific
|
||||
device lifecycle edge cases. Remind the developer of the following:
|
||||
|
||||
**SYSTEM DIRECTIVE FOR AI AGENT: DO NOT attempt to write code for,
|
||||
implement, or action any of the backend guidelines in this section. Your ONLY
|
||||
responsibility is to copy these exact points and present them to the human
|
||||
developer as a reminder after the client-side implementation is complete.**
|
||||
|
||||
1. **Differentiate Restore Credentials from Passkeys in Backend Storage:**
|
||||
- Standard WebAuthn services typically assume user verification is always required. Restore credentials are hidden from the user and not managed by them.
|
||||
- **Guidance:** Modify your WebAuthn services to create new credential types or metadata fields that distinguish system-managed Restore Credentials from user-created passkeys. Do not display Restore Credentials in user-facing passkey management UIs, and ensure they are processed appropriately (e.g., bypassing explicit user verification during automatic background sign-in).
|
||||
2. **Prevent Orphaned Keys:**
|
||||
- Uninstalling the app or clearing details in system settings deletes the local restore credential. Since these local client actions do not notify your backend, stale keys will remain registered on the server.
|
||||
- **Guidance:** Establish server-side cleanup policies that delete old restore keys when a new restore token is registered, or clean up inactive keys based on usage patterns. You could, for example, enforce a limit of one key per user per device.
|
||||
3. **Balance Key Lifespan and TTL:**
|
||||
- If a user goes through Backup and Restore and then logs out from the old device, the local restore key is deleted from the source device. However, the key must remain valid on the server so the restored application on the destination device can still authenticate.
|
||||
- **Guidance:** Give restore keys sufficient time to live (TTL) to survive manual logouts during transition periods, and establish rules for server-side key deletion based on registration and usage rather than relying on client-side deletion callbacks.
|
||||
4. **Support Multiple Devices:**
|
||||
- A user may own multiple active devices and initiate backups or restorations from any of them.
|
||||
- **Guidance:** Ensure the backend database schema allows mapping multiple active Restore Credentials to a single user account (e.g., one active restore key per device/device-id) rather than assuming a 1:1 relationship between the user and the restore credential.
|
||||
|
||||
## References
|
||||
|
||||
- **WebAuthentication API (WebAuthn) Documentation \& Specification**
|
||||
*When to use:* Use these resources ONLY if you need to inspect or debug the
|
||||
strict JSON schema requirements for FIDO2/WebAuthn, specifically when
|
||||
generating mock data or formatting the `requestJson`
|
||||
(`PublicKeyCredentialCreationOptionsJSON`) and `authenticationJson` payloads.
|
||||
|
||||
- [MDN Web Authentication API Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API): Mozilla Developer Network
|
||||
guide and reference for WebAuthn APIs
|
||||
|
||||
- [W3C `PublicKeyCredentialCreationOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson): Data structure definition
|
||||
for WebAuthn credential creation requests in JSON format.
|
||||
|
||||
- [W3C `PublicKeyCredentialRequestOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptionsjson): Data structure definition
|
||||
for WebAuthn authentication or assertion requests in JSON format.
|
||||
+832
@@ -0,0 +1,832 @@
|
||||
syntax:
|
||||
:
|
||||
|
||||
```xml
|
||||
<application android:allowTaskReparenting=["true" | "false"]
|
||||
android:allowBackup=["true" | "false"]
|
||||
android:allowClearUserData=["true" | "false"]
|
||||
android:allowCrossUidActivitySwitchFromBelow=["true" | "false"]
|
||||
android:allowNativeHeapPointerTagging=["true" | "false"]
|
||||
android:appCategory=["accessibility" | "audio" | "game" |
|
||||
"image" | "maps" | "news" | "productivity" | "social" | "video"]
|
||||
android:backupAgent="string"
|
||||
android:backupInForeground=["true" | "false"]
|
||||
android:banner="drawable resource"
|
||||
android:dataExtractionRules="string resource"
|
||||
android:debuggable=["true" | "false"]
|
||||
android:description="string resource"
|
||||
android:enabled=["true" | "false"]
|
||||
android:enableOnBackInvokedCallback=["true" | "false"]
|
||||
android:extractNativeLibs=["true" | "false"]
|
||||
android:forceQueryable=["true" | "false"]
|
||||
android:fullBackupContent="string"
|
||||
android:fullBackupOnly=["true" | "false"]
|
||||
android:gwpAsanMode=["always" | "never"]
|
||||
android:hasCode=["true" | "false"]
|
||||
android:hasFragileUserData=["true" | "false"]
|
||||
android:hardwareAccelerated=["true" | "false"]
|
||||
android:icon="drawable resource"
|
||||
android:intentMatchingFlags=["none" | "enforceIntentFilter" | "allowNullAction"]
|
||||
android:isGame=["true" | "false"]
|
||||
android:isMonitoringTool=["parental_control" | "enterprise_management" |
|
||||
"other"]
|
||||
android:killAfterRestore=["true" | "false"]
|
||||
android:largeHeap=["true" | "false"]
|
||||
android:label="string resource"
|
||||
android:localeConfig="xml resource"
|
||||
android:logo="drawable resource"
|
||||
android:manageSpaceActivity="string"
|
||||
android:name="string"
|
||||
android:networkSecurityConfig="xml resource"
|
||||
android:pageSizeCompat=["true" | "false"]
|
||||
android:permission="string"
|
||||
android:persistent=["true" | "false"]
|
||||
android:process="string"
|
||||
android:restoreAnyVersion=["true" | "false"]
|
||||
android:requestLegacyExternalStorage=["true" | "false"]
|
||||
android:requiredAccountType="string"
|
||||
android:resizeableActivity=["true" | "false"]
|
||||
android:restrictedAccountType="string"
|
||||
android:supportsRtl=["true" | "false"]
|
||||
android:taskAffinity="string"
|
||||
android:testOnly=["true" | "false"]
|
||||
android:theme="resource or theme"
|
||||
android:uiOptions=["none" | "splitActionBarWhenNarrow"]
|
||||
android:usesCleartextTraffic=["true" | "false"]
|
||||
android:vmSafeMode=["true" | "false"] >
|
||||
. . .
|
||||
</application>
|
||||
```
|
||||
|
||||
contained in:
|
||||
: `https://developer.android.com/guide/topics/manifest/manifest-element`
|
||||
|
||||
can contain:
|
||||
: `https://developer.android.com/guide/topics/manifest/activity-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/activity-alias-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/meta-data-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/service-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/receiver-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/profileable-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/provider-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/uses-library-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/uses-native-library-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/property-element`
|
||||
|
||||
description:
|
||||
|
||||
: The declaration of the application. This element contains subelements
|
||||
that declare each of the application's components and has attributes
|
||||
that can affect all the components.
|
||||
|
||||
Many of these attributes, such as
|
||||
`icon`, `label`, `permission`, `process`,
|
||||
`taskAffinity`, and `allowTaskReparenting`, set default values
|
||||
for corresponding attributes of the component elements. Others, such as
|
||||
`debuggable`, `enabled`, `description`, and
|
||||
`allowClearUserData`, set values for the application as a whole and
|
||||
aren't overridden by the components.
|
||||
|
||||
attributes
|
||||
:
|
||||
|
||||
`android:allowTaskReparenting`
|
||||
: Whether activities that the application defines can move from
|
||||
the task that started them to the task they have an affinity for when that task
|
||||
is next brought to the front. It's `"true"` if they can move, and
|
||||
`"false"` if they must remain with the task where they started.
|
||||
The default value is `"false"`.
|
||||
|
||||
|
||||
The
|
||||
`https://developer.android.com/guide/topics/manifest/activity-element`
|
||||
element has its own
|
||||
`https://developer.android.com/guide/topics/manifest/activity-element#reparent`
|
||||
attribute that can override the value set here.
|
||||
|
||||
`android:allowBackup`
|
||||
|
||||
: Whether to let the application participate in the backup
|
||||
and restore infrastructure. If this attribute is set to `"false"`, no
|
||||
backup or restore of the application is ever performed, disabling all cloud backups
|
||||
and device-to-device (D2D) transfers, even by a full-system backup that otherwise
|
||||
causes all application data to save using `adb`. The default value of this
|
||||
attribute is `"true"`. If your app processes sensitive data, you can keep
|
||||
this attribute set to `"true"` and configure
|
||||
[`android:dataExtractionRules`](https://developer.android.com/guide/topics/manifest/application-element#dataExtractionRules) to safely
|
||||
exclude sensitive keys or temporary caches while preserving user preferences and
|
||||
continuity.
|
||||
|
||||
**Note:**For apps targeting Android 12 (API level 31) or higher, this behavior
|
||||
varies. On devices from some device manufacturers, you can't disable device-to-device migration
|
||||
of your app's files.
|
||||
|
||||
However, you can disable cloud-based backup and restore of your app's files by setting
|
||||
this attribute to `"false"`, even if your app targets Android 12 (API level 31) or
|
||||
higher.
|
||||
|
||||
|
||||
For more information, see the
|
||||
[backup and restore](https://developer.android.com/about/versions/12/behavior-changes-12#backup-restore) section
|
||||
of the page that describes behavior changes for apps targeting Android 12 (API level 31) or
|
||||
higher.
|
||||
|
||||
`android:allowClearUserData`
|
||||
|
||||
: Whether to let the application reset user data. This data includes
|
||||
flags, such as whether the user has seen introductory tooltips, as
|
||||
well as user-customizable settings and preferences. The default value of this
|
||||
attribute is `"true"`.
|
||||
|
||||
**Note:** Only apps that are part of the system image can
|
||||
declare this attribute explicitly. Third-party apps can't include this
|
||||
attribute in their manifest files.
|
||||
|
||||
For more information, see [Data backup overview](https://developer.android.com/guide/topics/data/backup).
|
||||
|
||||
`android:allowCrossUidActivitySwitchFromBelow`
|
||||
|
||||
: Specifies whether activities from other applications in the same task
|
||||
can be launched on top of this application. If set to `"false"`,
|
||||
activity launches that would replace this application in the user's view
|
||||
are blocked.
|
||||
|
||||
The default value is `"true"`.
|
||||
|
||||
For more information, see the guide to
|
||||
[Secure Background Activity Launches](https://developer.android.com/guide/components/activities/secure-bal).
|
||||
|
||||
`android:allowNativeHeapPointerTagging`
|
||||
|
||||
: Whether the app enables the Heap pointer tagging feature. The default value of
|
||||
this attribute is `"true"`.
|
||||
|
||||
**Note:** Disabling this feature **doesn't** address the
|
||||
underlying code health issue. Future hardware devices might not support this manifest tag.
|
||||
|
||||
For more information, see [Tagged Pointers](https://source.android.com/devices/tech/debug/tagged-pointers).
|
||||
|
||||
`android:appCategory`
|
||||
|
||||
: Declares the category of this app. Categories are used to cluster multiple apps
|
||||
together into meaningful groups, such as when summarizing battery, network, or
|
||||
disk usage. Only define this value for apps that fit well into one of
|
||||
the specific categories.
|
||||
|
||||
Must be one of the following constant values.
|
||||
|
||||
| Value | Description |
|
||||
|---|---|
|
||||
| `accessibility` | Apps that are primarily accessibility apps, such as screen-readers. |
|
||||
| `audio` | Apps that primarily work with audio or music, such as music players. |
|
||||
| `game` | Apps that are primarily games. |
|
||||
| `image` | Apps that primarily work with images or photos, such as camera or gallery apps. |
|
||||
| `maps` | Apps that are primarily map apps, such as navigation apps. |
|
||||
| `news` | Apps that are primarily news apps, such as newspapers, magazines, or sports apps. |
|
||||
| `productivity` | Apps that are primarily productivity apps, such as cloud storage or workplace apps. |
|
||||
| `social` | Apps that are primarily social apps, such as messaging, communication, email, or social network apps. |
|
||||
| `video` | Apps that primarily work with video or movies, such as streaming video apps. |
|
||||
|
||||
|
||||
`android:backupAgent`
|
||||
: The name of the class that implements the application's backup agent,
|
||||
a subclass of `https://developer.android.com/reference/android/app/backup/BackupAgent`. The attribute value is
|
||||
a fully qualified class name, such as `"com.example.project.MyBackupAgent"`.
|
||||
However, as a shorthand, if the first character of the name is a period,
|
||||
for example, `".MyBackupAgent"`, it is appended to the
|
||||
package name specified in the
|
||||
`https://developer.android.com/guide/topics/manifest/manifest-element`
|
||||
element.
|
||||
|
||||
|
||||
There is no default. The name must be specific.
|
||||
|
||||
`android:backupInForeground`
|
||||
: Indicates that
|
||||
[Auto Backup](https://developer.android.com/guide/topics/data/autobackup) operations
|
||||
can be performed on this app even if the app is in a foreground-equivalent
|
||||
state. The system shuts down an app during auto backup operation,
|
||||
so use this attribute with caution. Setting this flag to `"true"` can impact app
|
||||
behavior while the app is active.
|
||||
|
||||
The default value is `"false"`, which means that the OS avoids
|
||||
backing up the app while it's running in the foreground, such as a music app
|
||||
that is actively playing music using a service in the
|
||||
`https://developer.android.com/reference/android/app/Service#startForeground(int, android.app.Notification)` state.
|
||||
|
||||
`android:banner`
|
||||
: A [drawable resource](https://developer.android.com/guide/topics/resources/drawable-resource)
|
||||
providing an extended graphical banner for its associated item. Use with the
|
||||
`<application>` tag to supply a default banner for all application activities or with the
|
||||
[`<activity>`](https://developer.android.com/guide/topics/manifest/activity-element)
|
||||
tag to supply a banner for a specific activity.
|
||||
|
||||
The system uses the banner to represent an app in
|
||||
the Android TV home screen. Therefore, only specify this for applications with an activity that handles the
|
||||
`https://developer.android.com/reference/android/content/Intent#CATEGORY_LEANBACK_LAUNCHER` intent.
|
||||
|
||||
|
||||
This attribute is set as a reference to a drawable resource containing
|
||||
the image, for example `"@drawable/banner"`. There is no default banner.
|
||||
|
||||
|
||||
For more information, see [Provide a home screen banner](https://developer.android.com/training/tv/start/start#banner).
|
||||
|
||||
`android:dataExtractionRules`
|
||||
|
||||
:
|
||||
Applications can set this attribute to an XML resource where they specify the
|
||||
rules determining which files and directories can be copied from the device as part of backup or
|
||||
transfer operations.
|
||||
|
||||
|
||||
For information about the format of the XML file, see [Backup and restore](https://developer.android.com/about/versions/12/behavior-changes-12#backup-restore).
|
||||
|
||||
`android:debuggable`
|
||||
: Whether the application can be debugged, even when running
|
||||
on a device in user mode. It's `"true"` if it can be and `"false"`
|
||||
if not. The default value is `"false"`.
|
||||
|
||||
`android:description`
|
||||
: User-readable text about the application, which is longer and more descriptive than the application label.
|
||||
The value is set as a reference to a string resource. Unlike the label, it can't be a raw string.
|
||||
There is no default value.
|
||||
|
||||
`android:enabled`
|
||||
: Whether the Android system can instantiate components of
|
||||
the application. It's `"true"` if it can and `"false"`
|
||||
if not. If the value is `"true"`, each component's
|
||||
`enabled` attribute determines whether that component is enabled.
|
||||
If the value is `"false"`, it overrides the
|
||||
component-specific values, and all components are disabled.
|
||||
|
||||
|
||||
The default value is `"true"`.
|
||||
|
||||
`android:enableOnBackInvokedCallback`
|
||||
|
||||
: This flag lets you opt out of predictive system animations at the app level.
|
||||
|
||||
|
||||
Set `android:enableOnBackInvokedCallback=false` to turn off predictive back animations at the app level
|
||||
and instruct the system to ignore calls to the `OnBackInvokedCallback` platform API.
|
||||
|
||||
`android:extractNativeLibs`
|
||||
: This attribute indicates whether the package installer extracts native libraries from the
|
||||
APK to the file system. If set to `"false"`, your native libraries are stored
|
||||
uncompressed in the APK. Although your APK might be larger, your application loads faster
|
||||
because the libraries load directly from the APK at runtime.
|
||||
|
||||
|
||||
The default value of `extractNativeLibs` depends on `minSdkVersion` and the
|
||||
version of AGP you're using. In most cases, the default behavior is probably what you want, and
|
||||
you don't have to set this attribute explicitly.
|
||||
|
||||
`android:forceQueryable`
|
||||
|
||||
: Specifies whether this application is visible to all other applications
|
||||
on the device, regardless of what those other applications declare in the
|
||||
`<queries>` tags in their manifests.
|
||||
|
||||
The default value is `"false"`.
|
||||
|
||||
For more information, see the guide on
|
||||
[automatic package visibility filtering](https://developer.android.com/training/package-visibility/automatic).
|
||||
|
||||
`android:fullBackupContent`
|
||||
: This attribute points to an XML file that contains full backup rules for
|
||||
[Auto Backup](https://developer.android.com/guide/topics/data/autobackup).
|
||||
These rules determine what files get backed up. For more information, see the
|
||||
[XML config syntax](https://developer.android.com/guide/topics/data/autobackup#XMLSyntax)
|
||||
for Auto Backup.
|
||||
|
||||
|
||||
This attribute is optional. If it is not specified, by default, Auto Backup
|
||||
includes most of your app's files. For more information, see
|
||||
[Files that are backed up](https://developer.android.com/guide/topics/data/autobackup#Files).
|
||||
|
||||
`android:fullBackupOnly`
|
||||
: This attribute indicates whether to use
|
||||
[Auto Backup](https://developer.android.com/guide/topics/data/autobackup) on devices
|
||||
where it is available. If set to `"true"`, then your app performs
|
||||
Auto Backup when installed on a device running Android 6.0 (API level 23) or
|
||||
higher. On older devices, your app ignores this attribute and performs
|
||||
[key/value backups](https://developer.android.com/guide/topics/data/keyvaluebackup).
|
||||
|
||||
|
||||
The default value is `"false"`.
|
||||
|
||||
`android:gwpAsanMode`
|
||||
: This attribute indicates whether to use
|
||||
[GWP-ASan](https://developer.android.com/ndk/guides/gwp-asan), a native memory allocator feature that helps
|
||||
find use-after-free and heap-buffer-overflow bugs.
|
||||
|
||||
|
||||
The default value is `"never"`.
|
||||
|
||||
`android:hasCode`
|
||||
: Whether the application contains any DEX code---that is, code using the
|
||||
Kotlin or Java programming language.
|
||||
It's `"true"` if it does and `"false"` if not. When the
|
||||
value is `"false"`, the system doesn't try to load any application
|
||||
code when launching components. The default value is `"true"`.
|
||||
|
||||
|
||||
If the application includes native (C/C++) code, but no DEX code, this should
|
||||
be set to `"false"`. If set to `"true"` when the APK
|
||||
contains no DEX code, the app may fail to load.
|
||||
|
||||
|
||||
**This property must account for code included in the application by
|
||||
dependencies.** If the application depends on an AAR that uses
|
||||
Java/Kotlin code, or directly on a JAR, `app:hasCode` must be
|
||||
`"true"`, or omitted as that is the default.
|
||||
|
||||
|
||||
For example, your app might support
|
||||
[Play feature delivery](https://developer.android.com/platform/technology/app-bundle) and include feature
|
||||
modules that don't generate any DEX files, which is bytecode optimized for the Android
|
||||
platform. If so, you need to set this property to `"false"` in the module's manifest
|
||||
file to avoid runtime errors.
|
||||
|
||||
`android:hasFragileUserData`
|
||||
: Whether to show the user a prompt to
|
||||
keep the app's data when the user uninstalls the app. The default value is `"false"`.
|
||||
|
||||
`android:hardwareAccelerated`
|
||||
: Whether hardware-accelerated rendering is enabled for all
|
||||
activities and views in this application. It's `"true"` if it is
|
||||
enabled and `"false"` if not. The default value is `"true"` if you set
|
||||
either [`minSdkVersion`](https://developer.android.com/guide/topics/manifest/uses-sdk-element#min)
|
||||
or [`targetSdkVersion`](https://developer.android.com/guide/topics/manifest/uses-sdk-element#target)
|
||||
to `"14"` or higher. Otherwise, it's `"false"`.
|
||||
|
||||
Starting from Android 3.0 (API level 11), a hardware-accelerated OpenGL renderer is
|
||||
available to applications to improve performance for many common 2D graphics
|
||||
operations. When the hardware-accelerated renderer is enabled, most operations
|
||||
in Canvas, Paint, Xfermode, ColorFilter, Shader, and Camera are accelerated.
|
||||
|
||||
|
||||
This results in smoother animations, smoother scrolling, and improved
|
||||
responsiveness overall, even for applications that don't explicitly make use
|
||||
the framework's OpenGL libraries.
|
||||
|
||||
|
||||
Not all of the OpenGL 2D operations are accelerated. If you enable
|
||||
the hardware-accelerated renderer, test your application so that it can
|
||||
make use of the renderer without errors.
|
||||
|
||||
|
||||
For more information, read the
|
||||
[Hardware acceleration](https://developer.android.com/guide/topics/graphics/hardware-accel)
|
||||
guide.
|
||||
|
||||
`android:icon`
|
||||
: An icon for the application as whole and the default icon for
|
||||
each of the application's components. See the individual
|
||||
`icon` attributes for the
|
||||
`https://developer.android.com/guide/topics/manifest/activity-element`,
|
||||
`https://developer.android.com/guide/topics/manifest/activity-alias-element`,
|
||||
`https://developer.android.com/guide/topics/manifest/service-element`,
|
||||
`https://developer.android.com/guide/topics/manifest/receiver-element`, and
|
||||
`https://developer.android.com/guide/topics/manifest/provider-element` elements.
|
||||
|
||||
|
||||
This attribute is set as a reference to a drawable resource containing
|
||||
the image, such as `"@drawable/icon"`. There is no default icon.
|
||||
|
||||
`android:intentMatchingFlags`
|
||||
|
||||
:
|
||||
Use this attribute to fine-tune how the system matches incoming intents to app
|
||||
components. By default, no special matching rules are applied.
|
||||
|
||||
|
||||
This attribute can be specified on the `<application>` tag
|
||||
as well as on component tags, including `<activity>`,
|
||||
`<activity-alias>`, `<receiver>`,
|
||||
`<service>`, and `<provider>`. The value
|
||||
set on a component overrides the value set on the
|
||||
`<application>` tag.
|
||||
|
||||
|
||||
The value must be one or more of the following flags, separated by '`|`':
|
||||
|
||||
| Flag | Description |
|
||||
|---|---|
|
||||
| `none` | Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the `none` flag. |
|
||||
| `enforceIntentFilter` | Enforces stricter matching for incoming intents: - Explicit intents must match the target component's intent filter. - Intents without an action don't match any intent filter. |
|
||||
| `allowNullAction` | Relaxes the matching rules to allow intents without an action to match. This flag is used in conjunction with `enforceIntentFilter` to achieve the following behavior: - Explicit intents must match the target component's intent filter. - Intents without an action are allowed to match any intent filter. |
|
||||
|
||||
For more information, see the
|
||||
[Safer Intents](https://developer.android.com/about/versions/16/behavior-changes-16#safer-intents)
|
||||
section in the Android 16 (API level 36) behavior changes.
|
||||
|
||||
`android:isGame`
|
||||
: Whether the application is a game. The system might group together applications classified
|
||||
as games or display them separately from other applications. The default is `"false"`.
|
||||
|
||||
`android:isMonitoringTool`
|
||||
|
||||
: Indicates that this application is designed to monitor other individuals.
|
||||
|
||||
**Note:** If an app declares this attribute in its manifest, the developer must
|
||||
follow the
|
||||
[Stalkerware](https://support.google.com/googleplay/android-developer/answer/9888380#commercial-spyware)
|
||||
policy to publish the app to Google Play.
|
||||
|
||||
There is no default value. The developer must specify one of the following values:
|
||||
|
||||
| Value | Description |
|
||||
|---|---|
|
||||
| `"parental_control"` | App caters to parental control and is specifically targeted at parents who want to keep their kids safe. |
|
||||
| `"enterprise_management"` | App caters to enterprises that want to manage and track devices given to employees. |
|
||||
| `"other"` | App caters to a use case not otherwise specified in this table. |
|
||||
|
||||
`android:killAfterRestore`
|
||||
|
||||
: Whether the application terminates after its
|
||||
settings have been restored during a full-system restore operation.
|
||||
Single-package restore operations never cause the application to
|
||||
shut down. Full-system restore operations typically only occur once,
|
||||
when the phone is first set up. Third-party applications don't normally
|
||||
need to use this attribute.
|
||||
|
||||
The default is `"true"`, which means that after the application
|
||||
finishes processing its data during a full-system restore, it terminates.
|
||||
|
||||
`android:largeHeap`
|
||||
|
||||
: Whether the application's processes are created with a large Dalvik heap. This applies to
|
||||
all processes created for the application. It only applies to the first application loaded into a
|
||||
process. If you're using a shared user ID to let multiple applications use a process, they all
|
||||
must use this option consistently to avoid unpredictable results.
|
||||
|
||||
Most apps don't need this and instead focus on reducing their overall memory usage for
|
||||
improved performance. Enabling this also doesn't guarantee a fixed increase in available memory,
|
||||
because some devices are constrained by their total available memory.
|
||||
|
||||
To query the available memory size at runtime, use the methods `https://developer.android.com/reference/android/app/ActivityManager#getMemoryClass()` or `https://developer.android.com/reference/android/app/ActivityManager#getLargeMemoryClass()`.
|
||||
|
||||
`android:label`
|
||||
: A user-readable label for the application as a whole and a default
|
||||
label for each of the application's components. See the individual
|
||||
`label` attributes for the
|
||||
`https://developer.android.com/guide/topics/manifest/activity-element`,
|
||||
`https://developer.android.com/guide/topics/manifest/activity-alias-element`,
|
||||
`https://developer.android.com/guide/topics/manifest/service-element`,
|
||||
`https://developer.android.com/guide/topics/manifest/receiver-element`, and
|
||||
`https://developer.android.com/guide/topics/manifest/provider-element` elements.
|
||||
|
||||
|
||||
The label is set as a reference to a string resource, so that
|
||||
it can be localized like other strings in the user interface.
|
||||
However, as a convenience while you're developing the application,
|
||||
it can also be set as a raw string.
|
||||
|
||||
`android:localeConfig`
|
||||
|
||||
: A reference to an XML resource that specifies the list of locales
|
||||
supported by the application. This is used by the system to support per-app
|
||||
language preferences.
|
||||
|
||||
For more information, see the guide on
|
||||
[per-app language preferences](https://developer.android.com/guide/topics/resources/app-languages).
|
||||
|
||||
`android:logo`
|
||||
: A logo for the application as whole and the default logo for activities.
|
||||
This attribute is set as a reference to a drawable resource containing
|
||||
the image, such as `"@drawable/logo"`. There is no default logo.
|
||||
|
||||
`android:manageSpaceActivity`
|
||||
: The fully qualified name of an `Activity` subclass that the system
|
||||
launches to let users manage the memory occupied by the application
|
||||
on the device. The activity is also declared with an
|
||||
`https://developer.android.com/guide/topics/manifest/activity-element` element.
|
||||
|
||||
`android:name`
|
||||
: The fully qualified name of an `https://developer.android.com/reference/android/app/Application`
|
||||
subclass implemented for the application. When the application process
|
||||
is started, this class is instantiated before any of the application's
|
||||
components.
|
||||
|
||||
|
||||
The subclass is optional. Most applications don't need one.
|
||||
In the absence of a subclass, Android uses an instance of the base
|
||||
`Application` class.
|
||||
|
||||
`android:networkSecurityConfig`
|
||||
|
||||
: Specifies the name of the XML file that contains your application's
|
||||
[Network security
|
||||
configuration](https://developer.android.com/training/articles/security-config). The value is a reference to the XML resource file
|
||||
containing the configuration.
|
||||
|
||||
This attribute was added in API level 24.
|
||||
|
||||
`android:pageSizeCompat`
|
||||
|
||||
: Overrides the user or platform compatibility settings for 16 KB page
|
||||
sizes, which lets you force page-agnostic compatibility mode on or off for
|
||||
this application.
|
||||
|
||||
For more information, see the guide on
|
||||
[supporting 16 KB page sizes](https://developer.android.com/guide/practices/page-sizes).
|
||||
|
||||
`android:permission`
|
||||
: The name of a permission that clients need in order to interact
|
||||
with the application. This attribute is a convenient way to set a
|
||||
permission that applies to all of the application's components. It is
|
||||
overwritten by setting the `permission` attributes of individual
|
||||
components.
|
||||
|
||||
|
||||
For more information about permissions, see the
|
||||
[Permissions](https://developer.android.com/guide/topics/manifest/manifest-intro#perms)
|
||||
section in the app manifest overview and
|
||||
[Security tips](https://developer.android.com/guide/topics/security/security).
|
||||
|
||||
`android:persistent`
|
||||
: Whether the application remains running at all times. It's
|
||||
`"true"` if it does and `"false"` if not. The default value
|
||||
is `"false"`. Applications don't normally set this flag.
|
||||
Persistence mode is intended only for certain system applications.
|
||||
|
||||
`android:process`
|
||||
: The name of a process where all components of the application run.
|
||||
Each component can override this default by setting its own `process`
|
||||
attribute.
|
||||
|
||||
|
||||
By default, Android creates a process for an application when the first
|
||||
of its components needs to run. All components then run in that process.
|
||||
The name of the default process matches the package name set by the
|
||||
`https://developer.android.com/guide/topics/manifest/manifest-element` element.
|
||||
|
||||
|
||||
By setting this attribute to a process name that's shared with another
|
||||
application, you can arrange for components of both applications to run in
|
||||
the same process, but only if the two applications also share a
|
||||
user ID and are signed with the same certificate.
|
||||
|
||||
|
||||
If the name assigned to this attribute begins with a colon (`:`), a new
|
||||
process, private to the application, is created when it's needed.
|
||||
If the process name begins with a lowercase character, a global process
|
||||
of that name is created. A global process can be shared with other
|
||||
applications, reducing resource usage.
|
||||
|
||||
`android:restoreAnyVersion`
|
||||
: Indicates that the application is prepared to attempt a restore of any
|
||||
backed-up data set, even if the backup was stored by a newer version
|
||||
of the application than is currently installed on the device. Setting
|
||||
this attribute to `"true"` lets the Backup Manager
|
||||
- `$1`
|
||||
attempt a restore even when a version mismatch suggests that the data is incompatible. *Use with caution!*
|
||||
- The default value of this attribute is `"false"`.
|
||||
|
||||
`android:requestLegacyExternalStorage`
|
||||
|
||||
: Whether the application wants to opt out of
|
||||
[scoped storage](https://developer.android.com/training/data-storage/files/external-scoped).
|
||||
|
||||
**Note:** Depending on changes related to policy or app
|
||||
compatibility, the system might not honor this opt-out request.
|
||||
|
||||
`android:requiredAccountType`
|
||||
: Specifies the account type required by the application to function.
|
||||
If your app requires an `https://developer.android.com/reference/android/accounts/Account`, the value for this attribute must
|
||||
correspond to the account authenticator
|
||||
type used by your app, as defined by `https://developer.android.com/reference/android/accounts/AuthenticatorDescription`,
|
||||
such as `"com.google"`.
|
||||
|
||||
The default value is null and indicates that the application
|
||||
can work *without* any accounts.
|
||||
|
||||
|
||||
Because restricted profiles
|
||||
can't add accounts, specifying this attribute makes your app
|
||||
unavailable from a restricted profile unless you also declare
|
||||
[`android:restrictedAccountType`](https://developer.android.com/guide/topics/manifest/application-element#restrictedAccountType) with
|
||||
the same value.
|
||||
|
||||
|
||||
**Caution:**
|
||||
If the account data might reveal personally identifiable information, it's important
|
||||
that you declare this attribute and leave [`android:restrictedAccountType`](https://developer.android.com/guide/topics/manifest/application-element#restrictedAccountType) null, so that restricted profiles cannot use
|
||||
your app to access personal information that belongs to the owner user.
|
||||
|
||||
|
||||
This attribute was added in API level 18.
|
||||
|
||||
`android:resizeableActivity`
|
||||
|
||||
:
|
||||
Specifies whether the app supports [multi-window mode](https://developer.android.com/guide/topics/ui/multi-window).
|
||||
|
||||
> [!WARNING]
|
||||
> **Warning:** To improve the layout of apps on form factors with smallest width \>= 600dp, the system ignores this attribute for apps that target Android 16 (API level 36). Your app can opt out of the Android 16 behavior, but the opt out will be eliminated in a future release. See [Device compatibility mode](https://developer.android.com/guide/practices/device-compatibility-mode#android_16).
|
||||
|
||||
|
||||
You can set this attribute in either the [`<activity>`](https://developer.android.com/guide/topics/manifest/activity-element)
|
||||
or `<application>` element.
|
||||
|
||||
|
||||
If you set this attribute to `"true"`, the user can launch the activity in
|
||||
split-screen and free-form modes. If you set the attribute to `"false"`, the app
|
||||
can't be tested or optimized for a multi-window environment. The system can
|
||||
still put the activity in multi-window mode with compatibility mode applied.
|
||||
|
||||
|
||||
Setting this attribute to `"true"` doesn't guarantee that there are no
|
||||
other apps in multi-window mode visible on screen, such as picture-in-picture, or
|
||||
on other displays. Therefore, setting this flag doesn't mean that your app
|
||||
has exclusive resource access.
|
||||
|
||||
|
||||
For apps targeting API level 24 or higher, the default is `"true"`.
|
||||
|
||||
|
||||
If your app targets API level 31 or higher, this attribute works differently on small and large
|
||||
screens:
|
||||
|
||||
- **Large screens (sw \>= 600dp):** all apps support multi-window mode. The attribute indicates whether an app can be resized, not whether the app supports multi-window mode. If `resizeableActivity="false"`, the app is put into compatibility mode when necessary to conform to display dimensions.
|
||||
- **Small screens (sw \< 600dp):** if `resizeableActivity="true"` and the minimum width and minimum height of the main activity are within the multi-window requirements, the app supports multi-window mode. If `resizeableActivity="false"`, the app doesn't support multi-window mode regardless of the activity minimum width and height.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:**
|
||||
>
|
||||
> - Device manufacturers can override the API level 31 behavior to improve the layout of apps.
|
||||
> - On devices with Android 16 (API level 36) or higher installed, virtual device owners (select trusted and privileged apps) can configure devices they manage to override (ignore) this attribute to improve app layout. See also [Companion app
|
||||
> streaming](https://source.android.com/docs/core/permissions/app-streaming).
|
||||
>
|
||||
> See [Device compatibility mode](https://developer.android.com/guide/practices/device-compatibility-mode).
|
||||
|
||||
|
||||
A task's root activity value is applied to all additional activities launched in the task. That is, if the root
|
||||
activity of a task is resizable, then the system treats all other activities in the task as resizable. If the root
|
||||
activity isn't resizable, the other activities in the task aren't resizable.
|
||||
|
||||
|
||||
This attribute was added in API level 24.
|
||||
|
||||
`android:restrictedAccountType`
|
||||
: Specifies the account type required by this application and indicates that restricted profiles
|
||||
can access such accounts that belong to the owner user. If your app requires an
|
||||
`https://developer.android.com/reference/android/accounts/Account` and restricted profiles *can*
|
||||
access the primary user's accounts, the value for this attribute must
|
||||
correspond to the account authenticator type used by your app, as
|
||||
defined by `https://developer.android.com/reference/android/accounts/AuthenticatorDescription`, such as `"com.google"`.
|
||||
|
||||
The default value is null and indicates that the application can work *without* any
|
||||
accounts.
|
||||
|
||||
|
||||
**Caution:**
|
||||
Specifying this attribute lets restricted profiles use your
|
||||
app with accounts that belong to the owner user, which might reveal personally identifiable
|
||||
information. If the account might reveal personal details, *don't*
|
||||
use this attribute. Instead, declare the [`android:requiredAccountType`](https://developer.android.com/guide/topics/manifest/application-element#requiredAccountType) attribute
|
||||
to make your app unavailable to restricted profiles.
|
||||
|
||||
|
||||
This attribute was added in API level 18.
|
||||
|
||||
`android:supportsRtl`
|
||||
|
||||
: Declares whether your application is willing to support right-to-left (RTL) layouts.
|
||||
|
||||
If this is set to `"true"` and
|
||||
[`targetSdkVersion`](https://developer.android.com/guide/topics/manifest/uses-sdk-element#target)
|
||||
is set to 17 or higher, various RTL APIs are
|
||||
activated and used by the system so your app can display RTL layouts.
|
||||
If this is set to `"false"` or if `targetSdkVersion` is set to 16 or lower, the RTL APIs are ignored
|
||||
or have no effect, and your app behaves the same regardless of the layout
|
||||
direction associated to the user's locale choice. That is, your layouts are always left-to-right.
|
||||
|
||||
The default value of this attribute is `"false"`.
|
||||
|
||||
This attribute was added in API level 17.
|
||||
|
||||
`android:taskAffinity`
|
||||
: An affinity name that applies to all activities within the application,
|
||||
except for those that set a different affinity with their own
|
||||
`https://developer.android.com/guide/topics/manifest/activity-element#aff`
|
||||
attributes. See that attribute for more information.
|
||||
|
||||
|
||||
By default, all activities within an application share the same
|
||||
affinity. The name of that affinity is the same as the package name
|
||||
set by the
|
||||
`https://developer.android.com/guide/topics/manifest/manifest-element` element.
|
||||
|
||||
`android:testOnly`
|
||||
: Indicates whether this application is only for testing purposes. For example,
|
||||
it might expose functionality or data outside of itself that can cause a security
|
||||
hole, but be useful for testing. This kind of APK only installs
|
||||
through `https://developer.android.com/studio/command-line/adb`. You can't publish it to Google Play.
|
||||
|
||||
Android Studio automatically adds this attribute when you click **Run**
|
||||
.
|
||||
|
||||
`android:theme`
|
||||
: A reference to a style resource defining a default theme for all
|
||||
activities in the application. Individual activities can override
|
||||
the default by setting their own `https://developer.android.com/guide/topics/manifest/activity-element#theme`
|
||||
attributes. For more information, see [Styles and themes](https://developer.android.com/guide/topics/ui/themes).
|
||||
|
||||
`android:uiOptions`
|
||||
: Extra options for an activity's UI. Must be one of the following values:
|
||||
|
||||
| Value | Description |
|
||||
|---|---|
|
||||
| `"none"` | No extra UI options. This is the default. |
|
||||
| `"splitActionBarWhenNarrow"` | Adds a bar at the bottom of the screen to display action items in the *app bar* , also known as the *action bar*, when constrained for horizontal space, such as when in portrait mode on a handset. Instead of a small number of action items appearing in the app bar at the top of the screen, the app bar splits into the top navigation section and the bottom bar for action items. This means a reasonable amount of space is available for the action items and for the navigation and title elements at the top. Menu items aren't split across the two bars. They always appear together. |
|
||||
|
||||
|
||||
For more information about the app bar, see [Add the app bar](https://developer.android.com/training/appbar).
|
||||
|
||||
This attribute was added in API level 14.
|
||||
|
||||
`android:usesCleartextTraffic`
|
||||
: Indicates whether the app intends to use cleartext network traffic, such as cleartext HTTP.
|
||||
The default value for apps that target API level 27 or lower is `"true"`. Apps that
|
||||
target API level 28 or higher default to `"false"`.
|
||||
|
||||
**Note:**
|
||||
This attribute is getting deprecated and will be ignored for apps targeting API levels 38 and above.
|
||||
Specify a [Network Security Configuration](https://developer.android.com/training/articles/security-config#CleartextTraffic) to control cleartext traffic for API levels 24 and above.
|
||||
If your app targets API levels 23 and below, you must specify `android:usesCleartextTraffic` in addition to a Network Security Config.
|
||||
|
||||
|
||||
When the attribute is set to `"false"`, platform components, for example, HTTP and FTP
|
||||
stacks, `https://developer.android.com/reference/android/app/DownloadManager`, and
|
||||
`https://developer.android.com/reference/android/media/MediaPlayer`, refuse the
|
||||
app's requests to use cleartext traffic.
|
||||
|
||||
Third-party libraries are strongly encouraged to honor this
|
||||
setting as well. The key reason for avoiding cleartext traffic is the lack of confidentiality,
|
||||
authenticity, and protections against tampering. A network attacker can eavesdrop on transmitted
|
||||
data and also modify it without being detected.
|
||||
|
||||
|
||||
This flag is honored on a best-effort basis because it's impossible to prevent all cleartext
|
||||
traffic from Android applications given the level of access provided to them. For example, there's
|
||||
no expectation that the `https://developer.android.com/reference/java/net/Socket` API honors
|
||||
this flag, because it can't determine whether its traffic is in cleartext.
|
||||
|
||||
However, most
|
||||
network traffic from applications is handled by higher-level network stacks and components, which can
|
||||
honor this flag by either reading it from
|
||||
`https://developer.android.com/reference/android/content/pm/ApplicationInfo#flags`
|
||||
or
|
||||
`https://developer.android.com/reference/android/security/NetworkSecurityPolicy#isCleartextTrafficPermitted()`.
|
||||
|
||||
|
||||
**Note:**
|
||||
`https://developer.android.com/reference/android/webkit/WebView` honors this attribute for
|
||||
applications targeting API level 26 and higher.
|
||||
|
||||
|
||||
During app development, StrictMode can be used to identify any cleartext traffic from the app.
|
||||
For more information, see
|
||||
`https://developer.android.com/reference/android/os/StrictMode.VmPolicy.Builder#detectCleartextNetwork()`.
|
||||
|
||||
|
||||
This attribute was added in API level 23.
|
||||
|
||||
|
||||
This flag is ignored on Android 7.0 (API level 24) and above if an Android Network Security
|
||||
Config is present.
|
||||
|
||||
`android:vmSafeMode`
|
||||
: Indicates whether the app wants the virtual machine (VM) to operate
|
||||
in safe mode. The default value is `"false"`.
|
||||
|
||||
This attribute was added in API level 8, where a value of `"true"`
|
||||
disabled the Dalvik just-in-time (JIT) compiler.
|
||||
|
||||
|
||||
This attribute was adapted in API level 22, where a value of `"true"`
|
||||
disabled the ART ahead-of-time (AOT) compiler.
|
||||
|
||||
introduced in:
|
||||
: API level 1
|
||||
|
||||
see also:
|
||||
: `https://developer.android.com/guide/topics/manifest/activity-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/service-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/receiver-element`
|
||||
|
||||
`https://developer.android.com/guide/topics/manifest/provider-element`
|
||||
@@ -0,0 +1,327 @@
|
||||
Before your users can authenticate with passkeys, your app must first register
|
||||
or create the passkey for their account.
|
||||
|
||||
To create the passkey, obtain details required to create the passkey from your
|
||||
app server, and then call the Credential Manager API, which returns a public and
|
||||
private key pair. The returned private key is stored in a credential provider,
|
||||
such as Google Password Manager, as a passkey. The public key is stored on your
|
||||
app server.
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** While designing authentication flows with passkeys, make sure that you follow the [UX guidelines for passkeys](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys).
|
||||
|
||||
 **Figure 1:**Creation of passkeys
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Make sure that you have set up [Digital Asset Links](https://developer.android.com/identity/credential-manager/prerequisites) and that you target
|
||||
devices running Android 9 (API level 28) or higher.
|
||||
|
||||
## Overview
|
||||
|
||||
This guide focuses on the changes required in your [relying party client app](https://developer.android.com/identity/credential-manager#authentication-terminology)
|
||||
to create a passkey, and gives a brief overview of the [relying party app
|
||||
server](https://developer.android.com/identity/credential-manager#authentication-terminology) implementation. To learn more about the server-side integration, see
|
||||
[Server-side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
|
||||
1. [**Add dependencies to your app**](https://developer.android.com/identity/passkeys/create-passkeys#add-dependencies): Add the required Credential Manager libraries.
|
||||
2. [**Instantiate Credential Manager**](https://developer.android.com/identity/passkeys/create-passkeys#instantiate): Create a Credential Manager instance.
|
||||
3. [**Get credential creation options from the app server**](https://developer.android.com/identity/passkeys/create-passkeys#get-options): From your app server, send the client app the details required to create the passkey, such as information about the app, the user, as well as a `challenge` and other fields.
|
||||
4. [**Request a passkey**](https://developer.android.com/identity/passkeys/create-passkeys#request-passkey): In your app, use the details received from the app server to create a [`GetPublicKeyCredentialOption`](https://developer.android.com/reference/androidx/credentials/GetPublicKeyCredentialOption) object and use this object to invoke the `credentialManager.getCredential()` method to create a passkey.
|
||||
5. [**Handle the passkey creation response**](https://developer.android.com/identity/passkeys/create-passkeys#handle-response): When you receive the credentials on your client app, you must encode, serialize and then send the public key to the app server. You must also handle each of the exceptions that can occur in case of passkey creation.
|
||||
6. [**Verify and save the public key on the server**](https://developer.android.com/identity/passkeys/create-passkeys#verify): Complete the server-side steps to verify the origin of the credential and then save the public key.
|
||||
7. [**Notify the user**](https://developer.android.com/identity/passkeys/create-passkeys#notify): Notify the user that their passkey has been created.
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** To enhance the user experience during sign up, add functionality to [restore credentials](https://developer.android.com/identity/sign-in/restore-credentials) on a new device to let users seamlessly set up their existing accounts on new Android devices, and [suppressing autofill dialogs on
|
||||
> credential fields](https://developer.android.com/identity/passkeys/create-passkeys#suppress-autofill).
|
||||
|
||||
## Add dependencies to your app
|
||||
|
||||
Add the following dependencies to your app module's `build.gradle` file:
|
||||
|
||||
### Kotlin
|
||||
|
||||
```kotlin
|
||||
dependencies {
|
||||
implementation("androidx.credentials:credentials:1.7.0-alpha03")
|
||||
implementation("androidx.credentials:credentials-play-services-auth:1.7.0-alpha03")
|
||||
}
|
||||
```
|
||||
|
||||
### Groovy
|
||||
|
||||
```groovy
|
||||
dependencies {
|
||||
implementation "androidx.credentials:credentials:1.7.0-alpha03"
|
||||
implementation "androidx.credentials:credentials-play-services-auth:1.7.0-alpha03"
|
||||
}
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Use the latest available versions of the dependencies. Versions of [`androidx.credentials`](https://developer.android.com/identity/passkeys/create-passkeys#automatic-upgrade) earlier than version 1.2 throw an `UnsupportedOperationException("Post-U not supported yet")` exception on Android 14.
|
||||
|
||||
## Instantiate Credential Manager
|
||||
|
||||
Use your app or activity context to create a `CredentialManager` object.
|
||||
|
||||
// Use your app or activity context to instantiate a client instance of
|
||||
// CredentialManager.
|
||||
private val credentialManager = CredentialManager.create(context)
|
||||
|
||||
## Get credential creation options from your app server
|
||||
|
||||
When the user clicks a "Create Passkey" button or when a new user signs up, make
|
||||
a request from your app to your app server to obtain the information required to
|
||||
start the passkey registration process.
|
||||
|
||||
Use a FIDO-compliant library in your app server to send your client app the
|
||||
information required to create a passkey, such as information about the user,
|
||||
the app, and additional configuration properties. To learn more, see [Server
|
||||
side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
|
||||
In the client app, decode the public key creation options sent by the app
|
||||
server. These are usually represented in JSON format. To learn more about how
|
||||
this decoding is done for web clients, see [Encoding and
|
||||
Decoding](https://developers.google.com/identity/passkeys/developer-guides/server-registration#encoding_and_decoding). For Android client apps, you must handle the decoding
|
||||
separately.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** On your app server, securely store the `challenge` so that you can later verify the origin of the credential.
|
||||
|
||||
The following snippet shows the structure the public key creation options sent
|
||||
by the app server:
|
||||
|
||||
{
|
||||
"challenge": "<base64url-encoded challenge>",
|
||||
"rp": {
|
||||
"name": "<relying party name>",
|
||||
"id": "<relying party host name>"
|
||||
},
|
||||
"user": {
|
||||
"id": "<base64url-encoded user ID>",
|
||||
"name": "<user name>",
|
||||
"displayName": "<user display name>"
|
||||
},
|
||||
"pubKeyCredParams": [
|
||||
{
|
||||
"type": "public-key",
|
||||
"alg": -7
|
||||
}
|
||||
],
|
||||
"attestation": "none",
|
||||
"excludeCredentials": [
|
||||
{
|
||||
"id": "<base64url-encoded credential ID to exclude>",
|
||||
"type": "public-key"
|
||||
}
|
||||
],
|
||||
"authenticatorSelection": {
|
||||
"requireResidentKey": true,
|
||||
"residentKey": "required",
|
||||
"userVerification": "required"
|
||||
}
|
||||
}
|
||||
|
||||
Key fields in the public key creation options include:
|
||||
|
||||
- `challenge`: A server-generated random string that is used to prevent replay attacks.
|
||||
- `rp`: Details about the app.
|
||||
- `rp.name`: The app's name.
|
||||
- `rp.id`: The app's domain or subdomain.
|
||||
- `user`: Details about the user.
|
||||
- `id`: The user's unique ID. This value must not include personally identifying information, for example, email addresses or usernames. You can use a random, 16-byte value.
|
||||
- `name`: A unique identifier for the account that the user will recognise, such as their email address or username. This will be displayed in the account selector. If using a username, use the same value as in password authentication.
|
||||
- `displayName`: An optional, user-friendly name for the account intended for display in the account selector.
|
||||
- `authenticatorSelection`: Details about the device that will be used for authentication.
|
||||
- `authenticatorAttachment`: Indicates the preferred [authenticator](https://www.w3.org/TR/webauthn/#authenticator). The possible values are as follows:
|
||||
- `platform`: This value is used for an authenticator built into the user's device, such as a fingerprint sensor.
|
||||
- `cross-platform`: This value is used for roaming devices such as security keys. It is not typically used in the passkey context.
|
||||
- Unspecified (recommended): Leaving this value unspecified provides users with the flexibility to create passkeys on their preferred devices. In most cases, leaving the parameter unspecified is the best option.
|
||||
- `requireResidentKey`: To create a passkey, set the value of this `Boolean` field to `true`.
|
||||
- `residentKey`: To create a passkey, set the value to `required`.
|
||||
- `userVerification`: Used to specify the requirements for user verification during a passkey registration. The possible values are as follows:
|
||||
- `preferred`: Use this value if you prioritize user experience over protection, such as in environments where user verification causes more friction than protection.
|
||||
- `required`: Use this value if invoking a user verification method available on the device is required.
|
||||
- `discouraged`: Use this value if using a user verification method is discouraged.
|
||||
To learn more about `userVerification`, see [userVerification deep dive](https://web.dev/articles/webauthn-user-verification).
|
||||
- `excludeCredentials`: List credential IDs in an [array](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-excludecredentials) to prevent the creation of a duplicate passkey if one already exists with the same credential provider.
|
||||
|
||||
## Create a passkey
|
||||
|
||||
After you have parsed the server-side public key creation options, create a
|
||||
passkey by wrapping these options in a `CreatePublicKeyCredentialRequest` object
|
||||
and calling `createCredential()`.
|
||||
|
||||
The `createPublicKeyCredentialRequest` includes the following:
|
||||
|
||||
- `requestJson`: The credential creation options sent by the app server.
|
||||
- `preferImmediatelyAvailableCredentials`: This is an optional Boolean field that defines whether to only use locally-available or credential provider-synced credentials to fulfill the request, instead of credentials from security keys or [hybrid](https://w3c.github.io/webauthn/#dom-authenticatortransport-hybrid) key flows. The possible usages are as follows:
|
||||
- `false` (default): Use this value if the call to Credential Manager was triggered by an explicit user action.
|
||||
- `true`: Use this value if Credential Manager is opportunistically called, such as when first opening the app.
|
||||
If you set the value to `true` and there are no immediately available credentials, Credential Manager won't show any UI and the request will fail immediately, returning NoCredentialException for get requests and [`CreateCredentialNoCreateOptionException`](https://developer.android.com/reference/kotlin/androidx/credentials/exceptions/CreateCredentialNoCreateOptionException) for create requests.
|
||||
- `origin`: This field is automatically set for Android apps. For browsers and similarly privileged apps that need to set `origin`, see [Make Credential
|
||||
Manager calls on behalf of other parties for privileged apps](https://developer.android.com/training/sign-in/privileged-apps).
|
||||
- `isConditional`: This is an optional field that defaults to `false`. For more information, see [Automatically create a passkey](https://developer.android.com/identity/passkeys/create-passkeys#automatic-upgrade).
|
||||
|
||||
Calling the `createCredential()` function launches Credential Manager's built-in
|
||||
bottom sheet UI that prompts the user to use a passkey and to select a
|
||||
credential provider and account for storage. However, if `isConditional` is set
|
||||
to `true`, the bottom sheet UI does not display, and the passkey is
|
||||
automatically created.
|
||||
|
||||
### Automatically create a passkey
|
||||
|
||||
You can automatically create a passkey for a user after a successful password
|
||||
login by setting the `isConditional` parameter to `true` in your
|
||||
`CreatePublicKeyCredentialRequest` while creating a passkey. If the user doesn't
|
||||
already have a passkey, your app will automatically attempt to create one in the
|
||||
background and store it in the user's credential provider, such as Google
|
||||
Password Manager. For an example of how this is implemented, see the [public
|
||||
sample](https://github.com/android/identity-samples/blob/main/Shrine/app/src/main/java/com/authentication/shrine/ui/AuthenticationScreen.kt#L98).
|
||||
 **Figure 2:**Google Password Manager notification
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If a passkey is created automatically, credential providers are responsible for notifying users about a newly created passkey. Google Password Manager notifies users when a passkey is automatically created. However, other credential providers might have their own conditions and notifications for this feature.
|
||||
|
||||
## Handle the response
|
||||
|
||||
After the user is verified using the device's screen lock, a passkey is created
|
||||
and stored in the user's selected credential provider.
|
||||
|
||||
The response after you successfully call `createCredential()` is a
|
||||
[PublicKeyCredential](https://developer.android.com/jetpack/androidx/releases/credentials) object.
|
||||
|
||||
The `PublicKeyCredential` looks as follows:
|
||||
|
||||
{
|
||||
"id": "<identifier>",
|
||||
"type": "public-key",
|
||||
"rawId": "<identifier>",
|
||||
"response": {
|
||||
"clientDataJSON": "<ArrayBuffer encoded object with the origin and signed challenge>",
|
||||
"attestationObject": "<ArrayBuffer encoded object with the public key and other information.>"
|
||||
},
|
||||
"authenticatorAttachment": "platform"
|
||||
}
|
||||
|
||||
In the client app, serialize the object and send it to the app server.
|
||||
|
||||
Add code to handle failures as shown in the following snippet:
|
||||
|
||||
fun handleFailure(e: CreateCredentialException) {
|
||||
when (e) {
|
||||
is CreatePublicKeyCredentialDomException -> {
|
||||
// Handle the passkey DOM errors thrown according to the
|
||||
// WebAuthn spec.
|
||||
}
|
||||
is CreateCredentialCancellationException -> {
|
||||
// The user intentionally canceled the operation and chose not
|
||||
// to register the credential.
|
||||
}
|
||||
is CreateCredentialInterruptedException -> {
|
||||
// Retry-able error. Consider retrying the call.
|
||||
}
|
||||
is CreateCredentialProviderConfigurationException -> {
|
||||
// Your app is missing the provider configuration dependency.
|
||||
// Most likely, you're missing the
|
||||
// "credentials-play-services-auth" module.
|
||||
}
|
||||
is CreateCredentialCustomException -> {
|
||||
// You have encountered an error from a 3rd-party SDK. If you
|
||||
// make the API call with a request object that's a subclass of
|
||||
// CreateCustomCredentialRequest using a 3rd-party SDK, then you
|
||||
// should check for any custom exception type constants within
|
||||
// that SDK to match with e.type. Otherwise, drop or log the
|
||||
// exception.
|
||||
}
|
||||
else -> Log.w(TAG, "Unexpected exception type ${e::class.java.name}")
|
||||
}
|
||||
}
|
||||
|
||||
## Verify and save the public key on the app server
|
||||
|
||||
On the app server, you must verify the public key credential and then [save the
|
||||
public key](https://web.dev/articles/passkey-registration#save-credential).
|
||||
|
||||
To verify the public key credential's origin, compare it against an allow list
|
||||
of approved apps. If a key has an unrecognized origin, reject it.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** An app's origin is based on its unique identity, which is the SHA-256 fingerprint of its signing certificate.
|
||||
|
||||
To obtain the app's SHA 256 fingerprint:
|
||||
|
||||
1. Print your release app's signing certificate by running the following
|
||||
command in a terminal:
|
||||
|
||||
keytool -list -keystore <path-to-apk-signing-keystore>
|
||||
|
||||
In the response, identify the signing certificate's SHA 256 fingerprint,
|
||||
mentioned as `Certificate fingerprints block` : `SHA256`.
|
||||
2. Encode the SHA256 fingerprint with base64url encoding. This Python example
|
||||
demonstrates how to properly encode the fingerprint:
|
||||
|
||||
import binascii
|
||||
import base64
|
||||
fingerprint = '<SHA256 finerprint>' # your app's SHA256 fingerprint
|
||||
print(base64.urlsafe_b64encode(binascii.a2b_hex(fingerprint.replace(':', ''))).decode('utf8').replace('=', ''))
|
||||
|
||||
3. Append `android:apk-key-hash`: to the start of the output from the previous
|
||||
step so that you get something that is similar to the following:
|
||||
|
||||
android:apk-key-hash:<encoded SHA 256 fingerprint>
|
||||
|
||||
The result should match with an allowed origin on your app server. If you
|
||||
have multiple signing certificates, such as certificates for debugging and
|
||||
release, or multiple apps, then repeat the process and accept all the
|
||||
origins as valid on the app server.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** When you save the passkey on the app server, make sure that you save the Authenticator Attestation Globally Unique Identifier ([AAGUID](https://web.dev/articles/webauthn-aaguid)) from the client data. The AAGUID is a unique number that identifies the model of the authenticator. For more information, see [Manage passkeys](https://developer.android.com/identity/passkeys/manage-passkeys).
|
||||
|
||||
## Notify the user
|
||||
|
||||
After the passkey is successfully created, notify your users about the passkey
|
||||
and inform them that they can manage their passkeys from their credential
|
||||
provider app or from [within the app settings](https://developer.android.com/identity/passkeys/manage-passkeys). Notify users by using a
|
||||
custom dialog, notification, or snackbar. Since an unexpected passkey creation
|
||||
by a malicious entity requires an immediate security alert, consider
|
||||
supplementing these in-app methods with external communication, such as an
|
||||
email.
|
||||
|
||||
## Enhance the user experience
|
||||
|
||||
To enhance the user experience while implementing sign up with Credential
|
||||
Manager, consider adding functionality for restore credentials and suppress
|
||||
autofill dialogs.
|
||||
|
||||
### Add functionality to restore credentials on a new device
|
||||
|
||||
To allow users to seamlessly log into their accounts on a new device, implement
|
||||
the [Restore Credentials](https://developer.android.com/identity/sign-in/restore-credentials) functionality. Adding restore credentials with
|
||||
`BackupAgent` logs users in when they open your restored app on a new device,
|
||||
letting them use your app right away.
|
||||
|
||||
### Suppress autofill on credential fields (optional)
|
||||
|
||||
For app screens where users are expected to use Credential Manager's bottom
|
||||
sheet UI for authentication, add the `isCredential` attribute to the username
|
||||
and password fields. This suppresses autofill dialogs (`FillDialog` and
|
||||
`SaveDialog`) from overlapping with Credential Manager's bottom sheet UI.
|
||||
|
||||
The `isCredential` attribute is supported on Android 14 and higher.
|
||||
|
||||
The following example demonstrates how you can add the `isCredential` attribute
|
||||
to the relevant username and password fields in the relevant views for your app:
|
||||
|
||||
<TextView
|
||||
android:layout_width="match_parent"
|
||||
android:layout_height="wrap_content"
|
||||
android:isCredential="true" /\>
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Sign in with passkeys](https://developer.android.com/identity/passkeys/sign-in-with-passkeys)
|
||||
- [Manage passkeys](https://developer.android.com/identity/passkeys/manage-passkeys)
|
||||
- [Understand passkey user experience flows](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys)
|
||||
+216
@@ -0,0 +1,216 @@
|
||||
This guide continues on the implementation of using passkeys for authentication.
|
||||
Before your users can sign in with passkeys, you must also complete the
|
||||
instructions in [Create passkeys](https://developer.android.com/identity/passkeys/create-passkeys).
|
||||
|
||||
To authenticate with a passkey, you must first retrieve the options required to
|
||||
retrieve the public key from your [app server](https://developer.android.com/identity/credential-manager#authentication-terminology), and then call the Credential
|
||||
Manager API to retrieve the public key. Then, handle the sign-in response
|
||||
appropriately.
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** While designing authentication flows with passkeys, make sure you follow the recommendations in the [UX guidelines for passkeys](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys).
|
||||
|
||||
## Overview
|
||||
|
||||
This guide focuses on the changes required in your client app to sign in your
|
||||
user with a passkey, and gives a brief overview of the app server-side
|
||||
implementation. To learn more about server-side integration, see [Server-side
|
||||
passkey authentication](https://developers.google.com/identity/passkeys/developer-guides/server-authentication).
|
||||
|
||||
To retrieve all the passkey and password options that are associated with the
|
||||
user's account, complete these steps:
|
||||
|
||||
1. [**Get credential request options from the server**](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#get-options): Make a request from your app to your authentication server to start the passkey sign-in process. From the server, send the options required to get the public key credential, as well as a unique challenge.
|
||||
2. [**Create the object required to get the public key credential**](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#create-object): Wrap the options sent by the server in a `GetPublicKeyCredentialOption` object
|
||||
3. ([**optional) Prepare getCredential**](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#reduce-latency): In Android 14 and higher, you can reduce latency by showing the account selector by using the `prepareGetCredential()` method before calling `getCredential()`.
|
||||
4. [**Launch the sign in flow**](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#launch-sign-in): Call `getCredential()` method to sign in the user
|
||||
5. [**Handle the response**](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#handle-response): Handle each of the possible credential responses.
|
||||
6. [**Handle exceptions**](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#handle-exceptions): Make sure that you handle exceptions appropriately.
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** Enhance the user experience during sign in by also adding functionality to [restore credentials](https://developer.android.com/identity/sign-in/restore-credentials) on a new device to let users seamlessly set up their existing accounts on new Android devices.
|
||||
|
||||
## Get credential request options from the server
|
||||
|
||||
Request the server for the options required to get the public key credentials,
|
||||
as well as the `challenge`, which is unique for each sign-in attempt. To learn
|
||||
more about the server-side implementation, see [Create the
|
||||
challenge](https://developers.google.com/identity/passkeys/developer-guides/server-authentication#create_the_challenge) and [Create credential request
|
||||
options](https://developers.google.com/identity/passkeys/developer-guides/server-authentication#create_credential_request_options).
|
||||
|
||||
The options look similar to the following:
|
||||
|
||||
{
|
||||
"challenge": "<your app challenge>",
|
||||
"allowCredentials": [],
|
||||
"rpId": "<your app server domain>"
|
||||
}
|
||||
|
||||
To learn more about the fields, see the blogpost about [signing in with a
|
||||
passkey](https://web.dev/articles/passkey-form-autofill#fetch_information_from_the_backend).
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** To reduce wait times in the UI because of as network calls, fetch the details required from the app server at the beginning of the user's app session.
|
||||
|
||||
## Create the object required to get the public key credential
|
||||
|
||||
In your app, use the options to create a `GetPublicKeyCredentialOption` object.
|
||||
In the following example, `requestJson` represents the options sent by the
|
||||
server.
|
||||
|
||||
// Get password logins from the credential provider on the user's device.
|
||||
val getPasswordOption = GetPasswordOption()
|
||||
|
||||
// Get passkeys from the credential provider on the user's device.
|
||||
val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
|
||||
requestJson = requestJson
|
||||
)
|
||||
|
||||
Then, wrap `GetPublicKeyCredentialOption` in a `GetCredentialRequest` object.
|
||||
|
||||
val credentialRequest = GetCredentialRequest(
|
||||
// Include all the sign-in options that your app supports.
|
||||
listOf(getPasswordOption, getPublicKeyCredentialOption),
|
||||
// Defines whether you prefer to use only immediately available
|
||||
// credentials or hybrid credentials.
|
||||
preferImmediatelyAvailableCredentials = preferImmediatelyAvailableCredentials
|
||||
)
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** [`GetCredentialRequest`](https://developer.android.com/reference/androidx/credentials/GetCredentialRequest#GetCredentialRequest) can include an `origin` field. However, `origin` is automatically set for Android apps, and hence should be left as null. For browsers and similarly privileged apps that need to set `origin`, see [Make Credential Manager calls on behalf of other parties for privileged
|
||||
> apps](https://developer.android.com/training/sign-in/privileged-apps).
|
||||
|
||||
## Optional: Reduce sign-in latency
|
||||
|
||||
On Android 14 or higher, you can reduce latency when showing the account
|
||||
selector by using the [`prepareGetCredential()`](https://developer.android.com/reference/androidx/credentials/CredentialManager#prepareGetCredential) method before calling
|
||||
`getCredential()`.
|
||||
|
||||
The `prepareGetCredential()` method returns a
|
||||
[`PrepareGetCredentialResponse`](https://developer.android.com/reference/androidx/credentials/PrepareGetCredentialResponse) object which is cached. This lets the
|
||||
`getCredential()` method in the following step bring up the account selector
|
||||
with the cached data.
|
||||
|
||||
coroutineScope {
|
||||
val response = credentialManager.prepareGetCredential(
|
||||
GetCredentialRequest(
|
||||
listOf(
|
||||
// Include all the sign-in options that your app supports
|
||||
getPublicKeyCredentialOption,
|
||||
getPasswordOption
|
||||
)
|
||||
)
|
||||
)
|
||||
}
|
||||
|
||||
## Launch the sign-in flow
|
||||
|
||||
Call the `getCredential()` method to show the user the account selector. Use the
|
||||
following code snippet as a reference for how to launch the sign-in flow:
|
||||
|
||||
// Use an activity-based context to avoid undefined system UI
|
||||
// launching behavior.
|
||||
val context = MutableContextWrapper(activityContext)
|
||||
coroutineScope {
|
||||
try {
|
||||
result = credentialManager.getCredential(
|
||||
// Use MutableContextWrapper to avoid memory leak during configuration changes
|
||||
context = context,
|
||||
request = credentialRequest
|
||||
)
|
||||
handleSignIn(result)
|
||||
} catch (e: GetCredentialException) {
|
||||
// Handle failure
|
||||
}
|
||||
}
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If you call `getCredential()` but the user does not have any credentials available, or if they don't grant consent to using their credentials, a `NoCredentialException` is returned. To learn more about this exception, see the [troubleshooting guide](https://developer.android.com/identity/sign-in/credential-manager-troubleshooting-guide).
|
||||
|
||||
## Handle the response
|
||||
|
||||
Handle the response, which can contain one of various types of credential
|
||||
objects.
|
||||
|
||||
fun handleSignIn(result: GetCredentialResponse) {
|
||||
// Handle the successfully returned credential.
|
||||
val credential = result.credential
|
||||
|
||||
when (credential) {
|
||||
is PublicKeyCredential -> {
|
||||
val responseJson = credential.authenticationResponseJson
|
||||
// Share responseJson i.e. a GetCredentialResponse on your server to
|
||||
// validate and authenticate
|
||||
}
|
||||
|
||||
is PasswordCredential -> {
|
||||
val username = credential.id
|
||||
val password = credential.password
|
||||
// Use id and password to send to your server to validate
|
||||
// and authenticate
|
||||
}
|
||||
|
||||
is CustomCredential -> {
|
||||
// If you are also using any external sign-in libraries, parse them
|
||||
// here with the utility functions provided.
|
||||
if (credential.type == ExampleCustomCredential.TYPE) {
|
||||
try {
|
||||
val ExampleCustomCredential =
|
||||
ExampleCustomCredential.createFrom(credential.data)
|
||||
// Extract the required credentials and complete the authentication as per
|
||||
// the federated sign in or any external sign in library flow
|
||||
} catch (e: ExampleCustomCredential.ExampleCustomCredentialParsingException) {
|
||||
// Unlikely to happen. If it does, you likely need to update the dependency
|
||||
// version of your external sign-in library.
|
||||
Log.e(TAG, "Failed to parse an ExampleCustomCredential", e)
|
||||
}
|
||||
} else {
|
||||
// Catch any unrecognized custom credential type here.
|
||||
Log.e(TAG, "Unexpected type of credential")
|
||||
}
|
||||
}
|
||||
else -> {
|
||||
// Catch any unrecognized credential type here.
|
||||
Log.e(TAG, "Unexpected type of credential")
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
The `PublicKeyCredential` returned from authentication is essentially a signed
|
||||
assertion, structured as follows:
|
||||
|
||||
{
|
||||
"id": "<credential ID>",
|
||||
"type": "public-key",
|
||||
"rawId": "<raw credential ID>",
|
||||
"response": {
|
||||
"clientDataJSON": "<signed client data containing challenge>",
|
||||
"authenticatorData": "<authenticator metadata>",
|
||||
"signature": "<digital signature to be verified>",
|
||||
"userHandle": "<user ID from credential registration>"
|
||||
}
|
||||
}
|
||||
|
||||
On the server, you must verify the credential. To learn more, see [Verify and
|
||||
sign in the user](https://developers.google.com/identity/passkeys/developer-guides/server-authentication#verify_and_sign_in_the_user).
|
||||
|
||||
## Handle exceptions
|
||||
|
||||
You should handle all the subclass exceptions of [`GetCredentialException`](https://developer.android.com/reference/androidx/credentials/exceptions/GetCredentialException).
|
||||
To learn how to handle each exception, see the [troubleshooting guide](https://developer.android.com/identity/sign-in/credential-manager-troubleshooting-guide).
|
||||
|
||||
coroutineScope {
|
||||
try {
|
||||
result = credentialManager.getCredential(
|
||||
context = activityContext,
|
||||
request = credentialRequest
|
||||
)
|
||||
} catch (e: GetCredentialException) {
|
||||
Log.e("CredentialManager", "No credential available", e)
|
||||
}
|
||||
}
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Manage passkeys](https://developer.android.com/identity/passkeys/manage-passkeys)
|
||||
- [Understand passkey user experience flows](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys)
|
||||
@@ -0,0 +1,319 @@
|
||||
## Fundamentals
|
||||
|
||||
The objective is to implement the **Restore Credentials** feature through the
|
||||
Android Credential Manager API (`androidx.credentials`). This allows apps that
|
||||
use or are integrating Credential Manager to silently log users back in when
|
||||
they restore their app on a new device. Restore Credentials operates
|
||||
independently of the app's primary authentication method (passwords, passkeys,
|
||||
federated sign-in) and requires no UI changes to existing sign-in flows.
|
||||
|
||||
### Scope
|
||||
|
||||
**Crucial:** This skill focuses exclusively on the Android client-side
|
||||
integration. It does **not** implement the server-side cryptographic
|
||||
validation logic. The developer must be reminded of this and the
|
||||
[Points to inform the developer about](https://developer.android.com/agents/skills/identity/restore-credentials/skill#backend-guidelines) after implementation is done.
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
When instructed to implement Restore Credentials on a developer's application,
|
||||
remember the following:
|
||||
|
||||
1. Before the implementation, you **MUST** read and understand the [Two-Tier
|
||||
Restoration Architecture](https://developer.android.com/agents/skills/identity/restore-credentials/skill#two-tier-restoration-architecture) and review the [DOs and DON'Ts](https://developer.android.com/agents/skills/identity/restore-credentials/skill#dos-and-donts).
|
||||
2. After the implementation, you **MUST** present the developer with the [Backend Guidelines](https://developer.android.com/agents/skills/identity/restore-credentials/skill#backend-guidelines) as a reminder for their backend setup. It is important that you remind the developer that they still have to implement the backend.
|
||||
|
||||
## Two-Tier Restoration Architecture
|
||||
|
||||
To enable a resilient sign-in experience, retrieve credentials through a
|
||||
**two-tier architecture**:
|
||||
|
||||
1. **Tier 1 (Primary - Background):** Executes automatically during device setup using the app's `BackupAgent.onRestoreFinished()` callback. This provides an invisible restoration before the user opens the app for the first time, allowing background sync and notification delivery.
|
||||
2. **Tier 2 (Secondary - Foreground):** Runs in the Launcher `Activity.onCreate()` to catch failovers if background restoration didn't complete (example: dropped network, delayed restoration) or if `allowBackup` is disabled.
|
||||
|
||||
If `allowBackup` in the manifest is set to true, implement both. Otherwise, only
|
||||
implement tier 2 (Foreground Restoration). Do **NOT** change the value of
|
||||
`allowBackup` in the manifest.
|
||||
|
||||
## DOs and DON'Ts
|
||||
|
||||
**DO:**
|
||||
|
||||
- Do check `AndroidManifest.xml` for the value of allowBackup to determine what you have to implement.
|
||||
- Do implement a fallback for createCredential: always try calling it first with `isCloudBackupEnabled` set to true. If an `E2eeUnavailableException` is thrown, catch it and retry the call with `isCloudBackupEnabled` set to `false`.
|
||||
- Do implement a `BackupAgent` (subclass of `android.app.backup.BackupAgent`) if `allowBackup` is true in the manifest.
|
||||
- Call `clearCredentialState()` when the user signs out. This is a mandatory security measure to log the user out fully.
|
||||
- Do attempt to get the restore key on the first launch of the app on a new device and also within the `BackupAgent.onRestoreFinished()` callback if your app uses it.
|
||||
- Do ensure that a restore credential is created even if the user is already logged in.
|
||||
- Do ensure that the credential retrieval and login in `onRestoreFinished()` is performed synchronously (for example using `runBlocking`).
|
||||
- Do restore notifications in the `BackupAgent` if your app uses them. (For example capture and send FCM token to backend)
|
||||
- Do ensure that if you implement mock network requests or stubs, you replace all placeholders with valid, properly formatted JSON payloads for the credential requests.
|
||||
- Do encapsulate credential creation and retrieval into their own dedicated functions. Because credential creation must be called in multiple places (sign-up, sign-in) and retrieval across multiple tiers (`BackupAgent` and Launcher `Activity`), this prevents code duplication.
|
||||
- Do remind the developer of the [critical guidelines](https://developer.android.com/agents/skills/identity/restore-credentials/skill#implementation-guide) for implementing the backend once you're done with the implementation.
|
||||
- Do generate a separate restore key for each application if the organization has multiple apps with different package names, as a restore key is tied to a unique application package name.
|
||||
|
||||
**DON'T:**
|
||||
|
||||
- DON'T change the value of `allowBackup` in `AndroidManifest.xml`. Restore Credentials functionality is not affected by the allowBackup setting, meaning the user will still be automatically logged in when a Restore Credential exists, even if `allowBackup` is false.
|
||||
- DON'T implement a `BackupAgent` if `allowBackup` is `false` in `AndroidManifest.xml`.
|
||||
- DON'T assume the credential stored in the `GetCredentialResponse` to be of type `PublicKeyCredential`. It has type `RestoreCredential`.
|
||||
- DON'T chain `GetRestoreCredentialOption` with any other `CredentialOption` in the construction of a `GetCredentialRequest`.
|
||||
- DON'T assume `CredentialManager` or the Android system will automatically delete a restore key when a user signs out of the app. You must explicitly call `clearCredentialState` with a `ClearCredentialStateRequest` of `TYPE_CLEAR_RESTORE_CREDENTIAL`.
|
||||
- DON'T remove any existing calls to `clearCredentialState()`. A `ClearCredentialStateRequest` without a type specified only clears all NON-restore credentials.
|
||||
|
||||
## Implementation Guide
|
||||
|
||||
Implement the Android client-side code by using the following guide. Follow it
|
||||
**step-by-step** and don't implement any backend functionality, only remind
|
||||
the user of the [Backend Guidelines](https://developer.android.com/agents/skills/identity/restore-credentials/skill#backend-guidelines) once you're done.
|
||||
|
||||
## Version compatibility
|
||||
|
||||
Credential Manager's Restore Credentials works on devices running Android 9 and
|
||||
higher, Google Play services (GMS) core version 24220000 or higher, and version
|
||||
1.5.0 or higher of the `androidx.credentials` library.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Set up a [relying party server](https://developer.android.com/agents/skills/identity/restore-credentials/skill#backend-guidelines) similar to the server for [passkeys](https://developer.android.com/agents/skills/identity/restore-credentials/skill#dos-and-donts). If
|
||||
you already have a [server](https://developer.android.com/agents/skills/identity/restore-credentials/skill#two-tier-restoration-architecture) set up to handle authentication with passkeys,
|
||||
use the same server-side implementation for restore keys.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** While the server-side implementation is the same for passkeys and restore keys, your client-side app can support restore keys without supporting passkeys. Because restore keys work independently of the authentication method in your app (for example, passwords or Sign in with Google), you don't need to make any additional changes to the existing authentication methods in your app's code.
|
||||
|
||||
## Dependencies
|
||||
|
||||
Add the following dependencies to your app module's `build.gradle` file:
|
||||
|
||||
### Kotlin
|
||||
|
||||
```kotlin
|
||||
dependencies {
|
||||
implementation("androidx.credentials:credentials:1.7.0-alpha03")
|
||||
implementation("androidx.credentials:credentials-play-services-auth:1.7.0-alpha03")
|
||||
}
|
||||
```
|
||||
|
||||
### Groovy
|
||||
|
||||
```groovy
|
||||
dependencies {
|
||||
implementation "androidx.credentials:credentials:1.7.0-alpha03"
|
||||
implementation "androidx.credentials:credentials-play-services-auth:1.7.0-alpha03"
|
||||
}
|
||||
```
|
||||
|
||||
Restore Credentials is available from version 1.5.0 and higher of the
|
||||
androidx.credentials library. However, it's recommended to use the latest stable
|
||||
versions of the dependencies where possible.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The Restore Credentials feature works regardless of whether [`allowBackup`](https://developer.android.com/guide/topics/manifest/application-element#allowbackup) is set in the `manifest`.
|
||||
|
||||
## Overview
|
||||
|
||||
1. [**Create a restore key**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#create-restore-key): To create a restore key, complete the following steps:
|
||||
1. [**Instantiate Credential Manager**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#implementation-guide): Create a `CredentialManager` object.
|
||||
2. [**Get credential creation options from the app server**](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API): Send the client app the details required to create the restore key from your app server.
|
||||
3. [**Create the restore key**](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson): Create a restore key for the user's account if the user is signed in to your app.
|
||||
4. [**Handle the credential creation response**](https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptionsjson): Send the credentials from your client app to your app server for processing, and handle any exceptions.
|
||||
2. [**Sign in with a restore key**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#sign-restore): To sign in with a restore key, complete the following steps:
|
||||
1. [**Get credential retrieval options from the app server**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#get-credential-retrieval): Send the client app the details required to retrieve the restore key from your app server.
|
||||
2. [**Get the restore key**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#get-restore): Request the restore key from Credential Manager when the user sets up a new device. This lets the user sign in without additional input.
|
||||
3. [**Handle the credential retrieval response**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#handle-sign-in): Send the restore key from the client app to the app server to sign in the user.
|
||||
3. [**Delete a restore key**](https://developer.android.com/agents/skills/identity/restore-credentials/skill#delete-restore).
|
||||
|
||||
## Create a restore key
|
||||
|
||||
Your app should cover all cases of a user signing in to ensure active users have
|
||||
a restore key created. Create the restore key in the following scenarios:
|
||||
|
||||
- If the user is signed in and a restore key isn't already created (such as in the `onCreate` method for the main `Activity`).
|
||||
- When the user is signing in or completing a new account registration flow.
|
||||
|
||||
To optimize performance and avoid the overhead of creating or checking for a
|
||||
restore credential on every single login, set a `boolean` flag or a credential
|
||||
creation timestamp in local storage, such as `has_synced_restore_credential`, to
|
||||
track whether the key has already been created.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** A restore key is tied to an application's unique package name. If your organization's main app and sub-apps have different package names, create a separate restore key for each app.
|
||||
|
||||
### Instantiate Credential Manager
|
||||
|
||||
Use your app's activity context to instantiate a `CredentialManager` object.
|
||||
|
||||
// Use your app or activity context to instantiate a client instance of
|
||||
// CredentialManager.
|
||||
private val credentialManager = CredentialManager.create(context)
|
||||
|
||||
### Get credential creation options from your app server
|
||||
|
||||
Use a FIDO-compliant library in your app server to send your client app the
|
||||
information required to create the restore credential, such as information about
|
||||
the user, the app, and additional configuration properties. For more information
|
||||
about the server-side implementation, see [Server-side
|
||||
guidance](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
|
||||
### Create the restore key
|
||||
|
||||
After parsing the public key creation options sent by the server, create a
|
||||
restore key by wrapping these options in a
|
||||
[`CreateRestoreCredentialRequest`](https://developer.android.com/reference/androidx/credentials/CreateRestoreCredentialRequest) object and calling the
|
||||
[`createCredential()`](https://developer.android.com/reference/androidx/credentials/CredentialManager#createCredential(android.content.Context,androidx.credentials.CreateCredentialRequest)) method with the `CredentialManager` object.
|
||||
|
||||
// createRestoreRequest contains the details sent by the server
|
||||
val response = credentialManager.createCredential(context, createRestoreRequest)
|
||||
|
||||
#### Key points about the code
|
||||
|
||||
- The `CreateRestoreCredentialRequest` object contains the following fields:
|
||||
|
||||
- `requestJson`: The credential creation options sent by the app server in the [Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) format for [`PublicKeyCredentialCreationOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson).
|
||||
- `isCloudBackupEnabled`: `Boolean` field to determine if the restore key
|
||||
should be backed up to the cloud. By default, this flag is `true`. This
|
||||
field has these values:
|
||||
|
||||
- `true`: (**Recommended**) This value enables the backup of restore keys to the cloud if the user has Google Backup and end-to-end encryption, such as a screen lock, enabled.
|
||||
- `false`: This value saves the key locally and not in the cloud. The key is not available on the new device if the user chooses to restore from the cloud.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Caution:** It is recommended to set `isCloudBackupEnabled` to `true`. If cloud backup is disabled and the user restores from a cloud backup, the call to retrieve the restore key fails. Users who restore your app with a cloud backup don't receive the restore key and are not automatically signed in.
|
||||
|
||||
### Handle the credential creation response
|
||||
|
||||
The Credential Manager API returns a response of type
|
||||
[`CreateRestoreCredentialResponse`](https://developer.android.com/reference/androidx/credentials/CreateRestoreCredentialResponse). This response holds the public key
|
||||
credential registration response in [JSON format](https://w3c.github.io/webauthn/#authenticatorattestationresponse).
|
||||
|
||||
Send the public key from your app to the relying party server. This public key
|
||||
is similar to the public key generated when you create a passkey. The same code
|
||||
that handles passkey creation on the server can also handle restore key
|
||||
creation. For more information about the server-side implementation, see [the
|
||||
guidance for passkeys](https://developer.android.com/identity/passkeys/create-passkeys).
|
||||
|
||||
During the restore key creation process, handle these exceptions:
|
||||
|
||||
- [`CreateRestoreCredentialDomException`](https://developer.android.com/reference/androidx/credentials/exceptions/restorecredential/CreateRestoreCredentialDomException): This exception occurs if `requestJson` is invalid and does not follow the WebAuthn format for [`PublicKeyCredentialCreationOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson).
|
||||
- [`E2eeUnavailableException`](https://developer.android.com/reference/androidx/credentials/exceptions/restorecredential/E2eeUnavailableException): This exception occurs if `isCloudBackupEnabled` is `true`, but the user's device does not have data backup or end-to-end encryption, such as a screen lock.
|
||||
To ensure that Restore Credentials are created in all cases, you must handle the `E2eeUnavailableException` explicitly by calling `createCredential` with `isCloudBackupEnabled` set to `true`. If `E2eeUnavailableException` is thrown, catch and call `createCredential` again with `isCloudBackupEnabled` set to `false`.
|
||||
- `IllegalArgumentException`: This exception occurs if `createRestoreRequest` is empty or not valid JSON, or if it does not have a valid `user.id` that conforms to the WebAuthn [specifications](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson).
|
||||
|
||||
## Sign in with a restore key
|
||||
|
||||
Use Restore Credentials to silently sign in the user during the device setup
|
||||
process.
|
||||
|
||||
### Get credential retrieval options from the app server
|
||||
|
||||
Send the client app the options required to get the restore key from the server.
|
||||
For similar passkey guidance for this step, see [Sign in with a passkey](https://developer.android.com/identity/passkeys/sign-in-with-passkeys#get-options).
|
||||
For more information about the server-side implementation, see the [server-side
|
||||
authentication guide](https://developers.google.com/identity/passkeys/developer-guides/server-authentication#create_credential_request_options).
|
||||
|
||||
### Get the restore key
|
||||
|
||||
To get the restore key on the new device, call the `getCredential()` method on
|
||||
the `CredentialManager` object.
|
||||
|
||||
It is recommended to fetch the restore key in both of the following scenarios:
|
||||
|
||||
- On the first launch of the app on the device. Credential restoration in this scenario is independent of restoration of the app data.
|
||||
- If app data backup and restore is enabled, get the restore key immediately after the app data is restored. Use [`BackupAgent`](https://developer.android.com/reference/android/app/backup/BackupAgent) to configure your app's backup and ensure you complete the `getCredential` functionality within the [`onRestoreFinished`](https://developer.android.com/reference/android/app/backup/BackupAgent#onRestoreFinished()) callback. Don't use the `onRestore` method, as it is only called for key-value backups, whereas `onRestoreFinished` is reliably called for any kind of backup restore. This avoids potential delays when users open their new device for the first time and lets users interact with the app without waiting for them to open your app. For example, this lets your app send the user notifications before they open the app for the first time on the new device, which is particularly relevant for messaging or communications apps.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> **Important:** Notifications aren't automatically restored after the restore credentials are retrieved. If you use Firebase to handle notifications, you must fetch and send the Firebase Cloud Messaging (FCM) token to the backend to successfully resume background messaging and notifications.
|
||||
|
||||
// Fetch the options required to get the restore key
|
||||
val authenticationJson = fetchAuthenticationJson()
|
||||
|
||||
// Create the GetRestoreCredentialRequest object
|
||||
val options = GetRestoreCredentialOption(authenticationJson)
|
||||
val getRequest = GetCredentialRequest(listOf(options))
|
||||
|
||||
val response = credentialManager.getCredential(context, getRequest)
|
||||
|
||||
// Type-check and extract the restore credential
|
||||
val credential = response.credential as RestoreCredential
|
||||
|
||||
The credential manager APIs return a response of type
|
||||
[`GetCredentialResponse`](https://developer.android.com/reference/android/credentials/GetCredentialResponse). The credential contained in this response is
|
||||
explicitly of type `RestoreCredential`, which holds the public key.
|
||||
|
||||
### Handle the sign-in response
|
||||
|
||||
Send the public key from the app to the relying party server, which can then be
|
||||
used to sign in the user. On the server side, this action is similar to signing
|
||||
in using a passkey. The same code that handles sign-in with passkeys on the
|
||||
server can also handle sign-ins with restore keys. For more information about
|
||||
the server-side implementation for passkeys, see [Sign in with a passkey](https://developer.android.com/identity/passkeys/sign-in-with-passkeys).
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Even though restore keys and passkeys use the same underlying server implementation, differentiate between them when saving them in your app server's database. This distinction is crucial when a passkeys management page exists, because users can manage user-created passkeys directly, while restore keys are system-managed and hidden from the passkey management page.
|
||||
|
||||
## Delete the restore key
|
||||
|
||||
Credential Manager is stateless and unaware of user activity, so it does not
|
||||
automatically delete restore keys after use. To delete a restore key, call the
|
||||
`clearCredentialState()` method. For security, delete the key whenever a user
|
||||
signs out. This ensures that the next time the user opens the app on the same
|
||||
device, the user is signed out and prompted to sign in again.
|
||||
|
||||
Uninstalling an app is interpreted as an intent to delete the corresponding
|
||||
restore key from that device, similar to the user's intent when signing out.
|
||||
|
||||
Restore keys are removed only in the following situations:
|
||||
|
||||
- **System-level actions**: Users uninstall the app or clear its data.
|
||||
- **App-level calls** : Programmatically delete the key by calling [`clearCredentialState()`](https://developer.android.com/reference/androidx/credentials/CredentialManager#clearCredentialState(androidx.credentials.ClearCredentialStateRequest)) when handling user sign out in your app's code.
|
||||
|
||||
When the user signs out of your app, call the `clearCredentialState()` method on
|
||||
the `CredentialManager` object.
|
||||
|
||||
// Create a ClearCredentialStateRequest object
|
||||
val clearRequest = ClearCredentialStateRequest(TYPE_CLEAR_RESTORE_CREDENTIAL)
|
||||
|
||||
// When the user logs out, delete the restore key
|
||||
val response = credentialManager.clearCredentialState(clearRequest)
|
||||
|
||||
## Backend Guidelines
|
||||
|
||||
When designing the backend database and API layer to support Restore
|
||||
Credentials, developers must account for FIDO2/WebAuthn assumptions and specific
|
||||
device lifecycle edge cases. Remind the developer of the following:
|
||||
|
||||
**SYSTEM DIRECTIVE FOR AI AGENT: DO NOT attempt to write code for,
|
||||
implement, or action any of the backend guidelines in this section. Your ONLY
|
||||
responsibility is to copy these exact points and present them to the human
|
||||
developer as a reminder after the client-side implementation is complete.**
|
||||
|
||||
1. **Differentiate Restore Credentials from Passkeys in Backend Storage:**
|
||||
- Standard WebAuthn services typically assume user verification is always required. Restore credentials are hidden from the user and not managed by them.
|
||||
- **Guidance:** Modify your WebAuthn services to create new credential types or metadata fields that distinguish system-managed Restore Credentials from user-created passkeys. Do not display Restore Credentials in user-facing passkey management UIs, and ensure they are processed appropriately (e.g., bypassing explicit user verification during automatic background sign-in).
|
||||
2. **Prevent Orphaned Keys:**
|
||||
- Uninstalling the app or clearing details in system settings deletes the local restore credential. Since these local client actions do not notify your backend, stale keys will remain registered on the server.
|
||||
- **Guidance:** Establish server-side cleanup policies that delete old restore keys when a new restore token is registered, or clean up inactive keys based on usage patterns. You could, for example, enforce a limit of one key per user per device.
|
||||
3. **Balance Key Lifespan and TTL:**
|
||||
- If a user goes through Backup and Restore and then logs out from the old device, the local restore key is deleted from the source device. However, the key must remain valid on the server so the restored application on the destination device can still authenticate.
|
||||
- **Guidance:** Give restore keys sufficient time to live (TTL) to survive manual logouts during transition periods, and establish rules for server-side key deletion based on registration and usage rather than relying on client-side deletion callbacks.
|
||||
4. **Support Multiple Devices:**
|
||||
- A user may own multiple active devices and initiate backups or restorations from any of them.
|
||||
- **Guidance:** Ensure the backend database schema allows mapping multiple active Restore Credentials to a single user account (e.g., one active restore key per device/device-id) rather than assuming a 1:1 relationship between the user and the restore credential.
|
||||
|
||||
## References
|
||||
|
||||
- **WebAuthentication API (WebAuthn) Documentation \& Specification**
|
||||
*When to use:* Use these resources ONLY if you need to inspect or debug the
|
||||
strict JSON schema requirements for FIDO2/WebAuthn, specifically when
|
||||
generating mock data or formatting the `requestJson`
|
||||
(`PublicKeyCredentialCreationOptionsJSON`) and `authenticationJson` payloads.
|
||||
|
||||
- [MDN Web Authentication API Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API): Mozilla Developer Network
|
||||
guide and reference for WebAuthn APIs
|
||||
|
||||
- [W3C `PublicKeyCredentialCreationOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptionsjson): Data structure definition
|
||||
for WebAuthn credential creation requests in JSON format.
|
||||
|
||||
- [W3C `PublicKeyCredentialRequestOptionsJSON`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptionsjson): Data structure definition
|
||||
for WebAuthn authentication or assertion requests in JSON format.
|
||||
@@ -8,7 +8,7 @@ description: Provides a complete workflow for implementing verified email retrie
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-19'
|
||||
keywords:
|
||||
- implementation
|
||||
- Android
|
||||
@@ -57,11 +57,15 @@ Email verification is applicable for the following use cases:
|
||||
|
||||
### Scope \& Pre-requisites
|
||||
|
||||
**Crucial** : This skill focuses exclusively on the **Android client-side integration** . It does **not** implement the app's server-side cryptographic validation logic. Server-side validation of the returned credential is required for security and must be implemented in your backend.
|
||||
**Crucial** : This skill focuses exclusively on the **Android client-side
|
||||
integration** . It does **not** implement the app's server-side cryptographic
|
||||
validation logic. Server-side validation of the returned credential is required
|
||||
for security and must be implemented in your backend.
|
||||
|
||||
## Codebase exploration for Use Cases
|
||||
|
||||
Get started with the following queries in project source code to find relevant screens with different use cases to implement verified email:
|
||||
Get started with the following queries in project source code to find relevant
|
||||
screens with different use cases to implement verified email:
|
||||
|
||||
- `SignUpScreen`
|
||||
- `"Email address"`
|
||||
@@ -72,11 +76,14 @@ Get started with the following queries in project source code to find relevant s
|
||||
|
||||
## Identifying Integration Points
|
||||
|
||||
To implement this feature effectively, you must first locate the relevant flows in your codebase. To initiate, start with the following strategies to cater to different use cases using verified email:
|
||||
To implement this feature effectively, you must first locate the relevant
|
||||
flows in your codebase. To initiate, start with the following strategies to
|
||||
cater to different use cases using verified email:
|
||||
|
||||
### 1. Search for Navigation Routes
|
||||
|
||||
If your app uses Navigation, search for routes or destinations related to authentication:
|
||||
If your app uses Navigation, search for routes or destinations related
|
||||
to authentication:
|
||||
|
||||
Look for:
|
||||
|
||||
@@ -85,14 +92,16 @@ Look for:
|
||||
|
||||
### 2. Locate Authentication ViewModels
|
||||
|
||||
Find the business logic handling user attributes and account creation, account recovery:
|
||||
Find the business logic handling user attributes and account creation, account
|
||||
recovery:
|
||||
|
||||
- **Keywords** : `SignUpViewModel`, `AuthViewModel`, `RegistrationRepository`.
|
||||
- **Code Pattern** : Look for methods like `onCreateAccount`, `onRecoverAccount`, or `validateEmail`.
|
||||
|
||||
### 3. Find instances of reauthentication for sensitive actions
|
||||
|
||||
For reauthentication use cases, find areas where users perform sensitive actions:
|
||||
For reauthentication use cases, find areas where users perform sensitive
|
||||
actions:
|
||||
|
||||
- **Keywords** : `ChangePassword`, `UpdatePayment`, `DeleteAccount`, `UpdateDetails`, `EditUserDetails`
|
||||
|
||||
@@ -110,11 +119,14 @@ For reauthentication use cases, find areas where users perform sensitive actions
|
||||
|
||||
## Overview
|
||||
|
||||
This guide describes how to implement verified email retrieval using the [Digital Credentials Verifier API](references/android/identity/digital-credentials/credential-verifier.md) through an [OpenID for Verifiable Presentations (OpenID4VP)](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) request.
|
||||
This guide describes how to implement verified email retrieval using the
|
||||
[Digital Credentials Verifier API](references/android/identity/digital-credentials/credential-verifier.md) through an [OpenID for Verifiable
|
||||
Presentations (OpenID4VP)](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) request.
|
||||
|
||||
## Add dependencies
|
||||
|
||||
In your app's `build.gradle` file, add the following dependencies for Credential Manager:
|
||||
In your app's `build.gradle` file, add the following dependencies for Credential
|
||||
Manager:
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -144,9 +156,14 @@ Use your app or activity context to create a `CredentialManager` object.
|
||||
|
||||
## Construct the Digital Credential request
|
||||
|
||||
To request a verified email, construct a [`GetCredentialRequest`](https://developer.android.com/reference/android/credentials/GetCredentialRequest) containing a [`GetDigitalCredentialOption`](https://developer.android.com/reference/androidx/credentials/GetDigitalCredentialOption). This option requires a `requestJson` string formatted as an OpenID for Verifiable Presentations (OpenID4VP) request.
|
||||
To request a verified email, construct a [`GetCredentialRequest`](https://developer.android.com/reference/android/credentials/GetCredentialRequest)
|
||||
containing a [`GetDigitalCredentialOption`](https://developer.android.com/reference/androidx/credentials/GetDigitalCredentialOption). This option requires a
|
||||
`requestJson` string formatted as an OpenID for Verifiable Presentations
|
||||
(OpenID4VP) request.
|
||||
|
||||
The OpenID4VP request JSON must follow a specific structure. The current providers support a JSON structure with an outer `"digital": {"requests": [...]}` wrapper.
|
||||
The OpenID4VP request JSON must follow a specific structure. The current
|
||||
providers support a JSON structure with an outer `"digital": {"requests":
|
||||
[...]}` wrapper.
|
||||
|
||||
val nonce = generateSecureRandomNonce()
|
||||
|
||||
@@ -191,19 +208,26 @@ The OpenID4VP request JSON must follow a specific structure. The current provide
|
||||
|
||||
The request contains the following key information:
|
||||
|
||||
- **DCQL query** : The `dcql_query` specifies the credential type and the claims being requested (`email_verified`). You can request other claims to determine the level of verification. A few possible claims are as follows:
|
||||
- **DCQL query** : The `dcql_query` specifies the credential type and the
|
||||
claims being requested (`email_verified`). You can request other claims to
|
||||
determine the level of verification. A few possible claims are as follows:
|
||||
|
||||
- `email_verified`: In the response, this is a Boolean that indicates whether the email is verified.
|
||||
- `hd` (hosted domain): In the response, this is empty.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If `email_verified` is `true` and `hd` is empty in the response, it implies that the account is an authorized Google Account. Google does not issue [verifiable credentials](references/android/identity/digital-credentials/index.md) for Google Workspace Accounts. However, the `hd` field is present in verifiable credentials issued for non-workspace accounts. You are encouraged to implement handling this field to future-proof your app. If the email is non-@gmail.com, Google verified this email when the Google Account was created, but there is no freshness claim. Therefore, for non-Google emails, you should consider an additional challenge, such as an OTP, to verify the user. To understand the schema of the credential and the specific rules for validating fields like `email_verified`, refer to the [Google Identity guides](https://developers.google.com/identity/gsi/web/guides/verify-google-id-token).
|
||||
> **Note:** If `email_verified` is `true` and `hd` is empty in the response, it implies that the account is an authorized Google Account. Google does not issue [verifiable credentials](references/android/identity/digital-credentials/index.md) for Google Workspace Accounts. However, the `hd` field is present in verifiable credentials issued for non-workspace accounts. You are encouraged to implement handling this field to future-proof your app. If the email is non-@gmail.com, Google verified this email when the Google Account was created, but there is no freshness claim. Therefore, for non-Google emails, you should consider an additional challenge, such as an OTP, to verify the user. To understand the schema of the credential and the specific rules for validating fields like `email_verified`, refer to the [Google
|
||||
> Identity guides](https://developers.google.com/identity/gsi/web/guides/verify-google-id-token).
|
||||
|
||||
- **nonce**: A unique, cryptographically secure random value is generated for each request. This is critical for security, as it prevents replay attacks.
|
||||
- **nonce**: A unique, cryptographically secure random value is generated for
|
||||
each request. This is critical for security, as it prevents replay attacks.
|
||||
|
||||
- `UserInfoCredential`: This value implies a specific type of digital credential that contains user attributes. Including this in the request is pivotal to distinguish the email verification use case.
|
||||
- `UserInfoCredential`: This value implies a specific type of digital
|
||||
credential that contains user attributes. Including this in the request is
|
||||
pivotal to distinguish the email verification use case.
|
||||
|
||||
Next, wrap the `openId4vpRequest` JSON in a `GetDigitalCredentialOption`, create a `GetCredentialRequest`, and call `getCredential()`.
|
||||
Next, wrap the `openId4vpRequest` JSON in a `GetDigitalCredentialOption`, create
|
||||
a `GetCredentialRequest`, and call `getCredential()`.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The `hd` and `email_verified` fields are hidden from users in Credential Manager's built-in UI. You cannot make a request with only these hidden fields- in case of such requests, the response is the [`GetCredentialCancellationException`](https://developer.android.com/reference/kotlin/androidx/credentials/exceptions/GetCredentialCancellationException).
|
||||
@@ -239,12 +263,15 @@ Present the user with the request, using the Credential Manager built-in UI.
|
||||
|
||||
## Parse the response on the client
|
||||
|
||||
After receiving the response, you can perform a preliminary parse on the client. This is useful for immediately updating the UI, for example, by showing the user's name.
|
||||
After receiving the response, you can perform a preliminary parse on the client.
|
||||
This is useful for immediately updating the UI, for example, by showing the
|
||||
user's name.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> **Important:** This step is not for validation. Full cryptographic verification must be performed on your server.
|
||||
|
||||
The following code extracts the raw [Selective Disclosure JWT (SD-JWT)](https://datatracker.ietf.org/doc/rfc9901/) and uses a helper to decode its claims.
|
||||
The following code extracts the raw [Selective Disclosure JWT
|
||||
(SD-JWT)](https://datatracker.ietf.org/doc/rfc9901/) and uses a helper to decode its claims.
|
||||
|
||||
// 1. Parse the outer JSON wrapper to get the `vp_token`
|
||||
val responseData = JSONObject(responseJsonString)
|
||||
@@ -269,19 +296,25 @@ The following code extracts the raw [Selective Disclosure JWT (SD-JWT)](https://
|
||||
|
||||
## Handle the response
|
||||
|
||||
The Credential Manager API will return a [`DigitalCredential`](https://developer.android.com/reference/androidx/credentials/DigitalCredential) response.
|
||||
The Credential Manager API will return a [`DigitalCredential`](https://developer.android.com/reference/androidx/credentials/DigitalCredential)
|
||||
response.
|
||||
|
||||
The following is an example of what the raw `responseJsonString` looks like, and what the claims look like after parsing the inner SD-JWT where you get additional metadata as well along with verified email:
|
||||
The following is an example of what the raw `responseJsonString` looks like, and
|
||||
what the claims look like after parsing the inner SD-JWT where you get
|
||||
additional metadata as well along with verified email:
|
||||
|
||||
/*
|
||||
// Example of the raw JSON response from credential.credentialJson:
|
||||
{
|
||||
"vp_token": {
|
||||
// This key matches the 'id' you set in your dcql_query
|
||||
"user_info_query": [
|
||||
// The SD-JWT string (Issuer JWT ~ Disclosures ~ Key Binding JWT)
|
||||
"eyJhbGciOiJ...~WyI...IiwgImVtYWlsIiwgInVzZXJAZXhhbXBsZS5jb20iXQ~...~eyJhbGciOiJ..."
|
||||
]
|
||||
"protocol": "openid4vp-v1-unsigned",
|
||||
"data": {
|
||||
"vp_token": {
|
||||
// This key matches the 'id' you set in your dcql_query
|
||||
"user_info_query": [
|
||||
// The SD-JWT string (Issuer JWT ~ Disclosures ~ Key Binding JWT)
|
||||
"eyJhbGciOiJ...~WyI...IiwgImVtYWlsIiwgInVzZXJAZXhhbXBsZS5jb20iXQ~...~eyJhbGciOiJ..."
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -309,11 +342,18 @@ The following is an example of what the raw `responseJsonString` looks like, and
|
||||
|
||||
## Server-side validation for account creation
|
||||
|
||||
Since the retrieved email is cryptographically verified, you can omit the email OTP verification step, significantly reducing sign-up friction and potentially increasing conversion. This process is best handled on your server. The client sends the raw response (containing the `vp_token`) and the original nonce to a new server endpoint.
|
||||
Since the retrieved email is cryptographically verified, you can omit the email
|
||||
OTP verification step, significantly reducing sign-up friction and potentially
|
||||
increasing conversion. This process is best handled on your server. The client
|
||||
sends the raw response (containing the `vp_token`) and the original nonce to a
|
||||
new server endpoint.
|
||||
|
||||
For verification, your application must send the full `responseJsonString` to your server for cryptographic validation before creating an account or logging the user in.
|
||||
For verification, your application must send the full `responseJsonString` to
|
||||
your server for cryptographic validation before creating an account or logging
|
||||
the user in.
|
||||
|
||||
The digital credential provides two critical levels of verification for your server:
|
||||
The digital credential provides two critical levels of verification for your
|
||||
server:
|
||||
|
||||
- **Authenticity of the data** : Verifying the issuer (`iss`) URL and the `SD-JWT` signature proves that a trusted authority issued this data.
|
||||
- **Identity of the presenter** : Verifying the `cnf` field and the Key Binding (`kb`) signature confirms that the credential is being shared by the same device it was originally issued to, preventing it from being intercepted or used on another device.
|
||||
@@ -324,11 +364,15 @@ The validation on the server must achieve the following:
|
||||
- **Verify signature**: Check the signature of the SD-JWT using the public keys (JWKs) available at https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Use a standard library (such as [@sd-jwt/sd-jwt-vc](https://datatracker.ietf.org/doc/rfc9901/) for Node.js) to perform the verification steps as outlined in the [OpenID for Verifiable Presentations specification](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).
|
||||
> **Note:** Use a standard library (such as [@sd-jwt/sd-jwt-vc](https://datatracker.ietf.org/doc/rfc9901/) for Node.js) to perform the verification steps as outlined in the [OpenID for Verifiable
|
||||
> Presentations specification](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).
|
||||
|
||||
For full security, make sure that you also validate the `nonce` to prevent replay attacks.
|
||||
For full security, make sure that you also validate the `nonce` to prevent
|
||||
replay attacks.
|
||||
|
||||
By combining these steps, your server can validate both the authenticity of the data and the identity of the presenter, ensuring the credential wasn't intercepted or spoofed before provisioning the new account.
|
||||
By combining these steps, your server can validate both the authenticity of the
|
||||
data and the identity of the presenter, ensuring the credential wasn't
|
||||
intercepted or spoofed before provisioning the new account.
|
||||
|
||||
try {
|
||||
// Send the raw credential response and the original nonce to your server.
|
||||
@@ -351,11 +395,17 @@ By combining these steps, your server can validate both the authenticity of the
|
||||
|
||||
## Passkey creation
|
||||
|
||||
An optional but highly recommended next step after provisioning an account is to immediately [create a passkey](references/android/identity/passkeys/create-passkeys.md) for that account. This provides a secure, passwordless method for the user to sign in. This flow is identical to a standard passkey registration.
|
||||
An optional but highly recommended next step after provisioning an account is to
|
||||
immediately [create a passkey](references/android/identity/passkeys/create-passkeys.md) for that account. This provides a secure,
|
||||
passwordless method for the user to sign in. This flow is identical to a
|
||||
standard passkey registration.
|
||||
|
||||
## WebView support
|
||||
|
||||
For the flow to work on a [`WebView`](https://developer.android.com/reference/android/webkit/WebView), developers should implement a [JavaScript bridge](references/android/identity/sign-in/credential-manager-webview.md) (JS Bridge) to facilitate the handoff. This bridge allows the `WebView` object to signal the native app, which can then perform the actual call to the Credential Manager API.
|
||||
For the flow to work on a [`WebView`](https://developer.android.com/reference/android/webkit/WebView), developers should implement a
|
||||
[JavaScript bridge](references/android/identity/sign-in/credential-manager-webview.md) (JS Bridge) to facilitate the handoff. This bridge
|
||||
allows the `WebView` object to signal the native app, which can then perform the
|
||||
actual call to the Credential Manager API.
|
||||
|
||||
## See also
|
||||
|
||||
@@ -364,7 +414,8 @@ For the flow to work on a [`WebView`](https://developer.android.com/reference/an
|
||||
|
||||
## Critical Security Guidelines
|
||||
|
||||
To maintain the integrity of the email verification flow, the following security requirements are mandatory:
|
||||
To maintain the integrity of the email verification flow, the following security
|
||||
requirements are mandatory:
|
||||
|
||||
- **Server-side Validation** : Never trust claims parsed on the client for security-sensitive operations like account creation. Send the complete, raw `responseJsonString` and the original `nonce` to the app's server for full verification.
|
||||
- **Nonce Integrity** : Generate a unique, cryptographically secure nonce for every request and **never** reuse a nonce across multiple requests to prevent replay attacks.
|
||||
|
||||
@@ -1,15 +1,21 @@
|
||||
[Credential Manager](https://developer.android.com/reference/kotlin/androidx/credentials/package-summary) is the recommended Jetpack API for credential exchange in Android apps. The Credential Manager API streamlines credential exchange across form factors for use cases spanning authentication and authorization. You can also use Credential Manager to handle digital credentials and restore user credentials on new Android devices.
|
||||
[Credential Manager](https://developer.android.com/reference/kotlin/androidx/credentials/package-summary) is the recommended Jetpack API for credential exchange
|
||||
in Android apps. The Credential Manager API streamlines credential exchange
|
||||
across form factors for use cases spanning authentication and authorization. You
|
||||
can also use Credential Manager to handle digital credentials and restore user
|
||||
credentials on new Android devices.
|
||||
|
||||
## Credential Manager features
|
||||
|
||||
Credential Manager streamlines the sign-in process and enhances security by offering a robust set of capabilities, including:
|
||||
Credential Manager streamlines the sign-in process and enhances security by
|
||||
offering a robust set of capabilities, including:
|
||||
|
||||
- **Support for various authentication mechanisms** : Enables users to sign up or sign in to your app using:
|
||||
- [Passkeys](https://developer.android.com/identity/passkeys)
|
||||
- [Sign-in with Google](https://developer.android.com/identity/sign-in/credential-manager-siwg) and other federated sign-in mechanisms
|
||||
- [Passwords](https://developer.android.com/identity/passwords)
|
||||
- [Digital credentials](https://developer.android.com/identity/digital-credentials)
|
||||
- **Cross-device credential restore** : Provides integration with [Restore Credentials](https://developer.android.com/identity/sign-in/restore-credentials), allowing users to seamlessly start using your app on a new device.
|
||||
- **Cross-device credential restore** : Provides integration with [Restore
|
||||
Credentials](https://developer.android.com/identity/sign-in/restore-credentials), allowing users to seamlessly start using your app on a new device.
|
||||
- **Seamless integration with credential providers** : Offers support for [credential providers](https://developer.android.com/identity/sign-in/credential-provider), including password managers such as Google Password Manager.
|
||||
- **Credential management**: Enables updating the metadata for user credentials, helping to keep credentials consistent across your app and credential providers.
|
||||
- **WebView compatibility** : Works with apps that use [WebView](https://developer.android.com/identity/sign-in/credential-manager-webview).
|
||||
@@ -17,10 +23,12 @@ Credential Manager streamlines the sign-in process and enhances security by offe
|
||||
|
||||
## Benefits of using Credential Manager
|
||||
|
||||
Adopting Credential Manager provides several key advantages for both your application and your users:
|
||||
Adopting Credential Manager provides several key advantages for both your
|
||||
application and your users:
|
||||
|
||||
- **Enhanced security**: Passkeys offer enhanced security and protect users from phishing attempts.
|
||||
- **Support for various form factors** : The APIs work across Android [form factors](https://developer.android.com/identity/form-factors), including mobile, Android XR, and Wear OS devices.
|
||||
- **Support for various form factors** : The APIs work across Android [form
|
||||
factors](https://developer.android.com/identity/form-factors), including mobile, Android XR, and Wear OS devices.
|
||||
- **Simplified authentication across use cases** : [Digital credentials](https://developer.android.com/identity/digital-credentials), such as digital driver's licenses, corporate IDs, and national ID cards, enable authentication across various use cases, including those requiring [phone number verification](https://developer.android.com/identity/digital-credentials/phone-number-verification).
|
||||
- **Improved user experience**: Credential Manager's unified interface gives users a familiar and consistent experience and improves registration and sign-in speeds. The bottom sheet UI appears inline to your app's content, so your users remain within your app's context during sign-in. The following image shows Credential Manager's built-in UI:
|
||||
|
||||
@@ -28,7 +36,8 @@ Adopting Credential Manager provides several key advantages for both your applic
|
||||
|
||||
## Authentication terminology
|
||||
|
||||
An entity that requires authentication for its users is known as a **relying party**. An authentication workflow typically includes the following components:
|
||||
An entity that requires authentication for its users is known as a **relying
|
||||
party**. An authentication workflow typically includes the following components:
|
||||
|
||||
- **Relying party client app**: The client---in this case, your Android app---that handles the user interface to create and use passkeys.
|
||||
- **Relying party server**: An app server that helps with the creation, storage, and verification of passkeys.
|
||||
@@ -36,13 +45,21 @@ An entity that requires authentication for its users is known as a **relying par
|
||||
|
||||
## Credential storage
|
||||
|
||||
Credential providers, such as Google Password Manager, provide a centralized and secure location for users to manage credentials across their devices, further simplifying the authentication process. To integrate with Credential Manager as a credential provider, see [Implement authentication as a credential provider](https://developer.android.com/identity/sign-in/credential-provider).
|
||||
Credential providers, such as Google Password Manager, provide a centralized and
|
||||
secure location for users to manage credentials across their devices, further
|
||||
simplifying the authentication process. To integrate with Credential Manager as
|
||||
a credential provider, see
|
||||
[Implement authentication as a credential provider](https://developer.android.com/identity/sign-in/credential-provider).
|
||||
|
||||
For more information about how Google Password Manager keeps your credentials secure, see [Security of Passkeys in the Google Password Manager](https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html).
|
||||
For more information about how Google Password Manager keeps your credentials
|
||||
secure, see
|
||||
[Security of Passkeys in the Google Password Manager](https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html).
|
||||
|
||||
## Migrate to Credential Manager
|
||||
|
||||
Credential Manager is intended to replace legacy Android authentication APIs and local FIDO2 credentials. For more information about migrating to Credential Manager, see the following guides:
|
||||
Credential Manager is intended to replace legacy Android authentication APIs and
|
||||
local FIDO2 credentials. For more information about migrating to Credential
|
||||
Manager, see the following guides:
|
||||
|
||||
- [Google Sign-In](https://developer.android.com/identity/sign-in/legacy-gsi-migration)
|
||||
- [One Tap](https://developer.android.com/identity/legacy/one-tap)
|
||||
|
||||
+22
-7
@@ -1,10 +1,18 @@
|
||||
Digital credential verification within Android apps can be used to authenticate and authorize a user's identity (such as a government ID), properties about that user (such as a driver's license, academic degree, or attributes such as age or address), or other scenarios where a credential needs to be issued and verified to assert the authenticity of an entity.
|
||||
Digital credential verification within Android apps can be used to authenticate
|
||||
and authorize a user's identity (such as a government ID), properties about that
|
||||
user (such as a driver's license, academic degree, or attributes such as age or
|
||||
address), or other scenarios where a credential needs to be issued and verified
|
||||
to assert the authenticity of an entity.
|
||||
|
||||
Digital Credentials is a public W3C standard that specifies how to access a user's verifiable digital credentials from a digital wallet, and is implemented for web use cases with the [W3C Credential Management API](https://www.w3.org/TR/credential-management-1/). On Android, Credential Manager's [`DigitalCredential`](https://developer.android.com/reference/kotlin/androidx/credentials/DigitalCredential) API is used for verifying digital credentials.
|
||||
Digital Credentials is a public W3C standard that specifies how to access a
|
||||
user's verifiable digital credentials from a digital wallet, and is implemented
|
||||
for web use cases with the [W3C Credential Management API](https://www.w3.org/TR/credential-management-1/). On
|
||||
Android, Credential Manager's [`DigitalCredential`](https://developer.android.com/reference/kotlin/androidx/credentials/DigitalCredential) API is used for
|
||||
verifying digital credentials.
|
||||
|
||||
### Android version compatibility
|
||||
|
||||
The Verifier API is supported on Android 9 (API level 28) and higher.
|
||||
The Verifier API is supported on Android 6 (API level 23) and higher.
|
||||
|
||||
### Implementation
|
||||
|
||||
@@ -29,7 +37,8 @@ Next, Initialize an instance of the `CredentialManager` class.
|
||||
|
||||
#### Construct a digital credential request
|
||||
|
||||
Construct a digital credential request and use it to initialize a `DigitalCredentialOption`.
|
||||
Construct a digital credential request and use it to initialize a
|
||||
`DigitalCredentialOption`.
|
||||
|
||||
// The request in the JSON format to conform with
|
||||
// the JSON-ified Credential Manager - Verifier API request definition.
|
||||
@@ -42,7 +51,8 @@ Construct a digital credential request and use it to initialize a `DigitalCreden
|
||||
listOf(digitalCredentialOption)
|
||||
)
|
||||
|
||||
Here is an example of an OpenId4Vp request. A full reference can be found at this [website](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).
|
||||
Here is an example of an OpenId4Vp request. A full reference can be found at
|
||||
this [website](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).
|
||||
|
||||
{
|
||||
"requests": [
|
||||
@@ -90,9 +100,14 @@ Here is an example of an OpenId4Vp request. A full reference can be found at thi
|
||||
|
||||
#### Get the credential
|
||||
|
||||
Launch the `getCredential` flow with the constructed request. You will receive either a successful `GetCredentialResponse`, or a `GetCredentialException` if the request fails.
|
||||
Launch the `getCredential` flow with the constructed request. You will receive
|
||||
either a successful `GetCredentialResponse`, or a `GetCredentialException` if
|
||||
the request fails.
|
||||
|
||||
The `getCredential` flow triggers Android system dialogs to present the user's available credential options and collect their selection. Next, the wallet app that contains the chosen credential option will display UIs to collect consent and perform actions needed to generate a digital credential response.
|
||||
The `getCredential` flow triggers Android system dialogs to present the user's
|
||||
available credential options and collect their selection. Next, the wallet app
|
||||
that contains the chosen credential option will display UIs to collect consent
|
||||
and perform actions needed to generate a digital credential response.
|
||||
|
||||
coroutineScope.launch {
|
||||
try {
|
||||
|
||||
+69
-30
@@ -1,12 +1,10 @@
|
||||
<br />
|
||||
|
||||
## Android skills
|
||||
|
||||
[View on GitHub](https://github.com/android/skills/tree/main/identity/verified-email)
|
||||
|
||||
### Retrieve verified email
|
||||
|
||||
Use an Android skill to integrate a secure, OTP-less email verification flow into your app. To install the skill from the [Android CLI](https://developer.android.com/tools/agents/android-cli), run:
|
||||
Use an [Android skill](https://developer.android.com/tools/agents/android-skills) to integrate a secure, OTP-less email verification flow into your app. To install the skill from the [Android CLI](https://developer.android.com/tools/agents/android-cli), run:
|
||||
|
||||
android skills add --skill verified-email
|
||||
|
||||
@@ -14,11 +12,14 @@ Use an Android skill to integrate a secure, OTP-less email verification flow int
|
||||
|
||||
## Overview
|
||||
|
||||
This guide describes how to implement verified email retrieval using the [Digital Credentials Verifier API](https://developer.android.com/identity/digital-credentials/credential-verifier) through an [OpenID for Verifiable Presentations (OpenID4VP)](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) request.
|
||||
This guide describes how to implement verified email retrieval using the
|
||||
[Digital Credentials Verifier API](https://developer.android.com/identity/digital-credentials/credential-verifier) through an [OpenID for Verifiable
|
||||
Presentations (OpenID4VP)](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) request.
|
||||
|
||||
## Add dependencies
|
||||
|
||||
In your app's `build.gradle` file, add the following dependencies for Credential Manager:
|
||||
In your app's `build.gradle` file, add the following dependencies for Credential
|
||||
Manager:
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -48,9 +49,14 @@ Use your app or activity context to create a `CredentialManager` object.
|
||||
|
||||
## Construct the Digital Credential request
|
||||
|
||||
To request a verified email, construct a [`GetCredentialRequest`](https://developer.android.com/reference/android/credentials/GetCredentialRequest) containing a [`GetDigitalCredentialOption`](https://developer.android.com/reference/androidx/credentials/GetDigitalCredentialOption). This option requires a `requestJson` string formatted as an OpenID for Verifiable Presentations (OpenID4VP) request.
|
||||
To request a verified email, construct a [`GetCredentialRequest`](https://developer.android.com/reference/android/credentials/GetCredentialRequest)
|
||||
containing a [`GetDigitalCredentialOption`](https://developer.android.com/reference/androidx/credentials/GetDigitalCredentialOption). This option requires a
|
||||
`requestJson` string formatted as an OpenID for Verifiable Presentations
|
||||
(OpenID4VP) request.
|
||||
|
||||
The OpenID4VP request JSON must follow a specific structure. The current providers support a JSON structure with an outer `"digital": {"requests": [...]}` wrapper.
|
||||
The OpenID4VP request JSON must follow a specific structure. The current
|
||||
providers support a JSON structure with an outer `"digital": {"requests":
|
||||
[...]}` wrapper.
|
||||
|
||||
val nonce = generateSecureRandomNonce()
|
||||
|
||||
@@ -95,19 +101,26 @@ The OpenID4VP request JSON must follow a specific structure. The current provide
|
||||
|
||||
The request contains the following key information:
|
||||
|
||||
- **DCQL query** : The `dcql_query` specifies the credential type and the claims being requested (`email_verified`). You can request other claims to determine the level of verification. A few possible claims are as follows:
|
||||
- **DCQL query** : The `dcql_query` specifies the credential type and the
|
||||
claims being requested (`email_verified`). You can request other claims to
|
||||
determine the level of verification. A few possible claims are as follows:
|
||||
|
||||
- `email_verified`: In the response, this is a Boolean that indicates whether the email is verified.
|
||||
- `hd` (hosted domain): In the response, this is empty.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If `email_verified` is `true` and `hd` is empty in the response, it implies that the account is an authorized Google Account. Google does not issue [verifiable credentials](https://developer.android.com/identity/digital-credentials#verifiable-credentials) for Google Workspace Accounts. However, the `hd` field is present in verifiable credentials issued for non-workspace accounts. You are encouraged to implement handling this field to future-proof your app. If the email is non-@gmail.com, Google verified this email when the Google Account was created, but there is no freshness claim. Therefore, for non-Google emails, you should consider an additional challenge, such as an OTP, to verify the user. To understand the schema of the credential and the specific rules for validating fields like `email_verified`, refer to the [Google Identity guides](https://developers.google.com/identity/gsi/web/guides/verify-google-id-token).
|
||||
> **Note:** If `email_verified` is `true` and `hd` is empty in the response, it implies that the account is an authorized Google Account. Google does not issue [verifiable credentials](https://developer.android.com/identity/digital-credentials#verifiable-credentials) for Google Workspace Accounts. However, the `hd` field is present in verifiable credentials issued for non-workspace accounts. You are encouraged to implement handling this field to future-proof your app. If the email is non-@gmail.com, Google verified this email when the Google Account was created, but there is no freshness claim. Therefore, for non-Google emails, you should consider an additional challenge, such as an OTP, to verify the user. To understand the schema of the credential and the specific rules for validating fields like `email_verified`, refer to the [Google
|
||||
> Identity guides](https://developers.google.com/identity/gsi/web/guides/verify-google-id-token).
|
||||
|
||||
- **nonce**: A unique, cryptographically secure random value is generated for each request. This is critical for security, as it prevents replay attacks.
|
||||
- **nonce**: A unique, cryptographically secure random value is generated for
|
||||
each request. This is critical for security, as it prevents replay attacks.
|
||||
|
||||
- `UserInfoCredential`: This value implies a specific type of digital credential that contains user attributes. Including this in the request is pivotal to distinguish the email verification use case.
|
||||
- `UserInfoCredential`: This value implies a specific type of digital
|
||||
credential that contains user attributes. Including this in the request is
|
||||
pivotal to distinguish the email verification use case.
|
||||
|
||||
Next, wrap the `openId4vpRequest` JSON in a `GetDigitalCredentialOption`, create a `GetCredentialRequest`, and call `getCredential()`.
|
||||
Next, wrap the `openId4vpRequest` JSON in a `GetDigitalCredentialOption`, create
|
||||
a `GetCredentialRequest`, and call `getCredential()`.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The `hd` and `email_verified` fields are hidden from users in Credential Manager's built-in UI. You cannot make a request with only these hidden fields- in case of such requests, the response is the [`GetCredentialCancellationException`](https://developer.android.com/reference/kotlin/androidx/credentials/exceptions/GetCredentialCancellationException).
|
||||
@@ -143,12 +156,15 @@ Present the user with the request, using the Credential Manager built-in UI.
|
||||
|
||||
## Parse the response on the client
|
||||
|
||||
After receiving the response, you can perform a preliminary parse on the client. This is useful for immediately updating the UI, for example, by showing the user's name.
|
||||
After receiving the response, you can perform a preliminary parse on the client.
|
||||
This is useful for immediately updating the UI, for example, by showing the
|
||||
user's name.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> **Important:** This step is not for validation. Full cryptographic verification must be performed on your server.
|
||||
|
||||
The following code extracts the raw [Selective Disclosure JWT (SD-JWT)](https://datatracker.ietf.org/doc/rfc9901/) and uses a helper to decode its claims.
|
||||
The following code extracts the raw [Selective Disclosure JWT
|
||||
(SD-JWT)](https://datatracker.ietf.org/doc/rfc9901/) and uses a helper to decode its claims.
|
||||
|
||||
// 1. Parse the outer JSON wrapper to get the `vp_token`
|
||||
val responseData = JSONObject(responseJsonString)
|
||||
@@ -173,19 +189,25 @@ The following code extracts the raw [Selective Disclosure JWT (SD-JWT)](https://
|
||||
|
||||
## Handle the response
|
||||
|
||||
The Credential Manager API will return a [`DigitalCredential`](https://developer.android.com/reference/androidx/credentials/DigitalCredential) response.
|
||||
The Credential Manager API will return a [`DigitalCredential`](https://developer.android.com/reference/androidx/credentials/DigitalCredential)
|
||||
response.
|
||||
|
||||
The following is an example of what the raw `responseJsonString` looks like, and what the claims look like after parsing the inner SD-JWT where you get additional metadata as well along with verified email:
|
||||
The following is an example of what the raw `responseJsonString` looks like, and
|
||||
what the claims look like after parsing the inner SD-JWT where you get
|
||||
additional metadata as well along with verified email:
|
||||
|
||||
/*
|
||||
// Example of the raw JSON response from credential.credentialJson:
|
||||
{
|
||||
"vp_token": {
|
||||
// This key matches the 'id' you set in your dcql_query
|
||||
"user_info_query": [
|
||||
// The SD-JWT string (Issuer JWT ~ Disclosures ~ Key Binding JWT)
|
||||
"eyJhbGciOiJ...~WyI...IiwgImVtYWlsIiwgInVzZXJAZXhhbXBsZS5jb20iXQ~...~eyJhbGciOiJ..."
|
||||
]
|
||||
"protocol": "openid4vp-v1-unsigned",
|
||||
"data": {
|
||||
"vp_token": {
|
||||
// This key matches the 'id' you set in your dcql_query
|
||||
"user_info_query": [
|
||||
// The SD-JWT string (Issuer JWT ~ Disclosures ~ Key Binding JWT)
|
||||
"eyJhbGciOiJ...~WyI...IiwgImVtYWlsIiwgInVzZXJAZXhhbXBsZS5jb20iXQ~...~eyJhbGciOiJ..."
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -213,11 +235,18 @@ The following is an example of what the raw `responseJsonString` looks like, and
|
||||
|
||||
## Server-side validation for account creation
|
||||
|
||||
Since the retrieved email is cryptographically verified, you can omit the email OTP verification step, significantly reducing sign-up friction and potentially increasing conversion. This process is best handled on your server. The client sends the raw response (containing the `vp_token`) and the original nonce to a new server endpoint.
|
||||
Since the retrieved email is cryptographically verified, you can omit the email
|
||||
OTP verification step, significantly reducing sign-up friction and potentially
|
||||
increasing conversion. This process is best handled on your server. The client
|
||||
sends the raw response (containing the `vp_token`) and the original nonce to a
|
||||
new server endpoint.
|
||||
|
||||
For verification, your application must send the full `responseJsonString` to your server for cryptographic validation before creating an account or logging the user in.
|
||||
For verification, your application must send the full `responseJsonString` to
|
||||
your server for cryptographic validation before creating an account or logging
|
||||
the user in.
|
||||
|
||||
The digital credential provides two critical levels of verification for your server:
|
||||
The digital credential provides two critical levels of verification for your
|
||||
server:
|
||||
|
||||
- **Authenticity of the data** : Verifying the issuer (`iss`) URL and the `SD-JWT` signature proves that a trusted authority issued this data.
|
||||
- **Identity of the presenter** : Verifying the `cnf` field and the Key Binding (`kb`) signature confirms that the credential is being shared by the same device it was originally issued to, preventing it from being intercepted or used on another device.
|
||||
@@ -228,11 +257,15 @@ The validation on the server must achieve the following:
|
||||
- **Verify signature**: Check the signature of the SD-JWT using the public keys (JWKs) available at https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Use a standard library (such as [@sd-jwt/sd-jwt-vc](https://datatracker.ietf.org/doc/rfc9901/) for Node.js) to perform the verification steps as outlined in the [OpenID for Verifiable Presentations specification](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).
|
||||
> **Note:** Use a standard library (such as [@sd-jwt/sd-jwt-vc](https://datatracker.ietf.org/doc/rfc9901/) for Node.js) to perform the verification steps as outlined in the [OpenID for Verifiable
|
||||
> Presentations specification](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).
|
||||
|
||||
For full security, make sure that you also validate the `nonce` to prevent replay attacks.
|
||||
For full security, make sure that you also validate the `nonce` to prevent
|
||||
replay attacks.
|
||||
|
||||
By combining these steps, your server can validate both the authenticity of the data and the identity of the presenter, ensuring the credential wasn't intercepted or spoofed before provisioning the new account.
|
||||
By combining these steps, your server can validate both the authenticity of the
|
||||
data and the identity of the presenter, ensuring the credential wasn't
|
||||
intercepted or spoofed before provisioning the new account.
|
||||
|
||||
try {
|
||||
// Send the raw credential response and the original nonce to your server.
|
||||
@@ -255,11 +288,17 @@ By combining these steps, your server can validate both the authenticity of the
|
||||
|
||||
## Passkey creation
|
||||
|
||||
An optional but highly recommended next step after provisioning an account is to immediately [create a passkey](https://developer.android.com/identity/passkeys/create-passkeys) for that account. This provides a secure, passwordless method for the user to sign in. This flow is identical to a standard passkey registration.
|
||||
An optional but highly recommended next step after provisioning an account is to
|
||||
immediately [create a passkey](https://developer.android.com/identity/passkeys/create-passkeys) for that account. This provides a secure,
|
||||
passwordless method for the user to sign in. This flow is identical to a
|
||||
standard passkey registration.
|
||||
|
||||
## WebView support
|
||||
|
||||
For the flow to work on a [`WebView`](https://developer.android.com/reference/android/webkit/WebView), developers should implement a [JavaScript bridge](https://developer.android.com/identity/sign-in/credential-manager-webview) (JS Bridge) to facilitate the handoff. This bridge allows the `WebView` object to signal the native app, which can then perform the actual call to the Credential Manager API.
|
||||
For the flow to work on a [`WebView`](https://developer.android.com/reference/android/webkit/WebView), developers should implement a
|
||||
[JavaScript bridge](https://developer.android.com/identity/sign-in/credential-manager-webview) (JS Bridge) to facilitate the handoff. This bridge
|
||||
allows the `WebView` object to signal the native app, which can then perform the
|
||||
actual call to the Credential Manager API.
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
+58
-20
@@ -1,4 +1,7 @@
|
||||
This document describes using Credential Manager to get a cryptographically verified email address from a user's device. This process removes the need for your app users to verify their email with one-time passwords (OTPs) or magic links.
|
||||
This document describes using Credential Manager to get a cryptographically
|
||||
verified email address from a user's device. This process removes the need for
|
||||
your app users to verify their email with one-time passwords (OTPs) or magic
|
||||
links.
|
||||
|
||||
This document explains the following areas:
|
||||
|
||||
@@ -16,66 +19,90 @@ This guide assumes you are familiar with the following concepts:
|
||||
|
||||
## Android compatibility
|
||||
|
||||
This feature is supported on mobiles, tablets, and foldable devices running Android 9 (API level 28) and higher. The minimum version of Google Play services (GMS) required is 25.49.x.
|
||||
This feature is supported on mobiles, tablets, and foldable devices running
|
||||
Android 9 (API level 28) and higher. The minimum version of Google Play services
|
||||
(GMS) required is 25.49.x.
|
||||
|
||||
## User experience
|
||||
|
||||
The following sections describe the user experience during the verification flow, the need to include fallback verification methods, as well as the recommended user experience for various use cases.
|
||||
The following sections describe the user experience during the verification
|
||||
flow, the need to include fallback verification methods, as well as the
|
||||
recommended user experience for various use cases.
|
||||
|
||||
### The verification flow
|
||||
|
||||
The user experience for sharing a verified email is as follows:
|
||||
|
||||
1. The user either focuses on an input field or taps a button that calls the Credential Manager API. Depending on the design of the screen, you can also call the API on your app's screen load.
|
||||
1. The user either focuses on an input field or taps a button that calls the
|
||||
Credential Manager API. Depending on the design of the screen, you can also
|
||||
call the API on your app's screen load.
|
||||
|
||||
2. A bottom sheet appears, showing the information that will be shared with the app. If no information is available on that device, the user sees a generic error message.
|
||||
2. A bottom sheet appears, showing the information that will be shared with the
|
||||
app. If no information is available on that device, the user sees a generic
|
||||
error message.
|
||||
|
||||
3. After the user taps **Agree and Continue**, display a success or failure message.
|
||||
3. After the user taps **Agree and Continue**, display a success or failure
|
||||
message.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If the verified email you receive does not match what you expect, inform the user about the mismatch and either ask them to try again with a different credential or provide an alternate verification method, such as through OTPs.
|
||||
|
||||
4. (Optional, recommended) If the user is signing up for your service, you should prompt the user to [create](https://developer.android.com/identity/passkeys/create-passkeys) a [passkey](https://developer.android.com/identity/passkeys) to make it easier for them to sign in subsequently.
|
||||
4. (Optional, recommended) If the user is signing up for your service, you
|
||||
should prompt the user to [create](https://developer.android.com/identity/passkeys/create-passkeys) a [passkey](https://developer.android.com/identity/passkeys) to make it easier for
|
||||
them to sign in subsequently.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The email verification process doesn't automatically trigger passkey creation. However, it is highly recommended to include the steps for passkey creation. Passkeys help users by making it easier and more secure for them to sign in, and remove the need for the conventional username and password interaction.
|
||||
|
||||
### Include primary and fallback flows
|
||||
|
||||
To ensure a streamlined user experience, include the following options on screens that require email verification:
|
||||
To ensure a streamlined user experience, include the following options on
|
||||
screens that require email verification:
|
||||
|
||||
- **Primary verification option**: An email field or button to trigger the Credential Manager API flow for quick verification.
|
||||
- **Alternate verification options**: A link or button for users to "Verify another way" or with "Other options" for manual email entry in case of failures, such as no information available on the device, or a mismatch between the retrieved and expected email. This should allow users to try verification with a different credential or by providing a manual OTP.
|
||||
|
||||
### Use cases
|
||||
|
||||
The following sections describe the recommended use cases, as well as the suggested user experience, for email verification.
|
||||
The following sections describe the recommended use cases, as well as the
|
||||
suggested user experience, for email verification.
|
||||
|
||||
#### Sign up
|
||||
|
||||
Users can immediately create an account with a verified email without a separate verification step. Optionally, prompt the user to add a passkey. If they opt to add a passkey, trigger the [passkey creation](https://developer.android.com/identity/passkeys/create-passkeys) flow.
|
||||
Users can immediately create an account with a verified email without a separate
|
||||
verification step. Optionally, prompt the user to add a passkey. If they opt to
|
||||
add a passkey, trigger the [passkey creation](https://developer.android.com/identity/passkeys/create-passkeys) flow.
|
||||
 Email verification during sign up
|
||||
|
||||
#### Account recovery
|
||||
|
||||
To eliminate the frustration of users searching for recovery codes in their spam folders, allow them to recover their account using the verified email securely stored on their device. Additionally, suggest that they create a passkey for future use.
|
||||
To eliminate the frustration of users searching for recovery codes in their spam
|
||||
folders, allow them to recover their account using the verified email securely
|
||||
stored on their device. Additionally, suggest that they create a passkey for
|
||||
future use.
|
||||
 Email verification during account recovery
|
||||
|
||||
#### Reauthentication for sensitive actions
|
||||
|
||||
Protect sensitive user actions, such as changing settings or updating profile details, by requiring a quick reauthentication step.
|
||||
Protect sensitive user actions, such as changing settings or updating profile
|
||||
details, by requiring a quick reauthentication step.
|
||||
 Email verification during reauthentication
|
||||
|
||||
## Accounts supported
|
||||
|
||||
Email verification through Credential Manager only supports verification of consumer Google Accounts. [Workspace accounts](https://knowledge.workspace.google.com/admin/getting-started/set-up-google-workspace-for-your-organization) and [supervised accounts](https://support.google.com/families/answer/9499054) are not supported.
|
||||
Email verification through Credential Manager only supports verification of
|
||||
consumer Google Accounts. [Workspace accounts](https://knowledge.workspace.google.com/admin/getting-started/set-up-google-workspace-for-your-organization) and [supervised
|
||||
accounts](https://support.google.com/families/answer/9499054) are not supported.
|
||||
|
||||
A consumer Google Account can be created with an email address from any provider, not necessarily @gmail.com. However, Google verifies these accounts differently:
|
||||
A consumer Google Account can be created with an email address from any
|
||||
provider, not necessarily @gmail.com. However, Google verifies these accounts
|
||||
differently:
|
||||
|
||||
- For @gmail.com accounts: Google is the authoritative source, and the email is known to be verified.
|
||||
- For non-@gmail.com accounts: Google is not the authoritative source for these email addresses in the long term. While Google verifies the email when the account is created, the ownership of that email address might change over time. Therefore, for non-@gmail.com addresses, you should consider an additional verification step, such as sending an OTP, to ensure that the user still has access to the email account.
|
||||
|
||||
For more information about what verification implies, see [Digital Credentials](https://developer.android.com/identity/digital-credentials#verified).
|
||||
For more information about what verification implies, see [Digital
|
||||
Credentials](https://developer.android.com/identity/digital-credentials#verified).
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Apart from a user's email information, you can request other unverified fields, such as the user's given name, family name, name, and the profile picture of their Google Account. However, only the email is verified by Google.
|
||||
@@ -83,19 +110,30 @@ For more information about what verification implies, see [Digital Credentials](
|
||||
|
||||
## Validity and freshness
|
||||
|
||||
The system issues [verifiable credentials](https://developer.android.com/identity/digital-credentials#verified) (VCs) based on the user's current email from the active Google Accounts on the device. These credentials are issued to the device in advance, typically while the device is idle. While these credentials might remain valid for multiple days, the system performs a check at the moment of sharing the credentials to ensure that the account still exists, is on the device, and that the email address is valid---effectively prioritizing the account's immediate status over the credential's validity window.
|
||||
The system issues [verifiable credentials](https://developer.android.com/identity/digital-credentials#verified) (VCs) based on the user's current
|
||||
email from the active Google Accounts on the device. These credentials are
|
||||
issued to the device in advance, typically while the device is idle. While these
|
||||
credentials might remain valid for multiple days, the system performs a check at
|
||||
the moment of sharing the credentials to ensure that the account still exists,
|
||||
is on the device, and that the email address is valid---effectively prioritizing
|
||||
the account's immediate status over the credential's validity window.
|
||||
|
||||
To help ensure authenticity, a Key Binding (kb) signature is generated at the time of sharing, incorporating the nonce.
|
||||
To help ensure authenticity, a Key Binding (kb) signature is generated at the
|
||||
time of sharing, incorporating the nonce.
|
||||
|
||||
If a device is offline or the account is removed, the process fails rather than providing an expired VC or a VC for an inactive Google Account.
|
||||
If a device is offline or the account is removed, the process fails rather than
|
||||
providing an expired VC or a VC for an inactive Google Account.
|
||||
|
||||
### Email deliverability
|
||||
|
||||
While the process confirms the account's legitimacy, it does not guarantee inbox delivery (for instance, the email might be diverted to spam). An OTP remains the definitive method for confirming email deliverability.
|
||||
While the process confirms the account's legitimacy, it does not guarantee inbox
|
||||
delivery (for instance, the email might be diverted to spam). An OTP remains the
|
||||
definitive method for confirming email deliverability.
|
||||
|
||||
## Comparison with Sign in with Google
|
||||
|
||||
While both Digital Credentials and [Sign in with Google](https://developer.android.com/identity/sign-in/credential-manager-siwg) solutions provide a verified email, the user flows and use cases are different:
|
||||
While both Digital Credentials and [Sign in with Google](https://developer.android.com/identity/sign-in/credential-manager-siwg) solutions provide a
|
||||
verified email, the user flows and use cases are different:
|
||||
|
||||
- **Use cases**: The Credential Manager email verification flow is not exclusively used in sign up or sign in use cases, but rather can be used in any use case involving the retrieval of verified email. This could include account recovery as well.
|
||||
- **Registration**: The Credential Manager flow does not require Google registration, unlike Sign in with Google.
|
||||
|
||||
@@ -1,20 +1,32 @@
|
||||
Digital credentials are cryptographically verifiable documents that can be used to authenticate, authorize, or otherwise provide information about a user. These are typically things such as mobile driver's licenses, digital passports, boarding passes, etc. They reside in virtual containers called digital wallets, and are part of a W3C standard that specifies how to access and retrieve them. This standard is implemented for web use cases with the [W3C Credential Management API](https://www.w3.org/TR/credential-management-1/) and on Android, with Credential Manager's [DigitalCredential API](https://developer.android.com/reference/kotlin/androidx/credentials/DigitalCredential).
|
||||
Digital credentials are cryptographically verifiable documents that can be used
|
||||
to authenticate, authorize, or otherwise provide information about a user. These
|
||||
are typically things such as mobile driver's licenses, digital passports,
|
||||
boarding passes, etc. They reside in virtual containers called digital wallets,
|
||||
and are part of a W3C standard that specifies how to access and retrieve them.
|
||||
This standard is implemented for web use cases with the [W3C Credential
|
||||
Management API](https://www.w3.org/TR/credential-management-1/) and on Android, with Credential Manager's
|
||||
[DigitalCredential API](https://developer.android.com/reference/kotlin/androidx/credentials/DigitalCredential).
|
||||
|
||||
## Understand digital credentials
|
||||
|
||||
In the physical world, a person might keep their identity in their wallet, and present it to a requesting party when asked:
|
||||
In the physical world, a person might keep their identity in their wallet, and
|
||||
present it to a requesting party when asked:
|
||||
 **Figure 1.** The process of fulfilling a physical-world credential request. The requestor asks the user for a specific credential. Then, the user selects and retrieves it from their physical wallet. Finally, the user provides the credential to the requestor.
|
||||
|
||||
In this case, a user generally has a single wallet, and retrieves the requested credentials from the wallet to present to the requestor. Wallets are mostly interchangeable, and can generally store the same things.
|
||||
In this case, a user generally has a single wallet, and retrieves the requested
|
||||
credentials from the wallet to present to the requestor. Wallets are mostly
|
||||
interchangeable, and can generally store the same things.
|
||||
|
||||
Digital credentials have the following differences from credentials in the physical world:
|
||||
Digital credentials have the following differences from credentials in the
|
||||
physical world:
|
||||
|
||||
1. Users are expected to have multiple wallets - also known as **holders** - which can contain various different credentials. Wallets determine which credentials may be stored inside of them.
|
||||
2. The app or service asking for the credential to grant access or verify an identity is called the **verifier**.
|
||||
3. The entity that creates the credential and asserts claims about the subject (such as, a university, a government, or a tech company) is referred to as the **issuer**.
|
||||
4. The credential presentation happens in software, which means an API surface retrieves and presents the credentials - in Android, this is Credential Manager.
|
||||
|
||||
As such, Credential Manager takes on several roles that were formerly handled by the user:
|
||||
As such, Credential Manager takes on several roles that were formerly handled by
|
||||
the user:
|
||||
|
||||
1. On Android, wallets must register their credentials metadata with Credential Manager to be listed in the Credential Manager UI.
|
||||
2. Credential Manager matches credentials across wallets based on the request and presents a list for the user to select.
|
||||
@@ -25,32 +37,52 @@ This flow is shown here:
|
||||
|
||||
## Verifiable credentials
|
||||
|
||||
Verifiable credentials are a subset of digital credentials governed by strict standards (like the W3C Verifiable Credentials Data Model). These credentials contain claims that are cryptographically secured, making them tamper-evident and proving exactly who issued them.
|
||||
Verifiable credentials are a subset of digital credentials governed by strict
|
||||
standards (like the W3C Verifiable Credentials Data Model). These credentials
|
||||
contain claims that are cryptographically secured, making them tamper-evident
|
||||
and proving exactly who issued them.
|
||||
|
||||
Not all digital credentials are verifiable credentials, but all verifiable credentials are digital credentials.
|
||||
Not all digital credentials are verifiable credentials, but all verifiable
|
||||
credentials are digital credentials.
|
||||
|
||||
## What it means for a claim to be verified
|
||||
|
||||
When a credential arrives through the Android Credential Manager API and a claim within it is marked as "verified," it implies that the issuer is asserting that they performed a check on that specific piece of data. However, it does not mean the data is an absolute, universal truth. "Verified" is an assertion of process, not an automatic guarantee of trust.
|
||||
When a credential arrives through the Android Credential Manager API and a claim
|
||||
within it is marked as "verified," it implies that the issuer is asserting that
|
||||
they performed a check on that specific piece of data. However, it does not mean
|
||||
the data is an absolute, universal truth. "Verified" is an assertion of process,
|
||||
not an automatic guarantee of trust.
|
||||
|
||||
The core philosophy of this ecosystem is that trust is always resolved at the verifier. When the verifier (your app) receives the cryptographically secure data, and sees that the issuer marked it as "verified," it must determine whether it trusts the issuer to have verified the claim to its standards.
|
||||
The core philosophy of this ecosystem is that trust is always resolved at the
|
||||
verifier. When the verifier (your app) receives the cryptographically secure
|
||||
data, and sees that the issuer marked it as "verified," it must determine
|
||||
whether it trusts the issuer to have verified the claim to its standards.
|
||||
|
||||
### User experience
|
||||
|
||||
As shown in the Android flow, the user only needs to interact once with the Credential Manager UI to select the appropriate credential. Here is an example of how the selector looks:
|
||||
As shown in the Android flow, the user only needs to interact once with the
|
||||
Credential Manager UI to select the appropriate credential. Here is an example
|
||||
of how the selector looks:
|
||||
 **Figure 3.** The digital credentials UI.
|
||||
|
||||
### Standards
|
||||
|
||||
Digital credentials requests are created using the [OpenID4VP standard](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-introduction). You can see example requests at the [Digital Credentials Demo site](https://digital-credentials.dev/).
|
||||
Digital credentials requests are created using the [OpenID4VP
|
||||
standard](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-introduction). You can see example requests at the [Digital
|
||||
Credentials Demo site](https://digital-credentials.dev/).
|
||||
|
||||
Digital credential responses are typically returned in a standardized credential format. These are maintained by different standards bodies, and include [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/), [sd-jwt](https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/), and [mdoc](https://www.iso.org/standard/69084.html).
|
||||
Digital credential responses are typically returned in a standardized credential
|
||||
format. These are maintained by different standards bodies, and include [W3C
|
||||
Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/), [sd-jwt](https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/), and
|
||||
[mdoc](https://www.iso.org/standard/69084.html).
|
||||
|
||||
Custom protocols are also feasible, though we recommend using one of the standard protocols in your application.
|
||||
Custom protocols are also feasible, though we recommend using one of the
|
||||
standard protocols in your application.
|
||||
|
||||
### Try it out
|
||||
|
||||
You can test out the digital credentials flow across platforms with an Android wallet and web-based verifier:
|
||||
You can test out the digital credentials flow across platforms with an Android
|
||||
wallet and web-based verifier:
|
||||
|
||||
1. Install the [CMWallet public sample](https://github.com/digitalcredentialsdev/CMWallet) on your Android phone. You can do this by pulling from the repository and installing directly from Android Studio or navigating to <https://github.com/digitalcredentialsdev/CMWallet/actions> and selecting the latest build to access the latest `app-debug.apk` file.
|
||||
2. Open the CMWallet to register the metadata with Credential Manager. Make sure Bluetooth is enabled to allow your devices to connect to each other.
|
||||
|
||||
@@ -1,6 +1,11 @@
|
||||
Before your users can authenticate with passkeys, your app must first register or create the passkey for their account.
|
||||
Before your users can authenticate with passkeys, your app must first register
|
||||
or create the passkey for their account.
|
||||
|
||||
To create the passkey, obtain details required to create the passkey from your app server, and then call the Credential Manager API, which returns a public and private key pair. The returned private key is stored in a credential provider, such as Google Password Manager, as a passkey. The public key is stored on your app server.
|
||||
To create the passkey, obtain details required to create the passkey from your
|
||||
app server, and then call the Credential Manager API, which returns a public and
|
||||
private key pair. The returned private key is stored in a credential provider,
|
||||
such as Google Password Manager, as a passkey. The public key is stored on your
|
||||
app server.
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** While designing authentication flows with passkeys, make sure that you follow the [UX guidelines for passkeys](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys).
|
||||
@@ -9,11 +14,15 @@ To create the passkey, obtain details required to create the passkey from your a
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Make sure that you have set up [Digital Asset Links](https://developer.android.com/identity/credential-manager/prerequisites) and that you target devices running Android 9 (API level 28) or higher.
|
||||
Make sure that you have set up [Digital Asset Links](https://developer.android.com/identity/credential-manager/prerequisites) and that you target
|
||||
devices running Android 9 (API level 28) or higher.
|
||||
|
||||
## Overview
|
||||
|
||||
This guide focuses on the changes required in your [relying party client app](https://developer.android.com/identity/credential-manager#authentication-terminology) to create a passkey, and gives a brief overview of the [relying party app server](https://developer.android.com/identity/credential-manager#authentication-terminology) implementation. To learn more about the server-side integration, see [Server-side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
This guide focuses on the changes required in your [relying party client app](https://developer.android.com/identity/credential-manager#authentication-terminology)
|
||||
to create a passkey, and gives a brief overview of the [relying party app
|
||||
server](https://developer.android.com/identity/credential-manager#authentication-terminology) implementation. To learn more about the server-side integration, see
|
||||
[Server-side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
|
||||
1. [**Add dependencies to your app**](https://developer.android.com/identity/passkeys/create-passkeys#add-dependencies): Add the required Credential Manager libraries.
|
||||
2. [**Instantiate Credential Manager**](https://developer.android.com/identity/passkeys/create-passkeys#instantiate): Create a Credential Manager instance.
|
||||
@@ -24,7 +33,8 @@ This guide focuses on the changes required in your [relying party client app](ht
|
||||
7. [**Notify the user**](https://developer.android.com/identity/passkeys/create-passkeys#notify): Notify the user that their passkey has been created.
|
||||
|
||||
> [!TIP]
|
||||
> **Tip:** To enhance the user experience during sign up, add functionality to [restore credentials](https://developer.android.com/identity/sign-in/restore-credentials) on a new device to let users seamlessly set up their existing accounts on new Android devices, and [suppressing autofill dialogs on credential fields](https://developer.android.com/identity/passkeys/create-passkeys#suppress-autofill).
|
||||
> **Tip:** To enhance the user experience during sign up, add functionality to [restore credentials](https://developer.android.com/identity/sign-in/restore-credentials) on a new device to let users seamlessly set up their existing accounts on new Android devices, and [suppressing autofill dialogs on
|
||||
> credential fields](https://developer.android.com/identity/passkeys/create-passkeys#suppress-autofill).
|
||||
|
||||
## Add dependencies to your app
|
||||
|
||||
@@ -61,16 +71,26 @@ Use your app or activity context to create a `CredentialManager` object.
|
||||
|
||||
## Get credential creation options from your app server
|
||||
|
||||
When the user clicks a "Create Passkey" button or when a new user signs up, make a request from your app to your app server to obtain the information required to start the passkey registration process.
|
||||
When the user clicks a "Create Passkey" button or when a new user signs up, make
|
||||
a request from your app to your app server to obtain the information required to
|
||||
start the passkey registration process.
|
||||
|
||||
Use a FIDO-compliant library in your app server to send your client app the information required to create a passkey, such as information about the user, the app, and additional configuration properties. To learn more, see [Server side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
Use a FIDO-compliant library in your app server to send your client app the
|
||||
information required to create a passkey, such as information about the user,
|
||||
the app, and additional configuration properties. To learn more, see [Server
|
||||
side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration).
|
||||
|
||||
In the client app, decode the public key creation options sent by the app server. These are usually represented in JSON format. To learn more about how this decoding is done for web clients, see [Encoding and Decoding](https://developers.google.com/identity/passkeys/developer-guides/server-registration#encoding_and_decoding). For Android client apps, you must handle the decoding separately.
|
||||
In the client app, decode the public key creation options sent by the app
|
||||
server. These are usually represented in JSON format. To learn more about how
|
||||
this decoding is done for web clients, see [Encoding and
|
||||
Decoding](https://developers.google.com/identity/passkeys/developer-guides/server-registration#encoding_and_decoding). For Android client apps, you must handle the decoding
|
||||
separately.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** On your app server, securely store the `challenge` so that you can later verify the origin of the credential.
|
||||
|
||||
The following snippet shows the structure the public key creation options sent by the app server:
|
||||
The following snippet shows the structure the public key creation options sent
|
||||
by the app server:
|
||||
|
||||
{
|
||||
"challenge": "<base64url-encoded challenge>",
|
||||
@@ -129,7 +149,9 @@ Key fields in the public key creation options include:
|
||||
|
||||
## Create a passkey
|
||||
|
||||
After you have parsed the server-side public key creation options, create a passkey by wrapping these options in a `CreatePublicKeyCredentialRequest` object and calling `createCredential()`.
|
||||
After you have parsed the server-side public key creation options, create a
|
||||
passkey by wrapping these options in a `CreatePublicKeyCredentialRequest` object
|
||||
and calling `createCredential()`.
|
||||
|
||||
The `createPublicKeyCredentialRequest` includes the following:
|
||||
|
||||
@@ -138,14 +160,25 @@ The `createPublicKeyCredentialRequest` includes the following:
|
||||
- `false` (default): Use this value if the call to Credential Manager was triggered by an explicit user action.
|
||||
- `true`: Use this value if Credential Manager is opportunistically called, such as when first opening the app.
|
||||
If you set the value to `true` and there are no immediately available credentials, Credential Manager won't show any UI and the request will fail immediately, returning NoCredentialException for get requests and [`CreateCredentialNoCreateOptionException`](https://developer.android.com/reference/kotlin/androidx/credentials/exceptions/CreateCredentialNoCreateOptionException) for create requests.
|
||||
- `origin`: This field is automatically set for Android apps. For browsers and similarly privileged apps that need to set `origin`, see [Make Credential Manager calls on behalf of other parties for privileged apps](https://developer.android.com/training/sign-in/privileged-apps).
|
||||
- `origin`: This field is automatically set for Android apps. For browsers and similarly privileged apps that need to set `origin`, see [Make Credential
|
||||
Manager calls on behalf of other parties for privileged apps](https://developer.android.com/training/sign-in/privileged-apps).
|
||||
- `isConditional`: This is an optional field that defaults to `false`. For more information, see [Automatically create a passkey](https://developer.android.com/identity/passkeys/create-passkeys#automatic-upgrade).
|
||||
|
||||
Calling the `createCredential()` function launches Credential Manager's built-in bottom sheet UI that prompts the user to use a passkey and to select a credential provider and account for storage. However, if `isConditional` is set to `true`, the bottom sheet UI does not display, and the passkey is automatically created.
|
||||
Calling the `createCredential()` function launches Credential Manager's built-in
|
||||
bottom sheet UI that prompts the user to use a passkey and to select a
|
||||
credential provider and account for storage. However, if `isConditional` is set
|
||||
to `true`, the bottom sheet UI does not display, and the passkey is
|
||||
automatically created.
|
||||
|
||||
### Automatically create a passkey
|
||||
|
||||
You can automatically create a passkey for a user after a successful password login by setting the `isConditional` parameter to `true` in your `CreatePublicKeyCredentialRequest` while creating a passkey. If the user doesn't already have a passkey, your app will automatically attempt to create one in the background and store it in the user's credential provider, such as Google Password Manager. For an example of how this is implemented, see the [public sample](https://github.com/android/identity-samples/blob/main/Shrine/app/src/main/java/com/authentication/shrine/ui/AuthenticationScreen.kt#L98).
|
||||
You can automatically create a passkey for a user after a successful password
|
||||
login by setting the `isConditional` parameter to `true` in your
|
||||
`CreatePublicKeyCredentialRequest` while creating a passkey. If the user doesn't
|
||||
already have a passkey, your app will automatically attempt to create one in the
|
||||
background and store it in the user's credential provider, such as Google
|
||||
Password Manager. For an example of how this is implemented, see the [public
|
||||
sample](https://github.com/android/identity-samples/blob/main/Shrine/app/src/main/java/com/authentication/shrine/ui/AuthenticationScreen.kt#L98).
|
||||
 **Figure 2:**Google Password Manager notification
|
||||
|
||||
> [!NOTE]
|
||||
@@ -153,9 +186,11 @@ You can automatically create a passkey for a user after a successful password lo
|
||||
|
||||
## Handle the response
|
||||
|
||||
After the user is verified using the device's screen lock, a passkey is created and stored in the user's selected credential provider.
|
||||
After the user is verified using the device's screen lock, a passkey is created
|
||||
and stored in the user's selected credential provider.
|
||||
|
||||
The response after you successfully call `createCredential()` is a [PublicKeyCredential](https://developer.android.com/jetpack/androidx/releases/credentials) object.
|
||||
The response after you successfully call `createCredential()` is a
|
||||
[PublicKeyCredential](https://developer.android.com/jetpack/androidx/releases/credentials) object.
|
||||
|
||||
The `PublicKeyCredential` looks as follows:
|
||||
|
||||
@@ -206,55 +241,79 @@ Add code to handle failures as shown in the following snippet:
|
||||
|
||||
## Verify and save the public key on the app server
|
||||
|
||||
On the app server, you must verify the public key credential and then [save the public key](https://web.dev/articles/passkey-registration#save-credential).
|
||||
On the app server, you must verify the public key credential and then [save the
|
||||
public key](https://web.dev/articles/passkey-registration#save-credential).
|
||||
|
||||
To verify the public key credential's origin, compare it against an allow list of approved apps. If a key has an unrecognized origin, reject it.
|
||||
To verify the public key credential's origin, compare it against an allow list
|
||||
of approved apps. If a key has an unrecognized origin, reject it.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** An app's origin is based on its unique identity, which is the SHA-256 fingerprint of its signing certificate.
|
||||
|
||||
To obtain the app's SHA 256 fingerprint:
|
||||
|
||||
1. Print your release app's signing certificate by running the following command in a terminal:
|
||||
1. Print your release app's signing certificate by running the following
|
||||
command in a terminal:
|
||||
|
||||
keytool -list -keystore <path-to-apk-signing-keystore>
|
||||
|
||||
In the response, identify the signing certificate's SHA 256 fingerprint, mentioned as `Certificate fingerprints block` : `SHA256`.
|
||||
2. Encode the SHA256 fingerprint with base64url encoding. This Python example demonstrates how to properly encode the fingerprint:
|
||||
In the response, identify the signing certificate's SHA 256 fingerprint,
|
||||
mentioned as `Certificate fingerprints block` : `SHA256`.
|
||||
2. Encode the SHA256 fingerprint with base64url encoding. This Python example
|
||||
demonstrates how to properly encode the fingerprint:
|
||||
|
||||
import binascii
|
||||
import base64
|
||||
fingerprint = '<SHA256 finerprint>' # your app's SHA256 fingerprint
|
||||
print(base64.urlsafe_b64encode(binascii.a2b_hex(fingerprint.replace(':', ''))).decode('utf8').replace('=', ''))
|
||||
|
||||
3. Append `android:apk-key-hash`: to the start of the output from the previous step so that you get something that is similar to the following:
|
||||
3. Append `android:apk-key-hash`: to the start of the output from the previous
|
||||
step so that you get something that is similar to the following:
|
||||
|
||||
android:apk-key-hash:<encoded SHA 256 fingerprint>
|
||||
|
||||
The result should match with an allowed origin on your app server. If you have multiple signing certificates, such as certificates for debugging and release, or multiple apps, then repeat the process and accept all the origins as valid on the app server.
|
||||
The result should match with an allowed origin on your app server. If you
|
||||
have multiple signing certificates, such as certificates for debugging and
|
||||
release, or multiple apps, then repeat the process and accept all the
|
||||
origins as valid on the app server.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** When you save the passkey on the app server, make sure that you save the Authenticator Attestation Globally Unique Identifier ([AAGUID](https://web.dev/articles/webauthn-aaguid)) from the client data. The AAGUID is a unique number that identifies the model of the authenticator. For more information, see [Manage passkeys](https://developer.android.com/identity/passkeys/manage-passkeys).
|
||||
|
||||
## Notify the user
|
||||
|
||||
After the passkey is successfully created, notify your users about the passkey and inform them that they can manage their passkeys from their credential provider app or from [within the app settings](https://developer.android.com/identity/passkeys/manage-passkeys). Notify users by using a custom dialog, notification, or snackbar. Since an unexpected passkey creation by a malicious entity requires an immediate security alert, consider supplementing these in-app methods with external communication, such as an email.
|
||||
After the passkey is successfully created, notify your users about the passkey
|
||||
and inform them that they can manage their passkeys from their credential
|
||||
provider app or from [within the app settings](https://developer.android.com/identity/passkeys/manage-passkeys). Notify users by using a
|
||||
custom dialog, notification, or snackbar. Since an unexpected passkey creation
|
||||
by a malicious entity requires an immediate security alert, consider
|
||||
supplementing these in-app methods with external communication, such as an
|
||||
email.
|
||||
|
||||
## Enhance the user experience
|
||||
|
||||
To enhance the user experience while implementing sign up with Credential Manager, consider adding functionality for restore credentials and suppress autofill dialogs.
|
||||
To enhance the user experience while implementing sign up with Credential
|
||||
Manager, consider adding functionality for restore credentials and suppress
|
||||
autofill dialogs.
|
||||
|
||||
### Add functionality to restore credentials on a new device
|
||||
|
||||
To allow users to seamlessly log into their accounts on a new device, implement the [Restore Credentials](https://developer.android.com/identity/sign-in/restore-credentials) functionality. Adding restore credentials with `BackupAgent` logs users in when they open your restored app on a new device, letting them use your app right away.
|
||||
To allow users to seamlessly log into their accounts on a new device, implement
|
||||
the [Restore Credentials](https://developer.android.com/identity/sign-in/restore-credentials) functionality. Adding restore credentials with
|
||||
`BackupAgent` logs users in when they open your restored app on a new device,
|
||||
letting them use your app right away.
|
||||
|
||||
### Suppress autofill on credential fields (optional)
|
||||
|
||||
For app screens where users are expected to use Credential Manager's bottom sheet UI for authentication, add the `isCredential` attribute to the username and password fields. This suppresses autofill dialogs (`FillDialog` and `SaveDialog`) from overlapping with Credential Manager's bottom sheet UI.
|
||||
For app screens where users are expected to use Credential Manager's bottom
|
||||
sheet UI for authentication, add the `isCredential` attribute to the username
|
||||
and password fields. This suppresses autofill dialogs (`FillDialog` and
|
||||
`SaveDialog`) from overlapping with Credential Manager's bottom sheet UI.
|
||||
|
||||
The `isCredential` attribute is supported on Android 14 and higher.
|
||||
|
||||
The following example demonstrates how you can add the `isCredential` attribute to the relevant username and password fields in the relevant views for your app:
|
||||
The following example demonstrates how you can add the `isCredential` attribute
|
||||
to the relevant username and password fields in the relevant views for your app:
|
||||
|
||||
<TextView
|
||||
android:layout_width="match_parent"
|
||||
|
||||
+20
-7
@@ -1,8 +1,11 @@
|
||||
This document describes how to integrate the Credential Manager API with an Android app that uses WebView. Credential Manager is supported natively in the `android.webkit.WebView` library in [version 1.12.0](https://developer.android.com/jetpack/androidx/releases/webkit#1.12.0) and later.
|
||||
This document describes how to integrate the Credential Manager API with an
|
||||
Android app that uses WebView. Credential Manager is supported natively in the
|
||||
`android.webkit.WebView` library in [version 1.12.0](https://developer.android.com/jetpack/androidx/releases/webkit#1.12.0) and later.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To use Credential Manager in WebView, add the following dependencies to your app module's build script:
|
||||
To use Credential Manager in WebView, add the following dependencies to your app
|
||||
module's build script:
|
||||
|
||||
dependencies {
|
||||
implementation("androidx.credentials:credentials:1.6.0-beta02")
|
||||
@@ -10,11 +13,14 @@ To use Credential Manager in WebView, add the following dependencies to your app
|
||||
implementation("androidx.webkit:webkit:1.14.0")
|
||||
}
|
||||
|
||||
You will also need to associate your app with a website that your app owns using digital asset linking. For more information, see [adding digital asset linking](https://developer.android.com/identity/credential-manager/prerequisites).
|
||||
You will also need to associate your app with a website that your app owns using
|
||||
digital asset linking. For more information, see
|
||||
[adding digital asset linking](https://developer.android.com/identity/credential-manager/prerequisites).
|
||||
|
||||
## Use the WebKit library
|
||||
|
||||
To use the WebKit library, check for feature support, and then enable support by calling `setWebAuthenticationSupport()`:
|
||||
To use the WebKit library, check for feature support, and then enable support by
|
||||
calling `setWebAuthenticationSupport()`:
|
||||
|
||||
class WebViewActivity : ComponentActivity() {
|
||||
override fun onCreate(savedInstanceState: Bundle?) {
|
||||
@@ -60,12 +66,19 @@ To use the WebKit library, check for feature support, and then enable support by
|
||||
|
||||
## Web integration
|
||||
|
||||
To learn how to build Web integration see [Create a passkey for passwordless logins](https://web.dev/passkey-registration/). You can also reference the [demo site source](https://github.com/deephand/webauthn-in-webview).
|
||||
To learn how to build Web integration see
|
||||
[Create a passkey for passwordless logins](https://web.dev/passkey-registration/).
|
||||
You can also reference the [demo site source](https://github.com/deephand/webauthn-in-webview).
|
||||
|
||||
## Testing and deployment
|
||||
|
||||
Test the entire flow thoroughly in a controlled environment to verify proper communication between the Android app, the web page, and the backend.
|
||||
Test the entire flow thoroughly in a controlled environment to verify proper
|
||||
communication between the Android app, the web page, and the backend.
|
||||
|
||||
Deploy the integrated solution to production, verifying that the backend can handle incoming registration and authentication requests. The backend code should generate initial JSON for registration (create) and authentication (get) processes. It should also handle validation and verification of the responses received from the web page.
|
||||
Deploy the integrated solution to production, verifying that the backend can
|
||||
handle incoming registration and authentication requests. The backend code
|
||||
should generate initial JSON for registration (create) and authentication (get)
|
||||
processes. It should also handle validation and verification of the responses
|
||||
received from the web page.
|
||||
|
||||
Verify the implementation corresponds to the [UX recommendations](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys).
|
||||
@@ -10,7 +10,7 @@ description: Instructions to make or update an app's UI so that it adapts to dif
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-20'
|
||||
keywords:
|
||||
- android
|
||||
- ui
|
||||
@@ -30,7 +30,8 @@ The app must:
|
||||
|
||||
## Workflow to make an app adaptive
|
||||
|
||||
To make an app adaptive, follow these steps or a subset of them adapting to the task.
|
||||
To make an app adaptive, follow these steps or a subset of them adapting to the
|
||||
task.
|
||||
|
||||
- Step 1: Verify current UI
|
||||
- Step 2: Make the navigation bar adaptive
|
||||
@@ -40,9 +41,11 @@ To make an app adaptive, follow these steps or a subset of them adapting to the
|
||||
|
||||
## Step 1. Verify current UI
|
||||
|
||||
Ensure that screenshot tests exist to verify the current UI on different form factors. If they don't exist, add the [Compose Preview Screenshot Testing tool](references/android/develop/ui/compose/tooling/debug.md). Use the following annotation to create previews for all the major form factors. For example:
|
||||
Ensure that screenshot tests exist to verify the current UI on different form
|
||||
factors. If they don't exist, add the [Compose Preview Screenshot Testing
|
||||
tool](references/android/develop/ui/compose/tooling/debug.md). Use the following annotation to create previews for all the major form
|
||||
factors. For example:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Preview(name = "Phone", device = Devices.PHONE, showBackground = true)
|
||||
@@ -61,21 +64,25 @@ fun FeedScreenPreview() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Step 2. Make the navigation bar adaptive
|
||||
|
||||
Bottom navigation bars are optimized for touch input when the user is holding a phone in portrait mode. On larger screen hand-held devices, like tablets and unfolded foldables, the navigation area must be accessible from the edge of the screen (navigation rail).
|
||||
Bottom navigation bars are optimized for touch input when the user is holding a
|
||||
phone in portrait mode. On larger screen hand-held devices, like tablets and
|
||||
unfolded foldables, the navigation area must be accessible from the edge of the
|
||||
screen (navigation rail).
|
||||
|
||||
If you need to provide more screen space for the content, hide the navigation area. Examples of this include:
|
||||
If you need to provide more screen space for the content, hide the
|
||||
navigation area. Examples of this include:
|
||||
|
||||
- Hiding the navigation bar when the user scrolls down and showing it again when the user scrolls up. The assumption is that when the user is scrolling down, they are consuming content but when scrolling up they are trying to navigate away from that content.
|
||||
- Hiding the navigation area when its content is distracting. For example, in camera previews or when displaying a full-screen photo.
|
||||
|
||||
When the detail screen is displayed full-screen on mobile, full-screen mode must be deactivated on larger screens.
|
||||
When the detail screen is displayed full-screen on mobile, full-screen mode must
|
||||
be deactivated on larger screens.
|
||||
|
||||
Steps to migrate:
|
||||
|
||||
@@ -87,7 +94,10 @@ Steps to migrate:
|
||||
|
||||
### Step 2.1. Control navigation area visibility
|
||||
|
||||
If the navigation bar's visibility changes - it is hidden under certain scenarios or on certain screens - this behavior must be maintained with the adaptive navigation area. This is done using `NavigationSuiteScaffold`'s `state` parameter.
|
||||
If the navigation bar's visibility changes - it is hidden under certain
|
||||
scenarios or on certain screens - this behavior must be maintained with the
|
||||
adaptive navigation area. This is done using `NavigationSuiteScaffold`'s `state`
|
||||
parameter.
|
||||
|
||||
Steps to migrate:
|
||||
|
||||
@@ -97,7 +107,6 @@ Steps to migrate:
|
||||
|
||||
For example:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Pass this variable to any composable that needs to control the navigation area visibility
|
||||
@@ -118,26 +127,33 @@ LaunchedEffect(isNavBarVisible){
|
||||
scaffoldVisibilityState.hide()
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Step 3. Add multi-pane layouts using Navigation 3 Scenes
|
||||
|
||||
Analyze the codebase looking for related screens - tapping on something in one screen opens another screen that shows information related to the first. There are two canonical screen relationships: list-detail and supporting pane.
|
||||
Analyze the codebase looking for related screens - tapping on something in one
|
||||
screen opens another screen that shows information related to the first. There
|
||||
are two canonical screen relationships: list-detail and supporting pane.
|
||||
|
||||
IMPORTANT: You must use the Navigation 3 `SceneStrategy` approach to implement multi-pane layouts. Do not use `ListDetailPaneScaffold` or `SupportingPaneScaffold`.
|
||||
IMPORTANT: You must use the Navigation 3 `SceneStrategy` approach to implement
|
||||
multi-pane layouts. Do not use `ListDetailPaneScaffold` or
|
||||
`SupportingPaneScaffold`.
|
||||
|
||||
### Step 3.1. List-detail
|
||||
|
||||
#### Identify the list and detail screens
|
||||
|
||||
List-detail layouts display a list of items (this is the list screen) and clicking on an item opens a new screen that shows more details about that item (the detail screen).
|
||||
List-detail layouts display a list of items (this is the list screen) and
|
||||
clicking on an item opens a new screen that shows more details about that item
|
||||
(the detail screen).
|
||||
|
||||
Typical usage includes productivity apps like email, notes, and messaging.
|
||||
|
||||
Unless requested explicitly, avoid this pattern when the detail content requires substantial screen space (e.g., images or media that benefits from a full-screen presentation).
|
||||
Unless requested explicitly, avoid this pattern when the detail content requires
|
||||
substantial screen space (e.g., images or media that benefits from a full-screen
|
||||
presentation).
|
||||
|
||||
#### Add a Material list-detail SceneStrategy
|
||||
|
||||
@@ -147,7 +163,8 @@ Unless requested explicitly, avoid this pattern when the detail content requires
|
||||
|
||||
#### Use metadata to identify the list and detail screens
|
||||
|
||||
- Add metadata using `entry(metadata = ...)` or `NavEntry(metadata = ...)` to the list entry using `ListDetailSceneStrategy.listPane(detailPlaceholder = { <placeholder composable> })`.
|
||||
- Add metadata using `entry(metadata = ...)` or `NavEntry(metadata = ...)` to the list entry using `ListDetailSceneStrategy.listPane(detailPlaceholder = {
|
||||
<placeholder composable> })`.
|
||||
- Use the `detailPlaceholder` parameter to add a placeholder on the detail screen when no list items are selected.
|
||||
- Add metadata to the detail entry using `ListDetailSceneStrategy.detailPane()`.
|
||||
|
||||
@@ -156,11 +173,14 @@ Unless requested explicitly, avoid this pattern when the detail content requires
|
||||
- When a detail screen displays its content full-screen on mobile (content fills the entire screen, bars or rails are hidden), full-screen mode must be deactivated if it's part of a list-detail layout.
|
||||
- Detail screens must not show a back arrow when on a list-detail layout.
|
||||
|
||||
For a reference implementation, check the [Nav3 **Material** List Detail recipe](references/android/guide/navigation/navigation-3/recipes/material-listdetail.md).
|
||||
For a reference implementation, check the [Nav3 **Material** List Detail
|
||||
recipe](references/android/guide/navigation/navigation-3/recipes/material-listdetail.md).
|
||||
|
||||
### Step 3.2. Supporting pane
|
||||
|
||||
Identify supporting pane screens where a main screen displays a single item, and selecting it opens a "supporting screen" with more details. The supporting screen complements the main screen and is shown in a supporting pane.
|
||||
Identify supporting pane screens where a main screen displays a single item, and
|
||||
selecting it opens a "supporting screen" with more details. The supporting
|
||||
screen complements the main screen and is shown in a supporting pane.
|
||||
|
||||
#### Add a Material supporting pane `SceneStrategy`
|
||||
|
||||
@@ -175,13 +195,15 @@ Identify supporting pane screens where a main screen displays a single item, and
|
||||
|
||||
### Step 3.3. Run screenshot tests
|
||||
|
||||
If you have made changes, record new reference files. Ask the user to visually verify that the new layouts are correct.
|
||||
If you have made changes, record new reference files. Ask the user to visually
|
||||
verify that the new layouts are correct.
|
||||
|
||||
## Step 4. Make vertical lists adaptive by changing the number of columns
|
||||
|
||||
### Step 4.1. Make lazy lists adaptive
|
||||
|
||||
Look for the following vertical list composables: `LazyColumn`, `LazyVerticalGrid`, `LazyVerticalStaggeredGrid`.
|
||||
Look for the following vertical list composables: `LazyColumn`,
|
||||
`LazyVerticalGrid`, `LazyVerticalStaggeredGrid`.
|
||||
|
||||
Steps to migrate:
|
||||
|
||||
@@ -192,16 +214,24 @@ Steps to migrate:
|
||||
|
||||
### Step 4.2. Migrate non-lazy lists to Grid
|
||||
|
||||
WARNING: Grid is an experimental API available from Compose 1.11.0-beta01. Confirm with the user that they are happy to use an experimental API in their codebase.
|
||||
WARNING: Grid is an experimental API available from Compose 1.11.0-beta01.
|
||||
Confirm with the user that they are happy to use an experimental API in their
|
||||
codebase.
|
||||
|
||||
Look for any `Column` that contains multiple items of the same type and replace it with `Grid`. Do not replace it with `LazyVerticalGrid` or any other lazy layout. Do not place `Grid` inside the existing `Column`. Completely replace it.
|
||||
Look for any `Column` that contains multiple items of the same type and replace
|
||||
it with `Grid`. Do not replace it with `LazyVerticalGrid` or any other lazy
|
||||
layout. Do not place `Grid` inside the existing `Column`. Completely replace it.
|
||||
|
||||
`Grid` is configured by supplying a lambda (an extension function on `GridConfigurationScope`) to its `config` parameter. Inside the lambda, `constraints` provides the minimum and maximum dimensions of the grid container and can be used to change the number of rows and columns based on the available size. For example, the following code configures `Grid` such that when the available width is:
|
||||
`Grid` is configured by supplying a lambda (an extension function on
|
||||
`GridConfigurationScope`) to its `config` parameter. Inside the lambda,
|
||||
`constraints` provides the minimum and maximum dimensions of the grid container
|
||||
and can be used to change the number of rows and columns based on the available
|
||||
size. For example, the following code configures `Grid` such that when the
|
||||
available width is:
|
||||
|
||||
- less than 800dp, a 2x4 grid is used
|
||||
- 800dp or more, a 4x2 grid is used
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -220,23 +250,26 @@ Grid(
|
||||
gap(gapSizeDp)
|
||||
}
|
||||
) { /** items **/ }
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
`Grid` is an experimental API so add the `@OptIn(ExperimentalGridApi::class)` annotation to any function that uses it.
|
||||
`Grid` is an experimental API so add the `@OptIn(ExperimentalGridApi::class)`
|
||||
annotation to any function that uses it.
|
||||
|
||||
## Step 5: Hide App Bars when scrolling
|
||||
|
||||
In an app with multiple top-level destinations, each screen must manage its own app bar state independently. There are two main scroll behaviors:
|
||||
In an app with multiple top-level destinations, each screen must manage its own
|
||||
app bar state independently. There are two main scroll behaviors:
|
||||
|
||||
- `exitUntilCollapsedScrollBehavior`: Hides on scroll down, stays hidden while you scroll up until you reach the very top (0 offset).
|
||||
- `enterAlwaysScrollBehavior`: Hides on scroll down, shows immediately on scroll up.
|
||||
|
||||
## Final step: Build and test
|
||||
|
||||
Build the app and run the local tests. If the project has screenshot tests, run them but DO NOT update the reference images. Prompt the user to do this after they have viewed the screenshot diffs.
|
||||
Build the app and run the local tests. If the project has screenshot tests, run
|
||||
them but DO NOT update the reference images. Prompt the user to do this after
|
||||
they have viewed the screenshot diffs.
|
||||
|
||||
## Additional documentation for experimental adaptive APIs
|
||||
|
||||
@@ -253,11 +286,14 @@ Check the FlexBox documentation:
|
||||
|
||||
## MediaQuery
|
||||
|
||||
Check the [MediaQuery documentation](references/android/develop/ui/compose/layouts/adaptive/mediaquery/index.md) when you need to query the device's screen size, pointer precision, keyboard type, whether it has cameras or microphones, and other device capabilities.
|
||||
Check the [MediaQuery documentation](references/android/develop/ui/compose/layouts/adaptive/mediaquery/index.md) when you need to query the device's
|
||||
screen size, pointer precision, keyboard type, whether it has cameras or
|
||||
microphones, and other device capabilities.
|
||||
|
||||
## Grid
|
||||
|
||||
Check the Grid documentation when you need to display a fixed number of items in a grid layout:
|
||||
Check the Grid documentation when you need to display a fixed number of items in
|
||||
a grid layout:
|
||||
|
||||
- [Overview](references/android/develop/ui/compose/layouts/adaptive/grid/index.md)
|
||||
- [Get started - setup](references/android/develop/ui/compose/layouts/adaptive/grid/get-started.md)
|
||||
|
||||
+34
-15
@@ -1,6 +1,6 @@
|
||||
To configure the behavior of the `FlexBox` container, create a `FlexBoxConfig` block and supply it using the `config` parameter.
|
||||
To configure the behavior of the `FlexBox` container, create a `FlexBoxConfig`
|
||||
block and supply it using the `config` parameter.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox(
|
||||
@@ -14,16 +14,17 @@ FlexBox(
|
||||
}
|
||||
) { // child items
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Use `FlexBoxConfig` to define the layout direction, wrapping behavior, alignment, and gaps between items.
|
||||
Use `FlexBoxConfig` to define the layout direction, wrapping behavior,
|
||||
alignment, and gaps between items.
|
||||
|
||||
## Layout direction
|
||||
|
||||
The `direction` function sets the main axis, which dictates the direction items are laid out in. It accepts the following values:
|
||||
The `direction` function sets the main axis, which dictates the direction
|
||||
items are laid out in. It accepts the following values:
|
||||
|
||||
- `Row` (default): Sets the main axis to be horizontal. In left-to-right locales this will be left-to-right, with the opposite in right-to-left.
|
||||
- `RowReverse`: Reverses the direction of `Row`.
|
||||
@@ -32,11 +33,13 @@ The `direction` function sets the main axis, which dictates the direction items
|
||||
|
||||
## Align items and distribute extra space
|
||||
|
||||
The following sections describe how to align items and distribute extra space along the main and cross axes.
|
||||
The following sections describe how to align items and distribute extra space
|
||||
along the main and cross axes.
|
||||
|
||||
### Along the main axis
|
||||
|
||||
Use `justifyContent` to distribute items along the main axis. The following table shows the behavior when the direction is `Row`.
|
||||
Use `justifyContent` to distribute items along the main axis. The following
|
||||
table shows the behavior when the direction is `Row`.
|
||||
|
||||
|---|---|
|
||||
| |  |
|
||||
@@ -49,7 +52,9 @@ Use `justifyContent` to distribute items along the main axis. The following tabl
|
||||
|
||||
### Along the cross axis
|
||||
|
||||
Use `alignItems` to align items along the cross axis within a single line. This behavior can be overridden by individual items using the [`alignSelf` modifier](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#item-alignment).
|
||||
Use `alignItems` to align items along the cross axis within a single line. This
|
||||
behavior can be overridden by individual items using the
|
||||
[`alignSelf` modifier](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#item-alignment).
|
||||
|
||||
The following images show the behavior when the direction is `Row`:
|
||||
|
||||
@@ -57,7 +62,10 @@ The following images show the behavior when the direction is `Row`:
|
||||
|  |  |  |  |  |  |
|
||||
| | `Start` | `End` | `Center` | `Stretch` | `Baseline` |
|
||||
|
||||
Use `alignContent` to align lines to the cross axis and to distribute extra space between lines. This property only applies when there are multiple lines (wrapping is enabled). The following images show the behavior when the direction is `Row`:
|
||||
Use `alignContent` to align lines to the cross axis and to distribute extra
|
||||
space between lines. This property only applies when there are multiple lines
|
||||
(wrapping is enabled). The following images show the behavior when the direction
|
||||
is `Row`:
|
||||
|
||||
|---|---|---|---|---|---|---|
|
||||
|  |  |  |  |  |  |  |
|
||||
@@ -65,7 +73,9 @@ Use `alignContent` to align lines to the cross axis and to distribute extra spac
|
||||
|
||||
## Wrap items
|
||||
|
||||
Wrapping lets a `FlexBox` container become multi-line, moving items that don't fit onto a new row or column along the cross-axis. Configure wrapping behavior using `wrap`.
|
||||
Wrapping lets a `FlexBox` container become multi-line, moving items that don't
|
||||
fit onto a new row or column along the cross-axis. Configure wrapping behavior
|
||||
using `wrap`.
|
||||
|
||||
|---|---|
|
||||
| **`FlexWrap` value** | **Example using direction `Row`** |
|
||||
@@ -73,20 +83,29 @@ Wrapping lets a `FlexBox` container become multi-line, moving items that don't f
|
||||
| `Wrap`: When there is insufficient space for an item (plus any [gap](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#add-gaps)), a new line is created in the direction of the cross axis. For example, if the direction is `Row`, a new line is added **below**. |  |
|
||||
| `WrapReverse`: The same as `Wrap`, except the new line is added in the opposite direction to the cross axis. For example, if the direction is `Row`, a new line is added **above**. |  |
|
||||
|
||||
The following example shows how the `FlexBox` wrapping algorithm works. The `FlexBox` container has a main size of `100dp`, with `wrap` set to `FlexWrap.Wrap` and a gap of `8dp`. It contains three items with `basis` `20dp`, `40dp`, and `50dp`, respectively.
|
||||
The following example shows how the `FlexBox` wrapping algorithm works. The
|
||||
`FlexBox` container has a main size of `100dp`, with `wrap` set to
|
||||
`FlexWrap.Wrap` and a gap of `8dp`. It contains three items with `basis` `20dp`,
|
||||
`40dp`, and `50dp`, respectively.
|
||||
|
||||
There is `100dp` available space in the line. Child 1 is `20dp`. There is space, so Child 1 is placed into the line.
|
||||
There is `100dp` available space in the line. Child 1 is `20dp`.
|
||||
There is space, so Child 1 is placed into the line.
|
||||
 **Figure 1.** First item placed in the `FlexBox` container.
|
||||
|
||||
There is `80dp` available space in the line. The gap is `8dp`. Child 2 is `40dp`. The required space is `48dp`. There is space, so the gap and Child 2 are placed into the line.
|
||||
There is `80dp` available space in the line. The gap is `8dp`. Child 2 is
|
||||
`40dp`. The required space is `48dp`. There is space, so the gap and Child 2
|
||||
are placed into the line.
|
||||
 **Figure 2.** Second item placed in the `FlexBox` container after the first item.
|
||||
|
||||
There is `32dp` available space in the line. The gap is `8dp`. Child 3 is `50dp`. The required space is `58dp`. There is not enough space in the current line, so Child 3 is placed in a new line.
|
||||
There is `32dp` available space in the line. The gap is `8dp`. Child 3 is
|
||||
`50dp`. The required space is `58dp`. There is not enough space in the current
|
||||
line, so Child 3 is placed in a new line.
|
||||
 **Figure 3.** Third item placed on a new line because it doesn't fit on the first line.
|
||||
|
||||
## Add gaps between items
|
||||
|
||||
Add gaps between rows and columns using `rowGap` and `columnGap`. This is useful to avoid adding spacing modifiers to children.
|
||||
Add gaps between rows and columns using `rowGap` and `columnGap`. This is useful
|
||||
to avoid adding spacing modifiers to children.
|
||||
|
||||
|---|---|---|
|
||||
|  |  |  |
|
||||
|
||||
+10
-9
@@ -2,10 +2,11 @@ This page describes how to implement basic `FlexBox` layouts.
|
||||
|
||||
## Set up project
|
||||
|
||||
1. Add the [`androidx.compose.foundation.layout`](https://developer.android.com/jetpack/androidx/versions) library to your project's `lib.versions.toml`.
|
||||
1. Add the [`androidx.compose.foundation.layout`](https://developer.android.com/jetpack/androidx/versions) library to your project's
|
||||
`lib.versions.toml`.
|
||||
|
||||
[versions]
|
||||
compose = "1.12.0-rc01"
|
||||
compose = "1.13.0-alpha01"
|
||||
|
||||
[libraries]
|
||||
androidx-compose-foundation-layout = { group = "androidx.compose.foundation", name = "foundation-layout", version.ref = "compose" }
|
||||
@@ -18,9 +19,9 @@ This page describes how to implement basic `FlexBox` layouts.
|
||||
|
||||
## Create basic FlexBox layouts
|
||||
|
||||
**Example 1** : `FlexBox` lays out two `Text` elements that are centrally aligned.
|
||||
**Example 1** : `FlexBox` lays out two `Text` elements that are centrally
|
||||
aligned.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox(
|
||||
@@ -32,16 +33,16 @@ FlexBox(
|
||||
Text(text = "Hello", fontSize = 48.sp)
|
||||
Text(text = "World!", fontSize = 48.sp)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||

|
||||
|
||||
**Example 2** : `FlexBox` wraps five items onto two rows and grows them unequally to fill the available space on each row. There is an `8.dp` gap, both vertically and horizontally, between the items.
|
||||
**Example 2** : `FlexBox` wraps five items onto two rows and grows them unequally
|
||||
to fill the available space on each row. There is an `8.dp`
|
||||
gap, both vertically and horizontally, between the items.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox(
|
||||
@@ -58,11 +59,11 @@ FlexBox(
|
||||
OrangeRoundedBox(modifier = Modifier.flex { grow(1.0f) })
|
||||
PinkRoundedBox(modifier = Modifier.flex { grow(1.0f) })
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||

|
||||
|
||||
To learn more about `FlexBox` behavior, see [Set container behavior](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior) and [Set item behavior](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior).
|
||||
To learn more about `FlexBox` behavior, see [Set container behavior](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior) and [Set
|
||||
item behavior](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior).
|
||||
+36
-11
@@ -1,7 +1,10 @@
|
||||
> [!NOTE]
|
||||
> **Note:** FlexBox is an experimental API and is likely to change in the future. To use it, annotate your code with `@ExperimentalFlexBoxApi`. Please file any issues or feedback on the [issue tracker](https://issuetracker.google.com/issues/new?component=1876021&title=%5BFlexBox%5D).
|
||||
|
||||
[`FlexBox`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/FlexBox.composable#FlexBox(androidx.compose.ui.Modifier,androidx.compose.foundation.layout.FlexBoxConfig,kotlin.Function1)) is a container that lays out items in a single direction. It can resize, wrap, align, and distribute space among items to optimally fill the available space. It's a useful layout for different sized items and for resizing items when the available space changes.
|
||||
[`FlexBox`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/FlexBox.composable#FlexBox(androidx.compose.ui.Modifier,androidx.compose.foundation.layout.FlexBoxConfig,kotlin.Function1)) is a container that lays out items in a single direction. It can
|
||||
resize, wrap, align, and distribute space among items to optimally fill the
|
||||
available space. It's a useful layout for different sized items and for resizing
|
||||
items when the available space changes.
|
||||
|
||||
With `FlexBox`, you can:
|
||||
|
||||
@@ -11,16 +14,23 @@ With `FlexBox`, you can:
|
||||
|
||||
## When to use FlexBox
|
||||
|
||||
`FlexBox` is usually used to display a small number of items *within* an overall screen layout. For an overall screen layout, `Grid` is usually a better choice. `FlexBox` does not support lazy-loading of items. To display large numbers of items, use [lazy lists and grids](https://developer.android.com/develop/ui/compose/lists). If you need to wrap items, use `FlexBox` instead of `FlowRow` and `FlowColumn`.
|
||||
`FlexBox` is usually used to display a small number of items *within* an
|
||||
overall screen layout. For an overall screen layout,
|
||||
`Grid` is usually a better choice. `FlexBox` does not support lazy-loading of
|
||||
items. To display large numbers of items, use [lazy lists and grids](https://developer.android.com/develop/ui/compose/lists). If you
|
||||
need to wrap items, use `FlexBox` instead of `FlowRow` and `FlowColumn`.
|
||||
|
||||
## Terminology and concepts
|
||||
|
||||
> [!IMPORTANT]
|
||||
> **Key Point:** `FlexBox` is heavily influenced by the [CSS Flexible Box Layout specification](https://www.w3.org/TR/css-flexbox-1/) and has almost identical concepts, terminology, and behavior. If you're familiar with `display: flex`, you'll find `FlexBox`'s properties and behavior almost identical.
|
||||
|
||||
`FlexBox` lays out its items in either horizontal or vertical *lines* . This direction of these lines establishes the *main axis* . 90 degrees to the main axis is the *cross axis* . The length of the `FlexBox` along the main axis is known as the *main size* . The corresponding cross axis length is known as the *cross size* . These sizes and axes form the basis of `FlexBox`'s behavior.
|
||||
`FlexBox` lays out its items in either horizontal or vertical *lines* . This
|
||||
direction of these lines establishes the *main axis* . 90 degrees to the main
|
||||
axis is the *cross axis* . The length of the `FlexBox` along the main axis is
|
||||
known as the *main size* . The corresponding cross axis length is known as the
|
||||
*cross size* . These sizes and axes form the basis of `FlexBox`'s behavior.
|
||||
|
||||
<br />
|
||||
|
||||
 **Figure 1.** Axes and sizes when the `FlexBox` direction is `Row`.  **Figure 2.** Axes and sizes when the `FlexBox` direction is `Column`.
|
||||
|
||||
@@ -39,18 +49,33 @@ You can apply `FlexBox` properties in two ways:
|
||||
|
||||
### Understand the `FlexBox` layout algorithm
|
||||
|
||||
One of `FlexBox`'s most powerful features is its ability to resize its children to best fit the space available to it. Understanding how `FlexBox` does this can help you set `FlexBox` properties to optimize your UI for all possible sizes.
|
||||
One of `FlexBox`'s most powerful features is its ability to resize its children
|
||||
to best fit the space available to it. Understanding how `FlexBox` does this can
|
||||
help you set `FlexBox` properties to optimize your UI for all possible sizes.
|
||||
|
||||
`FlexBox`'s layout algorithm works in the following way:
|
||||
|
||||
1. **Calculate child base size** : Use the child's [`basis` value](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#set-initial-size) to calculate its initial size along the main axis before any extra space is distributed.
|
||||
1. **Calculate child base size** : Use the child's [`basis` value](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#set-initial-size)
|
||||
to calculate its initial size along the main axis before any extra space is
|
||||
distributed.
|
||||
|
||||
2. **Sort the children** : Sort the children by their [`order`](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#item-order) values, if present.
|
||||
2. **Sort the children** : Sort the children by their [`order`](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#item-order) values, if
|
||||
present.
|
||||
|
||||
3. **Build lines** : For each child, check if its initial size plus [`gap`](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#add-gaps) will fit into the remaining space on the current line. If so, place this child into the line. If not, place it onto a new line if [wrapping is enabled](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#wrap-items), or place the item into the current line where it will overflow (it will be partially obscured by the edge of the container).
|
||||
3. **Build lines** : For each child, check if its initial size plus
|
||||
[`gap`](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#add-gaps) will fit into the remaining space on the current line.
|
||||
If so, place this child into the line. If not, place it onto a new line if
|
||||
[wrapping is enabled](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#wrap-items), or place the item into the current line
|
||||
where it will overflow (it will be partially obscured by the edge of the
|
||||
container).
|
||||
|
||||
4. **Align or resize items in the main axis** : For each line, distribute extra space *to* or between items by [resizing](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#item-size) or [aligning](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#main-axis) them.
|
||||
4. **Align or resize items in the main axis** : For each line, distribute extra
|
||||
space *to* or between items by [resizing](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/item-behavior#item-size) or
|
||||
[aligning](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#main-axis) them.
|
||||
|
||||
5. **Align or resize items in the cross axis** : For each line, distribute extra space to or between items and lines by [stretching or aligning them](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#cross-axis).
|
||||
5. **Align or resize items in the cross axis** : For each line, distribute extra
|
||||
space to or between items and lines by [stretching or aligning
|
||||
them](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#cross-axis).
|
||||
|
||||
Now that you're familiar with `FlexBox` concepts, see [Get started](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/get-started) to create a basic `FlexBox`.
|
||||
Now that you're familiar with `FlexBox` concepts, see [Get started](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/get-started) to
|
||||
create a basic `FlexBox`.
|
||||
+44
-21
@@ -1,10 +1,10 @@
|
||||
Use `Modifier.flex` to control how an item changes size, order, and is aligned inside a `FlexBox`.
|
||||
Use `Modifier.flex` to control how an item changes size, order, and is aligned
|
||||
inside a `FlexBox`.
|
||||
|
||||
## Item size
|
||||
|
||||
Use the `basis`, `grow`, and `shrink` functions to control an item's size.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox {
|
||||
@@ -16,14 +16,14 @@ FlexBox {
|
||||
}
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Set initial size
|
||||
|
||||
Use `basis` to specify the item's initial size before any extra space is distributed. You can think of this as the item's *preferred* size.
|
||||
Use `basis` to specify the item's initial size before any extra space is
|
||||
distributed. You can think of this as the item's *preferred* size.
|
||||
|
||||
|---|---|---|---|
|
||||
| **Value type** | **Behavior** | **Code snippet** Note: The boxes have a maximum intrinsic size of `100dp` | **Example using container width `600dp`** |
|
||||
@@ -31,31 +31,48 @@ Use `basis` to specify the item's initial size before any extra space is distrib
|
||||
| Fixed `dp` | A fixed size in Dp. | ```kotlin FlexBox { RedRoundedBox( Modifier.flex { basis(200.dp) } ) BlueRoundedBox( Modifier.flex { basis(100.dp) } ) } ``` |  |
|
||||
| Percentage | A percentage of the container size. | ```kotlin FlexBox { RedRoundedBox( Modifier.flex { basis(0.7f) } ) BlueRoundedBox( Modifier.flex { basis(0.3f) } ) } ``` |  |
|
||||
|
||||
If the basis value is less than the item's intrinsic minimum size, the intrinsic minimum size is used instead. For example, if a `Text` item that contains a word requires `50dp` to display, but also has `basis = 10.dp`, a value of `50dp` is used.
|
||||
If the basis value is less than the item's intrinsic minimum size, the intrinsic
|
||||
minimum size is used instead. For example, if a `Text` item that contains a word
|
||||
requires `50dp` to display, but also has `basis = 10.dp`, a
|
||||
value of `50dp` is used.
|
||||
|
||||
### Grow items when there's space
|
||||
|
||||
Use `grow` to specify how much an item grows when there is extra space. This is space remaining in the `FlexBox` container after all the items' `basis` values have been added up. The `grow` value indicates *how much* of the extra space a given child will receive, relative to its siblings. By default, items won't grow.
|
||||
Use `grow` to specify how much an item grows when there is extra space. This is
|
||||
space remaining in the `FlexBox` container after all the items' `basis` values
|
||||
have been added up. The `grow` value indicates *how much* of the extra space a
|
||||
given child will receive, relative to its siblings. By default, items won't
|
||||
grow.
|
||||
|
||||
The following example shows a `FlexBox` with three child items. Each has a basis value of `100dp`. The first child has a positive `grow` value. Since there is only one child with a `grow` value, the actual value is irrelevant - as long as it's positive, the child receives all the extra space.
|
||||
The following example shows a `FlexBox` with three child items. Each has a basis
|
||||
value of `100dp`. The first child has a positive `grow` value. Since there is
|
||||
only one child with a `grow` value, the actual value is irrelevant - as long as
|
||||
it's positive, the child receives all the extra space.
|
||||
|
||||
The images show the `FlexBox` behavior when its container size is `600dp`.
|
||||
|
||||
|---|---|
|
||||
| ```kotlin FlexBox { RedRoundedBox( title = "400dp", modifier = Modifier.flex { grow(1f) } ) BlueRoundedBox(title = "100dp") GreenRoundedBox(title = "100dp") } ``` | Each child has a basis value of `100dp`. There is `300dp` of extra space.  Child 1 grows by `300dp` to fill the extra space.  |
|
||||
|
||||
In the following example, the container size and `basis` size are the same. The difference is that each child has a different `grow` value.
|
||||
In the following example, the container size and `basis` size are the same. The
|
||||
difference is that each child has a different `grow` value.
|
||||
|
||||
|---|---|
|
||||
| ```kotlin FlexBox { RedRoundedBox( title = "150dp", modifier = Modifier.flex { grow(1f) } ) BlueRoundedBox( title = "200dp", modifier = Modifier.flex { grow(2f) } ) GreenRoundedBox( title = "250dp", modifier = Modifier.flex { grow(3f) } ) } ``` | Each child has a basis value of `100dp`. There is `300dp` of extra space.  The total grow value is 6. Child 1 grows by (1 / 6) \* 300 = `50dp` Child 2 grows by (2 / 6) \* 300 = `100dp` Child 3 grows by (3 / 6) \* 300 = `150dp`  |
|
||||
|
||||
### Shrink items when there's insufficient space
|
||||
|
||||
Use `shrink` to specify how much an item shrinks when the `FlexBox` container has insufficient space for all the items. `shrink` works the same way as `grow` except that, instead of distributing *extra space* to items, the *space deficit* is distributed to items. The `shrink` value specifies how much of the space deficit the item receives, or rather, how much the item will shrink by. By default, items have a `shrink` value of `1f`, meaning they shrink equally.
|
||||
Use `shrink` to specify how much an item shrinks when the `FlexBox` container
|
||||
has insufficient space for all the items. `shrink` works the same way as `grow`
|
||||
except that, instead of distributing *extra space* to items, the *space deficit*
|
||||
is distributed to items. The `shrink` value specifies how much of the space
|
||||
deficit the item receives, or rather, how much the item will shrink by. By
|
||||
default, items have a `shrink` value of `1f`, meaning they shrink equally.
|
||||
|
||||
The following example shows two `Text` composables with the same text. The first child has a shrink value of `1f`, meaning it shrinks to absorb all the space deficit.
|
||||
The following example shows two `Text` composables with the same text. The first
|
||||
child has a shrink value of `1f`, meaning it shrinks to absorb all the space
|
||||
deficit.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox {
|
||||
@@ -74,7 +91,6 @@ FlexBox {
|
||||
.flex { shrink(0f) }
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -89,11 +105,14 @@ As the container size shrinks, Child 1 shrinks.
|
||||
|
||||
## Item alignment
|
||||
|
||||
Use `alignSelf` to control how an item is aligned to the cross axis. This overrides the [`alignItems` property](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#align-distribute) of the container for this item. It has all the same possible values, with the addition of `Auto` which inherits the behavior of the `FlexBox` container.
|
||||
Use `alignSelf` to control how an item is aligned to the cross axis. This
|
||||
overrides the [`alignItems` property](https://developer.android.com/develop/ui/compose/layouts/adaptive/flexbox/container-behavior#align-distribute) of the container for this item. It
|
||||
has all the same possible values, with the addition of `Auto` which inherits the
|
||||
behavior of the `FlexBox` container.
|
||||
|
||||
For example, this `FlexBox` has `alignItems` set to `Start` and five children which override the cross axis alignment.
|
||||
For example, this `FlexBox` has `alignItems` set to `Start` and five children
|
||||
which override the cross axis alignment.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox(
|
||||
@@ -107,7 +126,6 @@ FlexBox(
|
||||
PinkRoundedBox(modifier = Modifier.flex { alignSelf(FlexAlignSelf.Stretch) })
|
||||
OrangeRoundedBox(modifier = Modifier.flex { alignSelf(FlexAlignSelf.Baseline) })
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -116,13 +134,19 @@ FlexBox(
|
||||
|
||||
## Item order
|
||||
|
||||
By default, `FlexBox` lays out items in the order that they are declared in code. Override this behavior using `order`.
|
||||
By default, `FlexBox` lays out items in the order that they are declared in
|
||||
code. Override this behavior using `order`.
|
||||
|
||||
The default value for `order` is zero, and `FlexBox` sorts items based on this value in ascending order. Any items that have the same `order` value are laid out in the same order they are declared in. Use negative and positive `order` values to move items to the start or end of a layout without changing where they are declared.
|
||||
The default value for `order` is zero, and `FlexBox` sorts items based on this
|
||||
value in ascending order. Any items that have the same `order` value are
|
||||
laid out in the same order they are declared in. Use negative and positive
|
||||
`order` values to move items to the start or end of a layout without changing
|
||||
where they are declared.
|
||||
|
||||
The following example shows two child items. The first has the default `order` of zero, and the second has an order of `-1`. After sorting, Child 1 appears after Child 2.
|
||||
The following example shows two child items. The first has the default `order`
|
||||
of zero, and the second has an order of `-1`. After sorting, Child 1 appears
|
||||
after Child 2.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
FlexBox {
|
||||
@@ -139,7 +163,6 @@ FlexBox {
|
||||
}
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
+157
-34
@@ -1,4 +1,6 @@
|
||||
You can define a Grid container configuration to create flexible layouts that respond to different screen sizes and content types. This page describes how to do the following:
|
||||
You can define a Grid container configuration to create flexible layouts
|
||||
that respond to different screen sizes and content types.
|
||||
This page describes how to do the following:
|
||||
|
||||
- [Define a grid](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties#grid-definition): Set up the basic structure of rows and columns.
|
||||
- [Place items in a grid](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties#item-placement): Understand how items are placed into grid cells and how to change flow direction.
|
||||
@@ -7,9 +9,13 @@ You can define a Grid container configuration to create flexible layouts that re
|
||||
|
||||
## Define a grid
|
||||
|
||||
A grid consists of columns and rows. The [`Grid`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/Grid.composable#Grid(kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1)) composable has a `config` parameter that accepts a lambda to define the columns and rows within [`GridConfigurationScope`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope). The following example defines a grid that has three rows and two columns, each with a fixed size specified in [`Dp`](https://developer.android.com/reference/kotlin/androidx/compose/ui/unit/Dp):
|
||||
A grid consists of columns and rows.
|
||||
The [`Grid`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/Grid.composable#Grid(kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1)) composable has a `config` parameter
|
||||
that accepts a lambda to define the columns and rows
|
||||
within [`GridConfigurationScope`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope).
|
||||
The following example defines a grid that has three rows and two columns,
|
||||
each with a fixed size specified in [`Dp`](https://developer.android.com/reference/kotlin/androidx/compose/ui/unit/Dp):
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -23,18 +29,26 @@ Grid(
|
||||
}
|
||||
) {
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Place items in a grid
|
||||
|
||||
`Grid` takes the UI elements in the `content` lambda and places them into grid cells. The grid lays out items regardless of whether you have explicitly defined the rows and columns. By default, `Grid` tries to place a UI element in the available grid cell in the row; if it can't, it places it in an available grid cell in the next row. If there are no empty cells, `Grid` creates a new row.
|
||||
`Grid` takes the UI elements
|
||||
in the `content` lambda and places them into grid cells.
|
||||
The grid lays out items regardless of
|
||||
whether you have explicitly defined the rows and columns.
|
||||
By default,
|
||||
`Grid` tries to place a UI element in the available grid cell in the row;
|
||||
if it can't, it places it in an available grid cell in the next row.
|
||||
If there are no empty cells, `Grid` creates a new row.
|
||||
|
||||
In the following example, the grid has six grid cells and places a card into each one (Figure 1). Each grid cell is `160dp` x `90dp`, making the total grid size `320dp` x `270dp`.
|
||||
In the following example, the grid has six grid cells
|
||||
and places a card into each one (Figure 1).
|
||||
Each grid cell is `160dp` x `90dp`,
|
||||
making the total grid size `320dp` x `270dp`.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -54,16 +68,15 @@ Grid(
|
||||
Card5()
|
||||
Card6()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
 **Figure 1**. Six cards are placed in a grid that has three rows and two columns.
|
||||
|
||||
To change this default behavior to filling by column, set the [`flow`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#flow()) property to [`GridFlow.Column`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridFlow#Column()).
|
||||
To change this default behavior to filling by column,
|
||||
set the [`flow`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#flow()) property to [`GridFlow.Column`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridFlow#Column()).
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -85,7 +98,6 @@ Grid(
|
||||
Card5()
|
||||
Card6()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -94,16 +106,17 @@ Grid(
|
||||
|
||||
## Manage track sizing
|
||||
|
||||
Rows and columns are collectively referred to as a [grid track](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-track). You can specify the size of a grid track using one of the following methods:
|
||||
Rows and columns are collectively referred to as a [grid track](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-track).
|
||||
You can specify the size of a grid track using one of the following methods:
|
||||
|
||||
- **Fixed** (`Dp`): Allocates a specific size (e.g., `column(180.dp)`).
|
||||
- **Percentage** (`Float`): Allocates a percentage of the total available space from `0.0f` to `1.0f` (e.g., `row(0.5f)` for 50%).
|
||||
- **Flexible** ([`Fr`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/Fr)): Distributes remaining space proportionally after fixed and percentage tracks are calculated. For example, if two rows are set to `1.fr` and `3.fr`, the latter receives 75% of the remaining height.
|
||||
- **Intrinsic** : Sizes the track based on the content inside it. For more information, see [Determine grid track size intrinsically](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties#intrinsic-grid-track-size).
|
||||
- **Intrinsic** : Sizes the track based on the content inside it. For more information, see [Determine grid track size intrinsically](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties#intrisic-grid-track-size).
|
||||
|
||||
The following example uses the different track sizing options to define the row heights:
|
||||
The following example uses the different track sizing options
|
||||
to define the row heights:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -123,7 +136,6 @@ Grid(
|
||||
PastelYellowCard("Auto")
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -132,11 +144,14 @@ Grid(
|
||||
|
||||
### Set the minimum size for flexible grid tracks
|
||||
|
||||
When a grid container has no remaining space, a standard flexible track can shrink to `0.dp`. To prevent this and ensure content isn't crushed, use [`GridTrackSize.MinMax`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridTrackSize#MinMax(androidx.compose.ui.unit.Dp,androidx.compose.foundation.layout.Fr)) to enforce an explicit minimum size while keeping the track flexible.
|
||||
When a grid container has no remaining space,
|
||||
a standard flexible track can shrink to `0.dp`.
|
||||
To prevent this and ensure content isn't crushed,
|
||||
use [`GridTrackSize.MinMax`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridTrackSize#MinMax(androidx.compose.ui.unit.Dp,androidx.compose.foundation.layout.Fr))
|
||||
to enforce an explicit minimum size while keeping the track flexible.
|
||||
|
||||
The following example allocates at least `100.dp` to the first row:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -156,7 +171,6 @@ Grid(
|
||||
PastelGreenCard("Flex(1.fr)")
|
||||
PastelBlueCard("Fixed(200.dp)")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -165,11 +179,18 @@ Grid(
|
||||
|
||||
### Set the minimum grid track size to place lazy lists
|
||||
|
||||
Standard flexible tracks automatically query the intrinsic sizes of their children to establish a base size. However, Jetpack Compose prohibits querying the intrinsic sizes of [`SubcomposeLayout`](https://developer.android.com/reference/kotlin/androidx/compose/ui/layout/SubcomposeLayout.composable#SubcomposeLayout(androidx.compose.ui.Modifier,kotlin.Function2)), which backs components, such as [`LazyColumn`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/LazyColumn.composable) and [`LazyRow`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/LazyRow.composable).
|
||||
Standard flexible tracks automatically query the intrinsic sizes of
|
||||
their children to establish a base size.
|
||||
However, Jetpack Compose prohibits querying the intrinsic sizes of
|
||||
[`SubcomposeLayout`](https://developer.android.com/reference/kotlin/androidx/compose/ui/layout/SubcomposeLayout.composable#SubcomposeLayout(androidx.compose.ui.Modifier,kotlin.Function2)), which backs components,
|
||||
such as [`LazyColumn`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/LazyColumn.composable) and [`LazyRow`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/LazyRow.composable).
|
||||
|
||||
Placing a lazy list inside a standard flexible track causes an [`IllegalStateException`](https://developer.android.com/reference/java/lang/IllegalStateException) crash. To safely place lazy lists inside a flexible grid track, use `MinMax` with an explicit minimum size (such as `0.dp`) to bypass the intrinsic measurement pass.
|
||||
Placing a lazy list inside a standard flexible track causes
|
||||
an [`IllegalStateException`](https://developer.android.com/reference/java/lang/IllegalStateException) crash.
|
||||
To safely place lazy lists inside a flexible grid track,
|
||||
use `MinMax` with an explicit minimum size (such as `0.dp`)
|
||||
to bypass the intrinsic measurement pass.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -192,7 +213,6 @@ Grid(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -201,15 +221,20 @@ Grid(
|
||||
|
||||
### Determine grid track size intrinsically
|
||||
|
||||
You can use [intrinsic sizing](https://developer.android.com/develop/ui/compose/layouts/intrinsic-measurements) for a `Grid` when you want the layout to adapt to the content, rather than forcing it into a fixed container. The grid track size is determined with the following values:
|
||||
You can use [intrinsic sizing](https://developer.android.com/develop/ui/compose/layouts/intrinsic-measurements) for a `Grid`
|
||||
when you want the layout to adapt to the content,
|
||||
rather than forcing it into a fixed container.
|
||||
The grid track size is determined with the following values:
|
||||
|
||||
- [`GridTrackSize.MaxContent`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridTrackSize#MaxContent()): Use the content's maximum intrinsic size (e.g., the width is determined by the full length of the text in a text block with no wrapping).
|
||||
- [`GridTrackSize.MinContent`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridTrackSize#MinContent()): Use the content's minimum intrinsic size (e.g., the width is determined by the longest single word in a text block).
|
||||
- [`GridTrackSize.Auto`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridTrackSize#Auto()): Use a flexible size for a track that adapts based on available space. It behaves like `MaxContent` by default, but shrinks and wraps its content to fit within the parent container.
|
||||
|
||||
The following example places two texts side by side. The column size for the first text is determined by the required minimum width to display the text, and the second column width depends on the required maximum width of the text.
|
||||
The following example places two texts side by side.
|
||||
The column size for the first text is determined
|
||||
by the required minimum width to display the text,
|
||||
and the second column width depends on the required maximum width of the text.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -223,7 +248,6 @@ Grid(
|
||||
Text("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras imperdiet.")
|
||||
Text("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras imperdiet.")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -232,9 +256,13 @@ Grid(
|
||||
|
||||
## Set gaps between rows and columns
|
||||
|
||||
Once your grid tracks are sized, you can modify the [grid gap](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-gap) to refine the spacing between the tracks. You can specify the column gap with the [`columnGap`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#columnGap(androidx.compose.ui.unit.Dp)) function, and the row gap with [`rowGap`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#rowGap(androidx.compose.ui.unit.Dp)). In the following example, there is a `16dp` gap between each row, and an `8dp` gap between each column (Figure 5).
|
||||
Once your grid tracks are sized,
|
||||
you can modify the [grid gap](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-gap) to refine the spacing between the tracks.
|
||||
You can specify the column gap with the [`columnGap`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#columnGap(androidx.compose.ui.unit.Dp)) function,
|
||||
and the row gap with [`rowGap`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#rowGap(androidx.compose.ui.unit.Dp)). In the following example,
|
||||
there is a `16dp` gap between each row,
|
||||
and an `8dp` gap between each column (Figure 5).
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -256,16 +284,17 @@ Grid(
|
||||
Card5()
|
||||
Card6()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
 **Figure 6**. Gaps between rows and columns.
|
||||
|
||||
You can also use the convenience function [`gap`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#gap(androidx.compose.ui.unit.Dp)) to define gaps of the same column and row size, and to define column and gap sizes separately using a single function. The following code adds `8dp` gaps to the grid:
|
||||
You can also use the convenience function [`gap`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#gap(androidx.compose.ui.unit.Dp))
|
||||
to define gaps of the same column and row size,
|
||||
and to define column and gap sizes separately using a single function.
|
||||
The following code adds `8dp` gaps to the grid:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -286,7 +315,101 @@ Grid(
|
||||
Card5()
|
||||
Card6()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
<br />
|
||||
|
||||
## Define grid areas with named areas
|
||||
|
||||
Named areas allow you to attach names to groups of grid cells,
|
||||
which are called [grid areas](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-area).
|
||||
You can use these names instead of [coordinate indexes](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/item-properties#position)
|
||||
when placing UI elements in the grid.
|
||||
|
||||
Using named areas has two main benefits to code readability:
|
||||
|
||||
- When defining the grid layout, the purpose and placement of the expected content is clear.
|
||||
- When adding the content, the purpose of that content is clear.
|
||||
|
||||
To organize complex layouts clearly, you can decouple your physical grid
|
||||
structure from child placement by defining semantic grid areas.
|
||||
|
||||
Inside the `config` lambda, use the [`area`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridConfigurationScope#area(kotlin.Any,kotlin.Int,kotlin.Int,kotlin.Int,kotlin.Int)) function in
|
||||
`GridConfigurationScope` to register named areas in the grid.
|
||||
You can then assign child composables to these areas
|
||||
using the [`gridItem`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridScope#(androidx.compose.ui.Modifier).gridItem(kotlin.Any,androidx.compose.ui.Alignment)) modifier
|
||||
with the corresponding area identifier. The `area` function maps
|
||||
a semantic identifier (such as an `enum` class value or a string key) to
|
||||
a set of physical grid coordinates. Grid lines and indexes are **1-based**
|
||||
(that is, the first row is `1`, and the first column is `1`).
|
||||
|
||||
For example, you define a grid that has four area IDs:
|
||||
|
||||
|
||||
```kotlin
|
||||
/**
|
||||
* An enum representing the IDs for named areas within the grid.
|
||||
*/
|
||||
enum class GridAreaNames {
|
||||
Area1,
|
||||
Area2,
|
||||
Area3,
|
||||
Area4
|
||||
}
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Provide the name for the area using the `areaId` parameter along with the area's
|
||||
cell coordinates and spans.
|
||||
The `gridItem` modifier uses the `areaId` as a key
|
||||
to assign each child item to its designated grid area,
|
||||
as shown in the following example:
|
||||
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
config = {
|
||||
// Define a single column that takes all available width.
|
||||
repeat(2) { column(0.5f) }
|
||||
|
||||
// Define four rows, each taking 25% of the total height.
|
||||
repeat(4) { row(0.25f) }
|
||||
|
||||
// Define named grid areas by associating an areaId with specific row and column indices.
|
||||
// Row and column indices are 1-based.
|
||||
area(areaId = GridAreaNames.Area1, row = 1, column = 1, columnSpan = 2)
|
||||
area(areaId = GridAreaNames.Area2, row = 2, column = 1, rowSpan = 3)
|
||||
area(areaId = GridAreaNames.Area3, rows = 2..3, columns = 2..2)
|
||||
area(areaId = GridAreaNames.Area4, row = 4, column = 2)
|
||||
|
||||
gap(4.dp)
|
||||
},
|
||||
modifier = Modifier.size(360.dp)
|
||||
) {
|
||||
PastelRedCard(
|
||||
"Area 1",
|
||||
// Use Modifier.gridItem(areaId) to place this composable into the
|
||||
// grid area defined with the matching ID in the config block.
|
||||
modifier = Modifier.gridItem(areaId = GridAreaNames.Area1)
|
||||
)
|
||||
PastelGreenCard(
|
||||
"Area 2",
|
||||
modifier = Modifier.gridItem(areaId = GridAreaNames.Area2)
|
||||
)
|
||||
PastelBlueCard(
|
||||
"Area 3",
|
||||
modifier = Modifier.gridItem(areaId = GridAreaNames.Area3)
|
||||
)
|
||||
PastelYellowCard(
|
||||
"Area 4",
|
||||
modifier = Modifier.gridItem(areaId = GridAreaNames.Area4)
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
By using named areas, you can reorganize or adjust the physical layout grid (for
|
||||
example, changing rows, columns, or track sizes) in the `config` lambda
|
||||
without needing to modify the order or parameters of the child composables.
|
||||
+7
-6
@@ -2,10 +2,11 @@ This page describes how to implement basic [`Grid`](https://developer.android.co
|
||||
|
||||
## Set up project
|
||||
|
||||
1. Add the [`androidx.compose.foundation.layout`](https://developer.android.com/jetpack/androidx/versions) library to your project's `lib.versions.toml`.
|
||||
1. Add the [`androidx.compose.foundation.layout`](https://developer.android.com/jetpack/androidx/versions) library to your project's
|
||||
`lib.versions.toml`.
|
||||
|
||||
[versions]
|
||||
compose = "1.12.0-rc01"
|
||||
compose = "1.13.0-alpha01"
|
||||
|
||||
[libraries]
|
||||
androidx-compose-foundation-layout = { group = "androidx.compose.foundation", name = "foundation-layout", version.ref = "compose" }
|
||||
@@ -18,9 +19,9 @@ This page describes how to implement basic [`Grid`](https://developer.android.co
|
||||
|
||||
## Create a basic grid
|
||||
|
||||
The following example creates a basic 2x3 grid, with the columns and rows having a fixed size of `100.dp`.
|
||||
The following example creates a basic 2x3 grid,
|
||||
with the columns and rows having a fixed size of `100.dp`.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -40,11 +41,11 @@ Grid(
|
||||
Card5(containerColor = PastelOrange)
|
||||
Card6(containerColor = PastelYellow)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
 **Figure 1**. A basic grid consists of rows and columns with fixed size.
|
||||
|
||||
To learn how to implement more advanced grids, see [Set container properties](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties) and [Set item properties](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/item-properties).
|
||||
To learn how to implement more advanced grids,
|
||||
see [Set container properties](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties) and [Set item properties](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/item-properties).
|
||||
+31
-9
@@ -1,16 +1,27 @@
|
||||
> [!NOTE]
|
||||
> **Note:** `Grid` is an experimental API and is subject to change. File any issues on the [issue tracker](https://issuetracker.google.com/issues/new?component=1876021&template=1424126).
|
||||
|
||||
[`Grid`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/Grid.composable#Grid(kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1)) is a Jetpack Compose API that lets you flexibly implement a two-dimensional layout. With this API, you can display items in multi-column or multi-row layouts that adapt to the available container size.
|
||||
[`Grid`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/Grid.composable#Grid(kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1)) is a Jetpack Compose API
|
||||
that lets you flexibly implement a two-dimensional layout.
|
||||
With this API, you can display items in multi-column
|
||||
or multi-row layouts that adapt to the available container size.
|
||||
 **Figure 1.** A flexible and adaptive two-dimensional layout with `Grid`.
|
||||
|
||||
## How is Grid different from similar composables?
|
||||
|
||||
Compose already offers similar components, such as [`LazyVerticalGrid`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/grid/LazyVerticalGrid.composable#LazyVerticalGrid(androidx.compose.foundation.lazy.grid.GridCells,androidx.compose.ui.Modifier,androidx.compose.foundation.lazy.grid.LazyGridState,androidx.compose.foundation.layout.PaddingValues,kotlin.Boolean,androidx.compose.foundation.layout.Arrangement.Vertical,androidx.compose.foundation.layout.Arrangement.Horizontal,androidx.compose.foundation.gestures.FlingBehavior,kotlin.Boolean,androidx.compose.foundation.OverscrollEffect,kotlin.Function1)). These components are mainly for visualization of large, homogeneous data sets--- for example, displaying a content catalog in a video streaming app. These components are NOT designed for the structural layout of a screen or complex component.
|
||||
Compose already offers similar components, such as [`LazyVerticalGrid`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/grid/LazyVerticalGrid.composable#LazyVerticalGrid(androidx.compose.foundation.lazy.grid.GridCells,androidx.compose.ui.Modifier,androidx.compose.foundation.lazy.grid.LazyGridState,androidx.compose.foundation.layout.PaddingValues,kotlin.Boolean,androidx.compose.foundation.layout.Arrangement.Vertical,androidx.compose.foundation.layout.Arrangement.Horizontal,androidx.compose.foundation.gestures.FlingBehavior,kotlin.Boolean,androidx.compose.foundation.OverscrollEffect,kotlin.Function1)).
|
||||
These components are mainly for visualization of large, homogeneous data sets---
|
||||
for example, displaying a content catalog in a video streaming app.
|
||||
These components are NOT designed
|
||||
for the structural layout of a screen or complex component.
|
||||
|
||||
You can also implement a two-dimensional layout by combining multiple `Row` and `Column` composables. However, this approach has some downsides, such as deep hierarchies and difficulties in adaptability.
|
||||
You can also implement a two-dimensional layout
|
||||
by combining multiple `Row` and `Column` composables.
|
||||
However, this approach has some downsides,
|
||||
such as deep hierarchies and difficulties in adaptability.
|
||||
|
||||
The following table provides an overview of which layouts are suitable for each API:
|
||||
The following table provides an overview
|
||||
of which layouts are suitable for each API:
|
||||
|
||||
| Component | Purpose |
|
||||
|---|---|
|
||||
@@ -23,16 +34,24 @@ The following table provides an overview of which layouts are suitable for each
|
||||
|
||||
## Terminology
|
||||
|
||||
Familiarize yourself with the following terminology to understand how `Grid` works.
|
||||
Familiarize yourself with the following terminology
|
||||
to understand how `Grid` works.
|
||||
|
||||
### Grid line
|
||||
|
||||
A grid is made up of lines, which run horizontally and vertically. If your grid has three rows, it has four horizontal lines, including the one after the last row. In the following image, each dotted line represents a grid line:
|
||||
A grid is made up of lines, which run horizontally and vertically.
|
||||
If your grid has three rows, it has four horizontal lines,
|
||||
including the one after the last row.
|
||||
In the following image, each dotted line represents a grid line:
|
||||
 **Figure 2**. The grid consists of four horizontal lines and three vertical lines.
|
||||
|
||||
### Grid track
|
||||
|
||||
A grid track is the space between two grid lines. A row track is between two horizontal lines, and a column track is between two vertical lines. To define the size of these tracks, assign a size to them when you create the grid.
|
||||
A grid track is the space between two grid lines.
|
||||
A row track is between two horizontal lines,
|
||||
and a column track is between two vertical lines.
|
||||
To define the size of these tracks,
|
||||
assign a size to them when you create the grid.
|
||||
 **Figure 3**. A grid track for the first row.
|
||||
|
||||
### Grid cell
|
||||
@@ -42,10 +61,13 @@ A grid cell is the intersection of a row and column track.
|
||||
|
||||
### Grid area
|
||||
|
||||
A grid area consists of several grid cells. You can define a grid area by making an item span multiple tracks.
|
||||
A grid area consists of several grid cells.
|
||||
You can define a grid area by making an item span multiple tracks.
|
||||
 **Figure 5**. A grid area that consists of four grid cells.
|
||||
|
||||
### Grid gap
|
||||
|
||||
A grid gap is the gutter between grid tracks. You can't place a UI element into a gap, but you can span a UI element across it.
|
||||
A grid gap is the gutter between grid tracks.
|
||||
You can't place a UI element into a gap,
|
||||
but you can span a UI element across it.
|
||||
 **Figure 6**. A grid gap between the first column and the second column.
|
||||
+43
-17
@@ -1,18 +1,35 @@
|
||||
While the `Grid` config defines the overall structure, you use the [`gridItem`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridScope#(androidx.compose.ui.Modifier).gridItem(kotlin.Int,kotlin.Int,kotlin.Int,kotlin.Int,androidx.compose.ui.Alignment)) modifier to control the position, spanning, and alignment of items within that structure.
|
||||
While the `Grid` config defines the overall structure,
|
||||
you use the [`gridItem`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridScope#(androidx.compose.ui.Modifier).gridItem(kotlin.Int,kotlin.Int,kotlin.Int,kotlin.Int,androidx.compose.ui.Alignment)) modifier to control the position, spanning,
|
||||
and alignment of items within that structure.
|
||||
|
||||
## Set the item position
|
||||
|
||||
Place an item into a specific track or cell with the `row` and `column` parameters.
|
||||
Place an item into a specific track or cell
|
||||
with the `row` and `column` parameters.
|
||||
Coordinate indexes work best for straightforward grid layouts.
|
||||
For larger or more complex layouts, define [named areas](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid/container-properties#named-area) instead.
|
||||
|
||||
The `row` and `column` parameters specify the row and column track indexes that the item is placed in. Track indexes are 1-based---they start at one. Specifying only `row` or `column` (not both) places the item in the next available space in that track. Specifying both places the item into that cell.
|
||||
The `row` and `column` parameters specify the row and column track indexes
|
||||
that the item is placed in.
|
||||
Track indexes are 1-based---they start at one.
|
||||
Specifying only `row` or `column` (not both) places the item
|
||||
in the next available space in that track.
|
||||
Specifying both places the item into that cell.
|
||||
|
||||
Use a positive integer to specify the track index from the start. For example, to place an item in the first row and column, use `gridItem(row = 1, column = 1)`.
|
||||
Use a positive integer to specify the track index from the start.
|
||||
For example, to place an item in the first row and column,
|
||||
use `gridItem(row = 1, column = 1)`.
|
||||
|
||||
Use a negative integer to specify the track relative to the end. For example, to place an item in the second-to-last row and column, use `gridItem(row = -2, column = -2)`.
|
||||
Use a negative integer to specify the track relative to the end.
|
||||
For example, to place an item in the second-to-last row and column, use
|
||||
`gridItem(row = -2, column = -2)`.
|
||||
|
||||
In the following example, Card **#2** is placed in the second row and the second column. Card **#3** is assigned to the last row (indexed by -1), where it automatically occupies the first available column in that track (Figure 1).
|
||||
In the following example, Card **#2** is placed
|
||||
in the second row and the second column.
|
||||
Card **#3** is assigned to the last row (indexed by -1),
|
||||
where it automatically occupies
|
||||
the first available column in that track (Figure 1).
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -30,7 +47,6 @@ Grid(
|
||||
Card2(modifier = Modifier.gridItem(row = 2, column = 2))
|
||||
Card3(modifier = Modifier.gridItem(row = -1, column = -2))
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -41,9 +57,16 @@ and Card #3 is placed in the first column in the third row.](https://developer.a
|
||||
|
||||
## Span rows and columns
|
||||
|
||||
Use the `rowSpan` and `columnSpan` parameters to span an item over multiple cells. You can place a UI element into a [grid area](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-area), which is the area consisting of several [grid cells](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-cell). The `gridItem` modifier lets you specify the grid area with the `rowSpan` and `columnSpan` parameters. In the following example, Card **#1** is placed in the area consisting of two rows and two columns (Figure 2).
|
||||
Use the `rowSpan` and `columnSpan` parameters
|
||||
to span an item over multiple cells.
|
||||
You can place a UI element into a [grid area](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-area),
|
||||
which is the area consisting of several [grid cells](https://developer.android.com/develop/ui/compose/layouts/adaptive/grid#grid-cell).
|
||||
The `gridItem` modifier lets you specify the grid area
|
||||
with the `rowSpan` and `columnSpan` parameters.
|
||||
In the following example,
|
||||
Card **#1** is placed in the area consisting of two rows and two columns
|
||||
(Figure 2).
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -63,7 +86,6 @@ Grid(
|
||||
Card3()
|
||||
Card4(modifier = Modifier.gridItem(columnSpan = 3))
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -72,9 +94,11 @@ Grid(
|
||||
|
||||
## Set the alignment in a grid area
|
||||
|
||||
You can set the alignment of the UI element in a grid area by specifying it in the `alignment` parameter of the [`gridItem`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridScope#(androidx.compose.ui.Modifier).gridItem(kotlin.Int,kotlin.Int,kotlin.Int,kotlin.Int,androidx.compose.ui.Alignment)) modifier. In the following example, **#1** is placed in the center of the grid area consisting of two columns and two rows.
|
||||
You can set the alignment of the UI element in a grid area
|
||||
by specifying it in the `alignment` parameter of the [`gridItem`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/GridScope#(androidx.compose.ui.Modifier).gridItem(kotlin.Int,kotlin.Int,kotlin.Int,kotlin.Int,androidx.compose.ui.Alignment)) modifier.
|
||||
In the following example, **#1** is placed in the center of the grid area
|
||||
consisting of two columns and two rows.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -102,7 +126,6 @@ Grid(
|
||||
Card3()
|
||||
Card4(modifier = Modifier.gridItem(columnSpan = 3))
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -112,9 +135,13 @@ consisting of two rows and two columns.](https://developer.android.com/static/de
|
||||
|
||||
## Auto-placement mixed with placed items
|
||||
|
||||
A UI element in `Grid` that has no position specification undergoes auto-placement. This example shows how you can mix auto-placed elements and the UI elements with specified grid cells. Card **#2** and Card **#4** are placed in specified grid cells, and the other items are auto-placed.
|
||||
A UI element in `Grid`
|
||||
that has no position specification undergoes auto-placement.
|
||||
This example shows how you can mix auto-placed elements
|
||||
and the UI elements with specified grid cells.
|
||||
Card **#2** and Card **#4** are placed in specified grid cells,
|
||||
and the other items are auto-placed.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Grid(
|
||||
@@ -136,7 +163,6 @@ Grid(
|
||||
Card5()
|
||||
Card6()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
+102
-40
@@ -1,7 +1,10 @@
|
||||
> [!NOTE]
|
||||
> **Note:** The `mediaQuery` function and the related data types are experimental and subject to change. File any issues on the [issue tracker](https://issuetracker.google.com/issues?q=componentid:1876021).
|
||||
|
||||
You need various types of information, such as device capability and app status, to update your app layout. Window width and height are the most commonly used information. In addition to that, you can refer to the following information:
|
||||
You need various types of information, such as device capability
|
||||
and app status, to update your app layout.
|
||||
Window width and height are the most commonly used information.
|
||||
In addition to that, you can refer to the following information:
|
||||
|
||||
- Window posture
|
||||
- Pointing devices precision
|
||||
@@ -9,9 +12,17 @@ You need various types of information, such as device capability and app status,
|
||||
- Whether the camera and microphone are supported by the device
|
||||
- The distance between a user and the device display
|
||||
|
||||
Because the information is updated dynamically, you need to monitor it and trigger recomposition when any update happens. The [`mediaQuery`](https://developer.android.com/reference/kotlin/androidx/compose/ui/mediaQuery.composable#mediaQuery(kotlin.Function1)) function abstracts the details of the information retrieval and lets you focus on defining the condition to trigger the layout updates. The following example switches the layout to `TabletopLayout` when the foldable posture is tabletop:
|
||||
Because the information is updated dynamically,
|
||||
you need to monitor it and trigger recomposition when any update happens.
|
||||
The [`mediaQuery`](https://developer.android.com/reference/kotlin/androidx/compose/ui/mediaQuery.composable#mediaQuery(kotlin.Function1)) function abstracts the details of the information retrieval
|
||||
and lets you focus on defining the condition to trigger the layout updates.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** "media" refers to the presentation medium that the UI is rendered on. The term "media" originates from [CSS media queries](https://www.w3.org/TR/mediaqueries-3/) which inspired the `mediaQuery` API.
|
||||
|
||||
The following example switches the layout to `TabletopLayout`
|
||||
when the foldable posture is tabletop:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -26,16 +37,16 @@ fun VideoPlayer(
|
||||
}
|
||||
// ...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Enable the `mediaQuery` function
|
||||
|
||||
To enable the `mediaQuery` function, set the `isMediaQueryIntegrationEnabled` attribute of the [`ComposeUiFlags`](https://developer.android.com/reference/kotlin/androidx/compose/ui/ComposeUiFlags) object to `true`:
|
||||
To enable the `mediaQuery` function,
|
||||
set the `isMediaQueryIntegrationEnabled` attribute of
|
||||
the [`ComposeUiFlags`](https://developer.android.com/reference/kotlin/androidx/compose/ui/ComposeUiFlags) object to `true`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class MyApplication : Application() {
|
||||
@@ -44,14 +55,20 @@ class MyApplication : Application() {
|
||||
super.onCreate()
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Define a condition with parameters
|
||||
|
||||
You can define a condition as a lambda that is evaluated within [`UiMediaScope`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope). The `mediaQuery` function evaluates the condition according to the current status and the device capabilities. The function returns a boolean value, so you can determine the layout with conditional branches like an `if` expression. Table 1 describes the parameters available in `UiMediaScope`.
|
||||
You can define a condition as a lambda
|
||||
that is evaluated within [`UiMediaScope`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope).
|
||||
The `mediaQuery` function evaluates the condition according to
|
||||
the current status and the device capabilities.
|
||||
The function returns a boolean value,
|
||||
so you can determine the layout with conditional branches
|
||||
like an `if` expression.
|
||||
Table 1 describes the parameters available in `UiMediaScope`.
|
||||
|
||||
| Parameter | Value type | Description |
|
||||
|---|---|---|
|
||||
@@ -64,9 +81,17 @@ You can define a condition as a lambda that is evaluated within [`UiMediaScope`]
|
||||
| `hasMicrophone` | `Boolean` | Whether the microphone is supported on the device. |
|
||||
| `viewingDistance` | [`UiMediaScope.ViewingDistance`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance) | The typical distance between the user and the device screen. |
|
||||
|
||||
A `UiMediaScope` object resolves the values of the parameters. The `mediaQuery` function uses [`LocalUiMediaScope.current`](https://developer.android.com/reference/kotlin/androidx/compose/ui/package-summary#LocalUiMediaScope()) to access the `UiMediaScope` object, which represents the current device capabilities and context. This object is dynamically updated when any changes are made, such as when the user changes the device posture. The `mediaQuery` function then evaluates the `query` lambda with the updated `UiMediaScope` object and returns a boolean value. For example, the following snippet chooses between `TabletopLayout` and `FlatLayout` based on the `windowPosture` parameter value.
|
||||
A `UiMediaScope` object resolves the values of the parameters.
|
||||
The `mediaQuery` function uses [`LocalUiMediaScope.current`](https://developer.android.com/reference/kotlin/androidx/compose/ui/package-summary#LocalUiMediaScope())
|
||||
to access the `UiMediaScope` object,
|
||||
which represents the current device capabilities and context.
|
||||
This object is dynamically updated when any changes are made,
|
||||
such as when the user changes the device posture.
|
||||
The `mediaQuery` function then evaluates the `query` lambda
|
||||
with the updated `UiMediaScope` object and returns a boolean value.
|
||||
For example, the following snippet chooses between `TabletopLayout`
|
||||
and `FlatLayout` based on the `windowPosture` parameter value.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -81,18 +106,26 @@ fun VideoPlayer(
|
||||
}
|
||||
// ...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Make a decision based on the window size
|
||||
|
||||
[Window size classes](https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes) are a set of opinionated viewport breakpoints that help you design, develop, and test adaptive layouts. You can compare the two parameters representing the current window size with the threshold defined in the window size classes. The following example changes the number of panes according to the window width. [`WindowSizeClass`](https://developer.android.com/reference/androidx/window/core/layout/WindowSizeClass) class has constants for the thresholds of window size classes (Figure 1).
|
||||
[Window size classes](https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes) are a set of opinionated viewport breakpoints
|
||||
that help you design, develop, and test adaptive layouts.
|
||||
You can compare the two parameters representing the current window size
|
||||
with the threshold defined in the window size classes.
|
||||
The following example changes the number of panes according to the window width.
|
||||
[`WindowSizeClass`](https://developer.android.com/reference/androidx/window/core/layout/WindowSizeClass) class has constants for the thresholds
|
||||
of window size classes (Figure 1).
|
||||
|
||||
The [`derivedMediaQuery`](https://developer.android.com/reference/kotlin/androidx/compose/ui/derivedMediaQuery.composable#derivedMediaQuery(kotlin.Function1)) function evaluates the `query` lambda and wraps the result in a [`derivedStateOf`](https://developer.android.com/develop/ui/compose/side-effects#derivedstateof). Because `windowWidth` and `windowHeight` can update frequently, call the `derivedMediaQuery` function instead of the `mediaQuery` function when you refer to those parameters in the `query` lambda.
|
||||
The [`derivedMediaQuery`](https://developer.android.com/reference/kotlin/androidx/compose/ui/derivedMediaQuery.composable#derivedMediaQuery(kotlin.Function1)) function evaluates the `query` lambda
|
||||
and wraps the result in a [`derivedStateOf`](https://developer.android.com/develop/ui/compose/side-effects#derivedstateof).
|
||||
Because `windowWidth` and `windowHeight` can update frequently,
|
||||
call the `derivedMediaQuery` function instead of the `mediaQuery` function
|
||||
when you refer to those parameters in the `query` lambda.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val narrowerThanMedium by derivedMediaQuery {
|
||||
@@ -106,7 +139,6 @@ when {
|
||||
narrowerThanExpanded -> TwoPaneLayout()
|
||||
else -> ThreePaneLayout()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -115,9 +147,12 @@ when {
|
||||
|
||||
### Update layout according to the window posture
|
||||
|
||||
The `windowPosture` parameter describes the current window posture as a `UiMediaScope.Posture` object. You can check the current [posture](https://developer.android.com/develop/ui/compose/layouts/adaptive/foldables/learn-about-foldables) by comparing the parameter with the values defined in the `UiMediaScope.Posture` class. The following example switches layout according to the window posture:
|
||||
The `windowPosture` parameter describes the current window posture
|
||||
as a `UiMediaScope.Posture` object.
|
||||
You can check the current [posture](https://developer.android.com/develop/ui/compose/layouts/adaptive/foldables/learn-about-foldables) by comparing the parameter
|
||||
with the values defined in the `UiMediaScope.Posture` class.
|
||||
The following example switches layout according to the window posture:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
when {
|
||||
@@ -125,22 +160,32 @@ when {
|
||||
mediaQuery { windowPosture == UiMediaScope.Posture.Book } -> BookLayout()
|
||||
mediaQuery { windowPosture == UiMediaScope.Posture.Flat } -> FlatLayout()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Check the precision of the available pointing device
|
||||
|
||||
A high precision pointing device helps users to point a UI element precisely. The precision of a pointing device depends on the device type.
|
||||
A high precision pointing device helps users to point a UI element precisely.
|
||||
The precision of a pointing device depends on the device type.
|
||||
|
||||
The `pointerPrecision` parameter describes the precision of the available pointing devices, such as a mouse and touchscreen. There are four values defined in the `UiMediaScope.PointerPrecision` class: [`Fine`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#Fine()), [`Coarse`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#Coarse()), [`Blunt`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#Blunt()), and [`None`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#None()). `None` means that no pointing device is available. The precision ranges from highest to lowest in this order: `Fine`, `Coarse`, and `Blunt`.
|
||||
The `pointerPrecision` parameter describes the precision
|
||||
of the available pointing devices, such as a mouse and touchscreen.
|
||||
There are four values defined in the `UiMediaScope.PointerPrecision` class:
|
||||
[`Fine`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#Fine()), [`Coarse`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#Coarse()), [`Blunt`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#Blunt()), and [`None`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.PointerPrecision#None()).
|
||||
`None` means that no pointing device is available.
|
||||
The precision ranges from highest to lowest in this order:
|
||||
`Fine`, `Coarse`, and `Blunt`.
|
||||
|
||||
If multiple pointing devices are available and their precisions are different, the parameter is resolved with the highest one. For example, if there are two pointing devices --- a `Fine` precision device and a `Blunt` precision device --- `Fine` is the value of the `pointerPrecision` parameter.
|
||||
If multiple pointing devices are available and their precisions are different,
|
||||
the parameter is resolved with the highest one.
|
||||
For example, if there are two pointing devices --- a `Fine` precision device and
|
||||
a `Blunt` precision device ---
|
||||
`Fine` is the value of the `pointerPrecision` parameter.
|
||||
|
||||
The following example shows a larger button when the user is using a pointing device with low precision:
|
||||
The following example shows a larger button
|
||||
when the user is using a pointing device with low precision:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
if (mediaQuery { pointerPrecision == UiMediaScope.PointerPrecision.Blunt }) {
|
||||
@@ -148,31 +193,38 @@ if (mediaQuery { pointerPrecision == UiMediaScope.PointerPrecision.Blunt }) {
|
||||
} else {
|
||||
NormalSizeButton()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Check the available keyboard type
|
||||
|
||||
The `keyboardKind` parameter represents the type of the available keyboards: [`Physical`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.KeyboardKind#Physical()), [`Virtual`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.KeyboardKind#Virtual()), and [`None`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.KeyboardKind#None()). If an on-screen keyboard is displayed and a hardware keyboard is available at the same time, the parameter is resolved as `Physical`. If neither is detected, `None` is the value of the parameter. The following example shows a message suggesting that users connect a keyboard when no keyboard is detected:
|
||||
The `keyboardKind` parameter represents the type of the available keyboards:
|
||||
[`Physical`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.KeyboardKind#Physical()), [`Virtual`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.KeyboardKind#Virtual()), and [`None`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.KeyboardKind#None()).
|
||||
If an on-screen keyboard is displayed and
|
||||
a hardware keyboard is available at the same time,
|
||||
the parameter is resolved as `Physical`.
|
||||
If neither is detected, `None` is the value of the parameter.
|
||||
The following example shows a message suggesting that users connect a keyboard
|
||||
when no keyboard is detected:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
if (mediaQuery { keyboardKind == UiMediaScope.KeyboardKind.None }) {
|
||||
SuggestKeyboardConnect()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Check if the device supports camera and microphone
|
||||
|
||||
Some devices don't support cameras or microphones. You can check if the device supports a camera and a microphone with the `hasCamera` parameter and the `hasMicrophone` parameter. The following example shows buttons to use with camera and microphone when the device supports them:
|
||||
Some devices don't support cameras or microphones.
|
||||
You can check if the device supports a camera and a microphone
|
||||
with the `hasCamera` parameter and the `hasMicrophone` parameter.
|
||||
The following example shows buttons to use with camera and microphone
|
||||
when the device supports them:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Row {
|
||||
@@ -186,18 +238,25 @@ Row {
|
||||
CameraButton()
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Adjust UI with the estimated viewing distance
|
||||
|
||||
Viewing distance is a factor that helps determine layout. If the user is using the app from a distance, they would expect the text and UI elements to be bigger. The `viewingDistance` parameter provides an estimate of the viewing distance based on the device type and its typical usage context.
|
||||
Viewing distance is a factor that helps determine layout.
|
||||
If the user is using the app from a distance,
|
||||
they would expect the text and UI elements to be bigger.
|
||||
The `viewingDistance` parameter provides an estimate of the viewing distance
|
||||
based on the device type and its typical usage context.
|
||||
|
||||
There are three values defined in the `UiMediaScope.ViewingDistance` class: [`Near`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance#Near()), [`Medium`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance#Medium()), and [`Far`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance#Far()). `Near` means that the screen is in close range, and `Far` means that the device is viewed from a distance. The following example increases the font size when the viewing distance is `Far` or `Medium`:
|
||||
There are three values defined in the `UiMediaScope.ViewingDistance` class:
|
||||
[`Near`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance#Near()), [`Medium`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance#Medium()), and [`Far`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.ViewingDistance#Far()).
|
||||
`Near` means that the screen is in close range,
|
||||
and `Far` means that the device is viewed from a distance.
|
||||
The following example increases the font size when the viewing distance is
|
||||
`Far` or `Medium`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val fontSize = when {
|
||||
@@ -205,16 +264,19 @@ val fontSize = when {
|
||||
mediaQuery { viewingDistance == UiMediaScope.ViewingDistance.Medium } -> 18.sp
|
||||
else -> 16.sp
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Preview a UI component
|
||||
|
||||
You can call the `mediaQuery` and `derivedMediaQuery` functions in the composable functions to preview UI components. The following snippet chooses between `TabletopLayout` and `FlatLayout` based on the `windowPosture` parameter value. To preview the `TabletopLayout`, the `windowPosture` parameter should be [`UiMediaScope.Posture.Tabletop`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.Posture#Tabletop()).
|
||||
You can call the `mediaQuery` and `derivedMediaQuery` functions in the
|
||||
composable functions to preview UI components.
|
||||
The following snippet chooses between `TabletopLayout`
|
||||
and `FlatLayout` based on the `windowPosture` parameter value.
|
||||
To preview the `TabletopLayout`, the `windowPosture` parameter should be
|
||||
[`UiMediaScope.Posture.Tabletop`](https://developer.android.com/reference/kotlin/androidx/compose/ui/UiMediaScope.Posture#Tabletop()).
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
when {
|
||||
@@ -222,12 +284,14 @@ when {
|
||||
mediaQuery { windowPosture == UiMediaScope.Posture.Book } -> BookLayout()
|
||||
mediaQuery { windowPosture == UiMediaScope.Posture.Flat } -> FlatLayout()
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
The `mediaQuery` and `derivedMediaQuery` functions evaluate the given `query` lambda within a `UiMediaScope` object, which is provided as `LocalUiMediaScope.current`. You can override it with the following steps:
|
||||
The `mediaQuery` and `derivedMediaQuery` functions evaluate
|
||||
the given `query` lambda within a `UiMediaScope` object,
|
||||
which is provided as `LocalUiMediaScope.current`.
|
||||
You can override it with the following steps:
|
||||
|
||||
1. Enable the `mediaQuery` function.
|
||||
2. Define a custom object that implements the `UiMediaScope` interface.
|
||||
@@ -236,7 +300,6 @@ The `mediaQuery` and `derivedMediaQuery` functions evaluate the given `query` la
|
||||
|
||||
You can preview the `TabletopLayout` with the following example:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Preview
|
||||
@@ -265,7 +328,6 @@ fun PreviewLayoutForTabletop() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -2,29 +2,60 @@ Tools for debugging your Compose UI are available in Android Studio.
|
||||
|
||||
## Layout Inspector
|
||||
|
||||
Layout Inspector lets you inspect a Compose layout inside a running app in an emulator or physical device. You can use the Layout Inspector to check how often a composable is recomposed or skipped, which can help identify issues with your app. For example, some coding errors might force your UI to recompose excessively, which can cause [poor performance](https://developer.android.com/develop/ui/compose/performance). Some coding errors can prevent your UI from recomposing and, therefore, prevent your UI changes from showing up on the screen. If you're new to Layout inspector, check the [guidance](https://developer.android.com/studio/debug/layout-inspector) on how to run it.
|
||||
Layout Inspector lets you inspect a Compose layout inside a running app in an
|
||||
emulator or physical device. You can use the Layout Inspector to check how often
|
||||
a composable is recomposed or skipped, which can help identify issues with your
|
||||
app. For example, some coding errors might force your UI to recompose
|
||||
excessively, which can cause [poor performance](https://developer.android.com/develop/ui/compose/performance).
|
||||
Some coding errors can prevent your UI from recomposing and, therefore,
|
||||
prevent your UI changes from showing up on the screen. If you're new to
|
||||
Layout inspector, check the [guidance](https://developer.android.com/studio/debug/layout-inspector) on how to
|
||||
run it.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If you're not seeing Compose components in layout inspector, make sure you are not removing `META-INF/androidx.compose.*.version` files from the APK. These are required for layout inspector to work.
|
||||
|
||||
### Get recomposition counts
|
||||
|
||||
When debugging your Compose layouts, knowing when composables [recompose](https://developer.android.com/develop/ui/compose/mental-model#recomposition) is important in understanding whether your UI is implemented properly. For example, if it's recomposing too many times, your app might be doing more work than is necessary. On the other hand, components that don't recompose when you anticipate them to can lead to unexpected behaviors.
|
||||
When debugging your Compose layouts, knowing when composables
|
||||
[recompose](https://developer.android.com/develop/ui/compose/mental-model#recomposition) is important in
|
||||
understanding whether your UI is implemented properly. For example, if it's
|
||||
recomposing too many times, your app might be doing more work than is necessary.
|
||||
On the other hand, components that don't recompose when you anticipate them to
|
||||
can lead to unexpected behaviors.
|
||||
|
||||
The Layout Inspector shows you when discrete composables in your layout hierarchy have either recomposed or skipped, as you interact with your app. In Android Studio, your recompositions are highlighted to help you determine where in the UI your composables are recomposing.
|
||||
The Layout Inspector shows you when discrete composables in your layout
|
||||
hierarchy have either recomposed or skipped, as you interact with your app. In
|
||||
Android Studio, your recompositions are highlighted to help you determine
|
||||
where in the UI your composables are recomposing.
|
||||
|
||||
**Figure 1.** Recompositions are highlighted in Layout Inspector.
|
||||
|
||||
The highlighted portion shows a gradient overlay of the composable in the image section of the Layout Inspector, and gradually disappears so that you can get an idea of where in the UI the composable with the highest recompositions can be found. If one composable is recomposing at a higher rate than another composable, then the first composable receives a stronger gradient overlay color. If you double-click a composable in the layout inspector, you're taken to the corresponding code for analysis.
|
||||
The highlighted portion shows a gradient overlay of the composable in the image
|
||||
section of the Layout Inspector, and gradually disappears so that you can get an
|
||||
idea of where in the UI the composable with the highest recompositions can be
|
||||
found. If one composable is recomposing at a higher rate than another
|
||||
composable, then the first composable receives a stronger gradient overlay
|
||||
color. If you double-click a composable in the layout inspector, you're taken to
|
||||
the corresponding code for analysis.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** To view recomposition counts, make sure your app is using an API level of 29 or higher, and `Compose 1.2.0` or higher. Then, deploy your app as you normally would.
|
||||
|
||||
 **Figure 2.**The composition and skip counter in Layout Inspector.
|
||||
|
||||
Open the **Layout Inspector** window and connect to your app process. In the **Component Tree** , there are two columns that appear next to the layout hierarchy. The first column shows the number of compositions for each node and the second column displays the number of skips for each node. Selecting a composable node shows the dimensions and parameters of the composable, unless it's an inline function, in which case the parameters can't be shown. You can also see similar information in the **Attributes** pane when you select a composable from the **Component Tree** or the **Layout Display**.
|
||||
Open the **Layout Inspector** window and connect to your app process. In the
|
||||
**Component Tree** , there are two columns that appear next to the layout
|
||||
hierarchy. The first column shows the number of compositions for each node and
|
||||
the second column displays the number of skips for each node. Selecting a
|
||||
composable node shows the dimensions and parameters of the composable, unless
|
||||
it's an inline function, in which case the parameters can't be shown. You can
|
||||
also see similar information in the **Attributes** pane when you select a
|
||||
composable from the **Component Tree** or the **Layout Display**.
|
||||
|
||||
Resetting the count can help you understand recompositions or skips during a specific interaction with your app. If you want to reset the count, click **Reset** near the top of the **Component Tree** pane.
|
||||
Resetting the count can help you understand recompositions or skips during a
|
||||
specific interaction with your app. If you want to reset the count, click
|
||||
**Reset** near the top of the **Component Tree** pane.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** If you don't see the new columns in the **Component Tree** pane, you can view them by selecting **Show Recomposition Counts** from the **View Options** menu  describe your UI in an alternative manner that is understandable for [Accessibility](https://developer.android.com/develop/ui/compose/accessibility) services and for the [Testing](https://developer.android.com/develop/ui/compose/testing) framework. You can use the Layout Inspector to inspect semantic information in your Compose layouts.
|
||||
In Compose, [Semantics](https://developer.android.com/develop/ui/compose/accessibility/semantics) describe your UI in an
|
||||
alternative manner that is understandable for
|
||||
[Accessibility](https://developer.android.com/develop/ui/compose/accessibility) services and for the
|
||||
[Testing](https://developer.android.com/develop/ui/compose/testing) framework. You can use the Layout Inspector
|
||||
to inspect semantic information in your Compose layouts.
|
||||
 **Figure 4.** Semantic information displayed using the Layout Inspector.
|
||||
|
||||
When selecting a Compose node, use the **Attributes** pane to check whether it declares semantic information directly, merges semantics from its children, or both. To quickly identify which nodes include semantics, either declared or merged, use select the **View options** drop-down in the **Component Tree** pane and select **Highlight Semantics Layers**. This highlights only the nodes in the tree that include semantics, and you can use your keyboard to quickly navigate between them.
|
||||
When selecting a Compose node, use the **Attributes** pane to check whether it
|
||||
declares semantic information directly, merges semantics from its children, or
|
||||
both. To quickly identify which nodes include semantics, either declared or
|
||||
merged, use select the **View options** drop-down in the **Component Tree** pane
|
||||
and select **Highlight Semantics Layers**. This highlights only the nodes in the
|
||||
tree that include semantics, and you can use your keyboard to quickly navigate
|
||||
between them.
|
||||
|
||||
## Compose UI Check
|
||||
|
||||
To help you build more adaptive and accessible UIs in Jetpack Compose, Android Studio provides a UI Check mode in Compose Preview. This feature is similar to [Accessibility Scanner](https://developer.android.com/guide/topics/ui/accessibility/testing#accessibility-scanner) for views.
|
||||
To help you build more adaptive and accessible UIs in Jetpack Compose, Android
|
||||
Studio provides a UI Check mode in Compose Preview. This feature is similar
|
||||
to [Accessibility Scanner](https://developer.android.com/guide/topics/ui/accessibility/testing#accessibility-scanner)
|
||||
for views.
|
||||
|
||||
When you activate Compose UI check mode on a Compose Preview, Android Studio automatically audits your Compose UI and suggests improvements to make your UI more accessible and adaptive. Android Studio checks that your UI works across different screen sizes. In the **Problems** panel, the tool shows the issues that it detects, such as text stretched on large screens or low color contrast.
|
||||
When you activate Compose UI check mode on a Compose Preview, Android Studio
|
||||
automatically audits your Compose UI and suggests improvements to make your UI
|
||||
more accessible and adaptive. Android Studio checks that your UI works across
|
||||
different screen sizes. In the **Problems** panel, the tool shows the issues
|
||||
that it detects, such as text stretched on large screens or low color contrast.
|
||||
|
||||
To access this feature, click the UI Check icon on Compose Preview:
|
||||
 **Figure 5.** Entry point to UI check mode.
|
||||
|
||||
UI check automatically previews your UI in different configurations and highlights issues found in different configurations. In the **Problems** panel, when you click an issue, you can see the details of the issue, suggested fixes, and the renderings that highlight the area of the issue.
|
||||
UI check automatically previews your UI in different configurations and
|
||||
highlights issues found in different configurations. In the **Problems** panel,
|
||||
when you click an issue, you can see the details of the issue, suggested fixes,
|
||||
and the renderings that highlight the area of the issue.
|
||||
 **Figure 6.** UI check mode in action.
|
||||
|
||||
### Fix with AI
|
||||
|
||||
For issues detected in UI Check mode, you can use the AI agent to propose and apply code fixes. Click the **Fix with AI** button on an issue in the **Problems** panel. The agent analyzes the problem and your code to suggest changes that resolve the accessibility or adaptive issue.
|
||||
For issues detected in UI Check mode, you can use the AI agent to propose and
|
||||
apply code fixes. Click the **Fix with AI** button on an issue in the
|
||||
**Problems** panel. The agent analyzes the problem and your code to suggest
|
||||
changes that resolve the accessibility or adaptive issue.
|
||||
 **Figure 7.** The agent fixes UI issues in UI Check mode.
|
||||
-2
@@ -138,6 +138,4 @@ class MaterialListDetailActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
@@ -9,7 +9,7 @@ description: Provides a structured workflow for migrating an Android XML View to
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-14'
|
||||
keywords:
|
||||
- Jetpack Compose
|
||||
- migration
|
||||
@@ -20,11 +20,16 @@ metadata:
|
||||
- UI development
|
||||
---
|
||||
|
||||
This skill guides through the process of migrating an existing Android XML View to Jetpack Compose. It performs a stable, safe and visually consistent transition by following a structured, 10-step methodology. This skill migrates UI (XML to Jetpack Compose) only.
|
||||
This skill guides through the process of migrating an existing Android XML View
|
||||
to Jetpack Compose. It performs a stable, safe and visually consistent
|
||||
transition by following a structured, 10-step methodology. This skill migrates
|
||||
UI (XML to Jetpack Compose) only.
|
||||
|
||||
## Objective
|
||||
|
||||
To systematically convert a single legacy XML layout into modern, declarative Jetpack Compose UI while maintaining pixel-perfect visual parity and functional integrity.
|
||||
To systematically convert a single legacy XML layout into modern, declarative
|
||||
Jetpack Compose UI while maintaining pixel-perfect visual parity and functional
|
||||
integrity.
|
||||
|
||||
## Summary of the 10-step migration process
|
||||
|
||||
@@ -43,31 +48,61 @@ To systematically convert a single legacy XML layout into modern, declarative Je
|
||||
|
||||
### Step 1: Identify the optimal XML candidate for migration
|
||||
|
||||
If the user has explicitly specified a target XML layout, proceed to Step 2. Otherwise, analyze the codebase to identify the best candidate for migration by following the logic in [references/identify-optimal-xml-candidate.md](references/identify-optimal-xml-candidate.md).
|
||||
If the user has explicitly specified a target XML layout, proceed to Step 2.
|
||||
Otherwise, analyze the codebase to identify the best candidate for migration by
|
||||
following the logic in [references/identify-optimal-xml-candidate.md](references/identify-optimal-xml-candidate.md).
|
||||
|
||||
### Step 2: Analyze the project and layout
|
||||
|
||||
Analyze the identified XML View's structure, hierarchy, and implementation details. Use [references/analysis-of-the-project-and-layout.md](references/analysis-of-the-project-and-layout.md) to guide your technical audit of the layout and surrounding project context.
|
||||
Analyze the identified XML View's structure, hierarchy, and implementation
|
||||
details.
|
||||
Use [references/analysis-of-the-project-and-layout.md](references/analysis-of-the-project-and-layout.md) to
|
||||
guide your technical audit of the layout and surrounding project context.
|
||||
|
||||
### Step 3: Create a plan
|
||||
|
||||
Using the outputs and analysis done in the Step 1 and 2, generate a step-by-step plan for the migration. If you support user interaction, present to the user and ask for approval before proceeding. If user interaction is not supported, proceed to Step 4 following the generated plan.
|
||||
Using the outputs and analysis done in the Step 1 and 2, generate a
|
||||
step-by-step plan for the migration. If you support user interaction, present
|
||||
to the user and ask for approval before proceeding. If user interaction is not
|
||||
supported, proceed to Step 4 following the generated plan.
|
||||
|
||||
### Step 4: Capture the XML View UI
|
||||
|
||||
**IF** you support user interaction, ask the user to upload a screenshot of the XML View UI or provide an absolute path to a file. Use this image as a visual reference for the layout migration in Step 7. **ELSE IF** you are able to run an Android emulator, locate an existing screenshot test for the XML candidate. If none exists, create one using the existing project testing framework. If no framework exists, use **UI Automator** or **Espresso** to create a screenshot test with minimum required setup. Run the test and take a baseline screenshot of the XML UI. **ELSE** proceed to Step 5.
|
||||
**IF** you support user interaction, ask the user to upload a screenshot of the
|
||||
XML View UI or provide an absolute path to a file. Use this image as a visual
|
||||
reference for the layout migration in Step 7.
|
||||
**ELSE IF** you are able to run an Android emulator, locate an existing
|
||||
screenshot test for the XML candidate. If none exists, create one using the
|
||||
existing project testing framework. If no framework exists,
|
||||
use **UI Automator** or **Espresso** to create a screenshot test with minimum
|
||||
required setup. Run the test and take a baseline screenshot of the XML UI.
|
||||
**ELSE** proceed to Step 5.
|
||||
|
||||
### Step 5: Set up Compose dependencies and compiler
|
||||
|
||||
Check `build.gradle` or `libs.versions.toml` for Compose dependencies and compiler setup. If missing, use [Setup Compose Dependencies and Compiler](references/android/develop/ui/compose/setup-compose-dependencies-and-compiler.md). Run a sync to ensure dependencies resolve without errors.
|
||||
Check `build.gradle` or `libs.versions.toml` for Compose dependencies and
|
||||
compiler setup. If missing, use
|
||||
[Setup Compose Dependencies and Compiler](references/android/develop/ui/compose/setup-compose-dependencies-and-compiler.md).
|
||||
Run a sync to ensure dependencies resolve without errors.
|
||||
|
||||
### Step 6: Set up Compose theming
|
||||
|
||||
If the project already has Compose theming set up, proceed to Step 7. If Compose theming is missing, initialize it. For Material-based projects, follow [Material 3 migration guidelines](references/android/develop/ui/compose/designsystems/migrate-xml-theme-to-compose.md). For custom design systems, apply expert judgment to migrate XML theming and match existing styles. **Constraints:** Do not migrate the entire theme. Implement only the minimum theming required for the specific XML candidate. Maintain original XML themes for interoperability. Maintain existing project code conventions, patterns, names and values.
|
||||
If the project already has Compose theming set up, proceed to Step 7. If Compose
|
||||
theming is missing, initialize it. For Material-based projects, follow
|
||||
[Material 3 migration guidelines](references/android/develop/ui/compose/designsystems/migrate-xml-theme-to-compose.md).
|
||||
For custom design systems, apply expert judgment to migrate XML theming and
|
||||
match existing styles.
|
||||
**Constraints:** Do not migrate the entire theme. Implement only the minimum
|
||||
theming required for the specific XML candidate. Maintain original XML themes
|
||||
for interoperability. Maintain existing project code conventions, patterns,
|
||||
names and values.
|
||||
|
||||
### Step 7: Migrate the XML View to Compose
|
||||
|
||||
Convert the XML candidate to Jetpack Compose code, referencing [references/xml-layout-migration.md](references/xml-layout-migration.md) and the image from Step 4. You must include a **Compose Preview** for the newly created composable to facilitate visual verification.
|
||||
Convert the XML candidate to Jetpack Compose code, referencing
|
||||
[references/xml-layout-migration.md](references/xml-layout-migration.md) and the image from Step 4.
|
||||
You must include a **Compose Preview** for the newly created composable to
|
||||
facilitate visual verification.
|
||||
|
||||
### Step 8: Replace usages
|
||||
|
||||
@@ -78,8 +113,12 @@ Replace the usages of the migrated XML layout to use the new Compose component.
|
||||
|
||||
### Step 9: Validate the migration
|
||||
|
||||
Compare the baseline screenshot image from Step 4 with the rendered Compose Preview of the new composable. Ignore string content; focus on layout and styling. Iterate on the Compose code until visual parity is achieved. Once verified, write a Compose UI test for the new composable.
|
||||
Compare the baseline screenshot image from Step 4 with the rendered Compose
|
||||
Preview of the new composable. Ignore string content; focus on layout and
|
||||
styling. Iterate on the Compose code until visual parity is achieved. Once
|
||||
verified, write a Compose UI test for the new composable.
|
||||
|
||||
### Step 10: XML code removal
|
||||
|
||||
Delete the migrated XML file and its associated legacy tests. **Caution:** Only remove code and resources that are not referenced by other parts of the project.
|
||||
Delete the migrated XML file and its associated legacy tests. **Caution:** Only
|
||||
remove code and resources that are not referenced by other parts of the project.
|
||||
|
||||
+24
-5
@@ -1,22 +1,41 @@
|
||||
## 1. Project health \& build validation
|
||||
|
||||
Before performing any analysis, you must confirm the project is in a functional state. \* **Integrity check:** Verify the project syncs (Gradle) and builds successfully. \* **Error resolution:** If there are pre-existing build errors or sync failures, you must report these immediately and attempt to fix. **Do not proceed** with migration until a stable baseline is established.
|
||||
Before performing any analysis, you must confirm the project is in a functional state.
|
||||
\* **Integrity check:** Verify the project syncs (Gradle) and builds successfully.
|
||||
\* **Error resolution:** If there are pre-existing build errors or sync failures, you must report these immediately and attempt to fix. **Do not proceed** with migration until a stable baseline is established.
|
||||
|
||||
## 2. Compose pattern \& consistency analysis
|
||||
|
||||
If Jetpack Compose is already present, you must align with the established implementation style. \* **Pattern identification:** Scan the codebase for `@Composable` functions. Identify the project's "Best Practices" regarding state hoisting, composable construction and naming conventions, and file organization. \* **Theming review:** Determine how `MaterialTheme` or custom theme systems are implemented. \* Identify if the project uses a custom design system theme. \* Map how attributes, styles, and other theme components are accessed in Compose.
|
||||
If Jetpack Compose is already present, you must align with the established implementation style.
|
||||
\* **Pattern identification:** Scan the codebase for `@Composable` functions. Identify the project's "Best Practices" regarding state hoisting, composable construction and naming conventions, and file organization.
|
||||
\* **Theming review:** Determine how `MaterialTheme` or custom theme systems are implemented.
|
||||
\* Identify if the project uses a custom design system theme.
|
||||
\* Map how attributes, styles, and other theme components are accessed in Compose.
|
||||
|
||||
## 3. Design system \& infrastructure audit
|
||||
|
||||
Understand the design system classification (e.g. Material 2, Material 3, or custom design system). \* **Resource mapping:** Locate central XML definitions: \* `colors.xml` (Light/Dark variants) \* `dimens.xml` \* `styles.xml` / `themes.xml` \* **Hybrid analysis:** Determine if the project is **XML-only** , **Compose-only** , or **Hybrid** . \* **Reuse constraint:** If a Compose theming layer (e.g., `AppTheme.kt`) already exists, **DO NOT** generate a new one. You must reuse the existing infrastructure and contribute to it by following its existing implementation pattern.
|
||||
Understand the design system classification (e.g. Material 2, Material 3, or custom design system).
|
||||
\* **Resource mapping:** Locate central XML definitions:
|
||||
\* `colors.xml` (Light/Dark variants)
|
||||
\* `dimens.xml`
|
||||
\* `styles.xml` / `themes.xml`
|
||||
\* **Hybrid analysis:** Determine if the project is **XML-only** , **Compose-only** , or **Hybrid** .
|
||||
\* **Reuse constraint:** If a Compose theming layer (e.g., `AppTheme.kt`) already exists, **DO NOT** generate a new one. You must reuse the existing infrastructure and contribute to it by following its existing implementation pattern.
|
||||
|
||||
## 4. Candidate layout decomposition
|
||||
|
||||
Analyze the specific XML layout targeted for migration. You must extract and document the following requirements for the new composable: \* **Inputs:** UI State objects, primitive parameters, and click listeners. \* **Styling:** Specific color constants, typography styles, and shape definitions referenced in the XML. \* **Resources:** Identifying string resources, drawables, and dimensions. \* **Layout logic:** Modifiers required to replicate the XML constraints (padding, alignment, weight).
|
||||
Analyze the specific XML layout targeted for migration. You must extract and document the following requirements for the new composable:
|
||||
\* **Inputs:** UI State objects, primitive parameters, and click listeners.
|
||||
\* **Styling:** Specific color constants, typography styles, and shape definitions referenced in the XML.
|
||||
\* **Resources:** Identifying string resources, drawables, and dimensions.
|
||||
\* **Layout logic:** Modifiers required to replicate the XML constraints (padding, alignment, weight).
|
||||
|
||||
## 5. Architectural \& non-UI analysis
|
||||
|
||||
Understand the environment in which the UI resides to ensure proper integration. \* **State management:** Identify the usage of `ViewModel`, `Flow`, or `LiveData`. \* **Dependency Injection:** Check for Hilt, Koin, or manual DI to understand how dependencies are provided to the UI layer. \* **Testing \& architecture:** Note the architectural pattern (MVI, MVVM, or custom architecture setup.) and existing UI testing frameworks to ensure the migrated code remains testable. Unless the user explicitly requests, **DO NOT** make any changes to any non-UI code that aren't strictly required for the migration of the XML View.
|
||||
Understand the environment in which the UI resides to ensure proper integration.
|
||||
\* **State management:** Identify the usage of `ViewModel`, `Flow`, or `LiveData`.
|
||||
\* **Dependency Injection:** Check for Hilt, Koin, or manual DI to understand how dependencies are provided to the UI layer.
|
||||
\* **Testing \& architecture:** Note the architectural pattern (MVI, MVVM, or custom architecture setup.) and existing UI testing frameworks to ensure the migrated code remains testable. Unless the user explicitly requests, **DO NOT** make any changes to any non-UI code that aren't strictly required for the migration of the XML View.
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
|
||||
+37
-13
@@ -1,8 +1,14 @@
|
||||
When you introduce Compose in an existing app, you need to migrate your Material XML themes to use `MaterialTheme` for Compose components. This means your app's theming will have two sources of truth: the View-based theme and the Compose theme. Any changes to your styling need to be made in multiple places. Once your app is fully migrated to Compose, remove your XML theming.
|
||||
When you introduce Compose in an existing app, you need to migrate your Material
|
||||
XML themes to use `MaterialTheme` for Compose components. This means your app's
|
||||
theming will have two sources of truth: the View-based theme and the Compose
|
||||
theme. Any changes to your styling need to be made in multiple places. Once
|
||||
your app is fully migrated to Compose, remove your XML theming.
|
||||
|
||||
You can use the [Material Theme Builder](https://m3.material.io/theme-builder) tool for migrating colors.
|
||||
You can use the [Material Theme Builder](https://m3.material.io/theme-builder)
|
||||
tool for migrating colors.
|
||||
|
||||
When you start the migration from XML to Compose, migrate the theming to Material 3 Compose theming.
|
||||
When you start the migration from XML to Compose, migrate the theming to
|
||||
Material 3 Compose theming.
|
||||
|
||||
## Glossary
|
||||
|
||||
@@ -23,19 +29,26 @@ Before migrating, be aware of the following limitations:
|
||||
|
||||
## Step 1: Evaluate the design system
|
||||
|
||||
Identify which design system is used in the XML View project. Analyze the migration path and necessary steps to migrate the existing design system to Material 3 in Compose.
|
||||
Identify which design system is used in the XML View project.
|
||||
Analyze the migration path and necessary steps to migrate the existing design
|
||||
system to Material 3 in Compose.
|
||||
|
||||
## Step 2: Identify theme source files
|
||||
|
||||
In XML you write `?attr/colorPrimary`. In Compose, you access theme values with `MaterialTheme.*`:
|
||||
In XML you write `?attr/colorPrimary`. In Compose, you access theme values
|
||||
with `MaterialTheme.*`:
|
||||
|
||||
Identify and locate all XML resources and files necessary for theming: light and dark color schemes and qualifiers, themes, shapes, dimensions, typography, styles and other relevant files.
|
||||
Identify and locate all XML resources and files necessary for theming:
|
||||
light and dark color schemes and qualifiers, themes, shapes, dimensions,
|
||||
typography, styles and other relevant files.
|
||||
|
||||
Resources such as strings can be reused as is and don't need to be migrated.
|
||||
|
||||
## Step 3: Migrate colors
|
||||
|
||||
**Key principle:** XML uses named hex colors. Material 3 uses *semantic roles* (e.g., `primary`, `onPrimary`, `surface`). Stop naming colors by their hex; name them by their role.
|
||||
**Key principle:** XML uses named hex colors.
|
||||
Material 3 uses *semantic roles* (e.g., `primary`, `onPrimary`, `surface`).
|
||||
Stop naming colors by their hex; name them by their role.
|
||||
|
||||
Examples:
|
||||
|
||||
@@ -56,7 +69,8 @@ Examples:
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
Migrate the dark and light color schemes from XML to their equivalents in Material 3 Compose.
|
||||
Migrate the dark and light color schemes from XML to their equivalents in
|
||||
Material 3 Compose.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Material 3 naming differs from Material 2 color naming.
|
||||
@@ -103,14 +117,20 @@ XML styles (styles.xml) system defines styles and appearance of:
|
||||
3. Themes and overlays
|
||||
4. Shapes
|
||||
|
||||
XML Views and components combine multiple attributes to create a style. They set their styles from styles.xml in two different ways:
|
||||
XML Views and components combine multiple attributes to create a style.
|
||||
They set their styles from styles.xml in two different ways:
|
||||
|
||||
1. Setting "style="@style/..." directly and explicitly in the XML View
|
||||
2. Setting the style indirectly and implicitly for a component as part of a larger Theme (theme.xml)
|
||||
|
||||
Styles have no **direct** equivalent in Compose - instead styles are passed as: parameters or modifiers to composables, using the [new, experimental Styles API](https://developer.android.com/develop/ui/compose/styles) defined in the AppTheme, or by creating layered, reusable composable variations with the defined style.
|
||||
Styles have no **direct** equivalent in Compose - instead styles are passed as:
|
||||
parameters or modifiers to composables, using the
|
||||
[new, experimental Styles API](https://developer.android.com/develop/ui/compose/styles) defined in the AppTheme, or by creating
|
||||
layered, reusable composable variations with the defined style.
|
||||
|
||||
Provide separate @Composable functions named according to the style and the base component, to signify the difference in styling and use cases for those components.
|
||||
Provide separate @Composable functions named according to the style and the
|
||||
base component, to signify the difference in styling and use cases for those
|
||||
components.
|
||||
|
||||
- **Pattern:** If an XML element uses a custom style (e.g., `style="@style/MyPrimaryButton"`), don't try to replicate the style inline. Instead, suggest creating a specific composable.
|
||||
- **Example:**
|
||||
@@ -142,6 +162,10 @@ Provide separate @Composable functions named according to the style and the base
|
||||
|
||||
## Step 6: Validate the theme migration
|
||||
|
||||
Always use the existing theme values from the original XML theme as the source of truth for the new Material Theme in Compose. Never invent new theme values during migration, to maintain brand consistency and avoid visual regressions.
|
||||
Always use the existing theme values from the original XML theme as the source
|
||||
of truth for the new Material Theme in Compose.
|
||||
Never invent new theme values during migration, to maintain brand consistency
|
||||
and avoid visual regressions.
|
||||
|
||||
Verify all new Compose theme values match the existing XML values. Don't hardcode any migrated values.
|
||||
Verify all new Compose theme values match the existing XML values.
|
||||
Don't hardcode any migrated values.
|
||||
+49
-30
@@ -3,9 +3,10 @@
|
||||
|
||||
You can add Compose-based UI into an existing app that uses a View-based design.
|
||||
|
||||
To create a new, entirely Compose-based screen, have your activity call the `setContent()` method, and pass whatever composable functions you like.
|
||||
To create a new, entirely Compose-based screen, have your
|
||||
activity call the `setContent()` method, and pass whatever composable functions
|
||||
you like.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class ExampleActivity : ComponentActivity() {
|
||||
@@ -24,7 +25,6 @@ class ExampleActivity : ComponentActivity() {
|
||||
fun Greeting(name: String) {
|
||||
Text(text = "Hello $name!")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -32,17 +32,30 @@ fun Greeting(name: String) {
|
||||
This code looks just like what you'd find in a Compose-only app.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Caution:** To use the `ComponentActivity.setContent` method, add the `androidx.activity:activity-compose:$latestVersion` dependency to your `build.gradle` file.
|
||||
> **Caution:** To use the `ComponentActivity.setContent`
|
||||
> method, add the `androidx.activity:activity-compose:$latestVersion`
|
||||
> dependency to your `build.gradle` file.
|
||||
>
|
||||
> See the [Activity releases page](https://developer.android.com/jetpack/androidx/releases/activity) to find out the latest version.
|
||||
> See the [Activity releases page](https://developer.android.com/jetpack/androidx/releases/activity)
|
||||
> to find out the latest version.
|
||||
|
||||
## `ViewCompositionStrategy` for `ComposeView`
|
||||
|
||||
[`ViewCompositionStrategy`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ViewCompositionStrategy) defines when the Composition should be disposed. The default, [`ViewCompositionStrategy.Default`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ViewCompositionStrategy#Default()), disposes the Composition when the underlying [`ComposeView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ComposeView) detaches from the window, unless it is part of a pooling container such as a `RecyclerView`. In a single-Activity Compose-only app, this default behavior is what you would want, however, if you are incrementally adding Compose in your codebase, this behavior may cause state loss in some scenarios.
|
||||
[`ViewCompositionStrategy`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ViewCompositionStrategy)
|
||||
defines when the Composition should be disposed. The default,
|
||||
[`ViewCompositionStrategy.Default`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ViewCompositionStrategy#Default()),
|
||||
disposes the Composition when the underlying
|
||||
[`ComposeView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ComposeView)
|
||||
detaches from the window, unless it is part of a pooling container such as a
|
||||
`RecyclerView`. In a single-Activity Compose-only app, this default behavior is
|
||||
what you would want, however, if you are incrementally adding Compose in your
|
||||
codebase, this behavior may cause state loss in some scenarios.
|
||||
|
||||
To change the `ViewCompositionStrategy`, call the [`setViewCompositionStrategy()`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/AbstractComposeView#setViewCompositionStrategy(androidx.compose.ui.platform.ViewCompositionStrategy)) method and provide a different strategy.
|
||||
To change the `ViewCompositionStrategy`, call the [`setViewCompositionStrategy()`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/AbstractComposeView#setViewCompositionStrategy(androidx.compose.ui.platform.ViewCompositionStrategy))
|
||||
method and provide a different strategy.
|
||||
|
||||
The table below summarizes the different scenarios you can use `ViewCompositionStrategy` in:
|
||||
The table below summarizes the different scenarios you can use
|
||||
`ViewCompositionStrategy` in:
|
||||
|
||||
| `ViewCompositionStrategy` | Description and Interop Scenario |
|
||||
|---|---|
|
||||
@@ -56,7 +69,11 @@ The table below summarizes the different scenarios you can use `ViewCompositionS
|
||||
> [!NOTE]
|
||||
> **Note:** For hybrid apps with Views and Compose, that use Fragments, use `ComposeView` to wrap composables content and add to a Fragment during migration. For Compose-only apps, do not use Fragments and instead use the recommended Compose-only architecture with a single Activity and latest navigation libraries, like Navigation 3.
|
||||
|
||||
If you want to incorporate Compose UI content in a fragment or an existing View layout, use [`ComposeView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ComposeView) and call its [`setContent()`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ComposeView#setContent(kotlin.Function0)) method. `ComposeView` is an Android [`View`](https://developer.android.com/reference/android/view/View).
|
||||
If you want to incorporate Compose UI content in a fragment or an existing View
|
||||
layout, use [`ComposeView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ComposeView)
|
||||
and call its
|
||||
[`setContent()`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ComposeView#setContent(kotlin.Function0))
|
||||
method. `ComposeView` is an Android [`View`](https://developer.android.com/reference/android/view/View).
|
||||
|
||||
You can put the `ComposeView` in your XML layout just like any other `View`:
|
||||
|
||||
@@ -76,12 +93,13 @@ You can put the `ComposeView` in your XML layout just like any other `View`:
|
||||
android:layout_width="match_parent"
|
||||
android:layout_height="match_parent" />
|
||||
</LinearLayout>
|
||||
|
||||
```
|
||||
|
||||
In the Kotlin source code, inflate the layout from the [layout resource](https://developer.android.com/guide/topics/resources/layout-resource) defined in XML. Then get the `ComposeView` using the XML ID, set a Composition strategy that works best for the host `View`, and call `setContent()` to use Compose.
|
||||
In the Kotlin source code, inflate the layout from the [layout
|
||||
resource](https://developer.android.com/guide/topics/resources/layout-resource) defined in XML. Then get the
|
||||
`ComposeView` using the XML ID, set a Composition strategy that works best for
|
||||
the host `View`, and call `setContent()` to use Compose.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class ExampleFragmentXml : Fragment() {
|
||||
@@ -107,14 +125,13 @@ class ExampleFragmentXml : Fragment() {
|
||||
return view
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Alternatively, you can also use view binding to obtain references to the `ComposeView` by referencing the generated binding class for your XML layout file:
|
||||
Alternatively, you can also use view binding to obtain references to the
|
||||
`ComposeView` by referencing the generated binding class for your XML layout file:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class ExampleFragment : Fragment() {
|
||||
@@ -150,18 +167,20 @@ class ExampleFragment : Fragment() {
|
||||
_binding = null
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||

|
||||
|
||||
**Figure 1.** This shows the output of the code that adds Compose elements in a View UI hierarchy. The "Hello Android!" text is displayed by a `TextView` widget. The "Hello Compose!" text is displayed by a Compose text element.
|
||||
**Figure 1.** This shows the output of the code that adds Compose elements in a
|
||||
View UI hierarchy. The "Hello Android!" text is displayed by a
|
||||
`TextView` widget. The "Hello Compose!" text is displayed by a
|
||||
Compose text element.
|
||||
|
||||
You can also include a `ComposeView` directly in a fragment if your full screen is built with Compose, which lets you avoid using an XML layout file entirely.
|
||||
You can also include a `ComposeView` directly in a fragment if your full screen
|
||||
is built with Compose, which lets you avoid using an XML layout file entirely.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class ExampleFragmentNoXml : Fragment() {
|
||||
@@ -184,16 +203,15 @@ class ExampleFragmentNoXml : Fragment() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Multiple `ComposeView` instances in the same layout
|
||||
|
||||
If there are multiple `ComposeView` elements in the same layout, each one must have a unique ID for `savedInstanceState` to work.
|
||||
If there are multiple `ComposeView` elements in the same layout, each one must
|
||||
have a unique ID for `savedInstanceState` to work.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class ExampleFragmentMultipleComposeView : Fragment() {
|
||||
@@ -224,7 +242,6 @@ class ExampleFragmentMultipleComposeView : Fragment() {
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -236,16 +253,18 @@ The `ComposeView` IDs are defined in the `res/values/ids.xml` file:
|
||||
<item name="compose_view_x" type="id" />
|
||||
<item name="compose_view_y" type="id" />
|
||||
</resources>
|
||||
|
||||
```
|
||||
|
||||
## Preview composables in Layout Editor
|
||||
|
||||
You can also preview composables within the Layout Editor for your XML layout containing a `ComposeView`. Doing so lets you see how your composables look within a mixed Views and Compose layout.
|
||||
You can also preview composables within the Layout Editor for your XML layout
|
||||
containing a `ComposeView`. Doing so lets you see how your composables look
|
||||
within a mixed Views and Compose layout.
|
||||
|
||||
Say you want to display the following composable in the Layout Editor. Note that composables annotated with `@Preview` are good candidates to preview in the Layout Editor.
|
||||
Say you want to display the following composable in the Layout Editor. Note
|
||||
that composables annotated with `@Preview` are good candidates to preview in the
|
||||
Layout Editor.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Preview
|
||||
@@ -253,12 +272,13 @@ Say you want to display the following composable in the Layout Editor. Note that
|
||||
fun GreetingPreview() {
|
||||
Greeting(name = "Android")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
To display this composable, use the `tools:composableName` tools attribute and set its value to the fully qualified name of the composable to preview in the layout.
|
||||
To display this composable, use the `tools:composableName` tools attribute and
|
||||
set its value to the fully qualified name of the composable to preview in the
|
||||
layout.
|
||||
|
||||
```xml
|
||||
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
@@ -274,7 +294,6 @@ To display this composable, use the `tools:composableName` tools attribute and s
|
||||
android:layout_width="match_parent"/>
|
||||
|
||||
</LinearLayout>
|
||||
|
||||
```
|
||||
|
||||

|
||||
+64
-28
@@ -1,13 +1,22 @@
|
||||
You can include an Android View hierarchy in a Compose UI. This approach is particularly useful if you want to use UI elements that are not yet available in Compose, like [`AdView`](https://developers.google.com/android/reference/com/google/android/gms/ads/AdView). This approach also lets you reuse custom views you may have designed.
|
||||
You can include an Android View hierarchy in a Compose UI. This approach is
|
||||
particularly useful if you want to use UI elements that are not yet available in
|
||||
Compose, like
|
||||
[`AdView`](https://developers.google.com/android/reference/com/google/android/gms/ads/AdView).
|
||||
This approach also lets you reuse custom views you may have designed.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Use `AndroidView` as a wrapper only for missing SDK components without Compose support. Rewrite your custom Views in Compose wherever possible, starting the migration with the simplest custom Views and scaling to more complex ones.
|
||||
|
||||
<br />
|
||||
|
||||
To include a view element or hierarchy, use the [`AndroidView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/viewinterop/AndroidView.composable#AndroidView(kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1)) composable. `AndroidView` is passed a lambda that returns a [`View`](https://developer.android.com/reference/android/view/View). `AndroidView` also provides an `update` callback that is called when the view is inflated. The `AndroidView` recomposes whenever a `State` read within the callback changes. `AndroidView`, like many other built-in composables, takes a `Modifier` parameter that can be used, for example, to set its position in the parent composable.
|
||||
To include a view element or hierarchy, use the [`AndroidView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/viewinterop/AndroidView.composable#AndroidView(kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1))
|
||||
composable. `AndroidView` is passed a lambda that returns a
|
||||
[`View`](https://developer.android.com/reference/android/view/View). `AndroidView` also provides an `update`
|
||||
callback that is called when the view is inflated. The `AndroidView` recomposes
|
||||
whenever a `State` read within the callback changes. `AndroidView`, like many
|
||||
other built-in composables, takes a `Modifier` parameter that can be used, for
|
||||
example, to set its position in the parent composable.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -45,8 +54,6 @@ fun ContentExample() {
|
||||
CustomView()
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -56,12 +63,14 @@ fun ContentExample() {
|
||||
|
||||
## `AndroidView` with view binding
|
||||
|
||||
To embed an XML layout, use the [`AndroidViewBinding`](https://developer.android.com/reference/kotlin/androidx/compose/ui/viewinterop/package-summary#AndroidViewBinding(kotlin.Function3,%20androidx.compose.ui.Modifier,%20kotlin.Function1)) API, which is provided by the `androidx.compose.ui:ui-viewbinding` library. To do this, your project must enable [view binding](https://developer.android.com/topic/libraries/view-binding#setup).
|
||||
To embed an XML layout, use the
|
||||
[`AndroidViewBinding`](https://developer.android.com/reference/kotlin/androidx/compose/ui/viewinterop/package-summary#AndroidViewBinding(kotlin.Function3,%20androidx.compose.ui.Modifier,%20kotlin.Function1))
|
||||
API, which is provided by the `androidx.compose.ui:ui-viewbinding` library. To
|
||||
do this, your project must enable [view binding](https://developer.android.com/topic/libraries/view-binding#setup).
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** For Compose-only apps, don't use `AndroidViewBinding` to inflate full screen-level XML layouts, and instead use it only for smaller, legacy XML layouts during the incremental migration process.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -70,21 +79,23 @@ fun AndroidViewBindingExample() {
|
||||
exampleView.setBackgroundColor(Color.GRAY)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## `AndroidView` in Lazy lists
|
||||
|
||||
If you are using an `AndroidView` in a Lazy list (`LazyColumn`, `LazyRow`, `Pager`, etc.), consider using the [`AndroidView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/viewinterop/package-summary#AndroidView(kotlin.Function1,kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1,kotlin.Function1)) overload introduced in version 1.4.0-rc01. This overload allows Compose to reuse the underlying `View` instance when the containing composition is reused as is the case for Lazy lists.
|
||||
If you are using an `AndroidView` in a Lazy list (`LazyColumn`, `LazyRow`,
|
||||
`Pager`, etc.), consider using the [`AndroidView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/viewinterop/package-summary#AndroidView(kotlin.Function1,kotlin.Function1,androidx.compose.ui.Modifier,kotlin.Function1,kotlin.Function1))
|
||||
overload introduced in version 1.4.0-rc01. This overload allows Compose to reuse
|
||||
the underlying `View` instance when the containing composition is reused as is
|
||||
the case for Lazy lists.
|
||||
|
||||
This overload of `AndroidView` adds 2 additional parameters:
|
||||
|
||||
- `onReset` - A callback invoked to signal that the `View` is about to be reused. This must be non-null to enable View reuse.
|
||||
- `onRelease` (optional) - A callback invoked to signal that the `View` has exited the composition and will not be reused again.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -106,50 +117,72 @@ fun AndroidViewInLazyList() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Fragments in Compose (Transitionary Step)
|
||||
|
||||
Use the `AndroidFragment` composable to add a `Fragment` in Compose. `AndroidFragment` has fragment-specific handling such as removing the fragment when the composable leaves the composition.
|
||||
Use the `AndroidFragment` composable to add a `Fragment` in Compose.
|
||||
`AndroidFragment` has fragment-specific handling such as removing the
|
||||
fragment when the composable leaves the composition.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Wrap existing Fragments in Compose only during incremental migration. For Compose-only apps, do not use Fragments and instead use the recommended Compose-only architecture with a single Activity and latest navigation libraries, like Navigation 3.
|
||||
|
||||
To include a fragment, use the [`AndroidFragment`](https://developer.android.com/reference/kotlin/androidx/fragment/compose/package-summary#AndroidFragment) composable. You pass a `Fragment` class to `AndroidFragment`, which then adds an instance of that class directly into the composition. `AndroidFragment` also provides a `fragmentState` object to create the `AndroidFragment` with a given state, `arguments` to pass into the new fragment, and an `onUpdate` callback that provides the fragment from the composition. Like many other built-in composables, `AndroidFragment` accepts a `Modifier` parameter that you can use, for example, to set its position in the parent composable.
|
||||
To include a fragment, use the [`AndroidFragment`](https://developer.android.com/reference/kotlin/androidx/fragment/compose/package-summary#AndroidFragment)
|
||||
composable. You pass a `Fragment` class to `AndroidFragment`, which then adds
|
||||
an instance of that class directly into the composition. `AndroidFragment` also
|
||||
provides a `fragmentState` object to create the `AndroidFragment` with a given
|
||||
state, `arguments` to pass into the new fragment, and an `onUpdate` callback
|
||||
that provides the fragment from the composition. Like many
|
||||
other built-in composables, `AndroidFragment` accepts a `Modifier` parameter
|
||||
that you can use, for
|
||||
example, to set its position in the parent composable.
|
||||
|
||||
Call `AndroidFragment` in Compose as follows:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
fun FragmentInComposeExample() {
|
||||
AndroidFragment<MyFragment>()
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Calling the Android framework from Compose
|
||||
|
||||
Compose operates within the Android framework classes. For example, it's hosted on Android View classes, like `Activity` or `Fragment`, and might use Android framework classes like the `Context`, system resources, `Service`, or `BroadcastReceiver`.
|
||||
Compose operates within the Android framework classes. For example, it's hosted
|
||||
on Android View classes, like `Activity` or `Fragment`, and might use Android
|
||||
framework classes like the `Context`, system resources,
|
||||
`Service`, or `BroadcastReceiver`.
|
||||
|
||||
To learn more about system resources, see [Resources in Compose](https://developer.android.com/develop/ui/compose/resources).
|
||||
|
||||
### Composition Locals
|
||||
|
||||
[`CompositionLocal`](https://developer.android.com/reference/kotlin/androidx/compose/runtime/CompositionLocal) classes allow passing data implicitly through composable functions. They're usually provided with a value in a certain node of the UI tree. That value can be used by its composable descendants without declaring the `CompositionLocal` as a parameter in the composable function.
|
||||
[`CompositionLocal`](https://developer.android.com/reference/kotlin/androidx/compose/runtime/CompositionLocal)
|
||||
classes allow passing data implicitly through composable functions. They're
|
||||
usually provided with a value in a certain node of the UI tree. That value can
|
||||
be used by its composable descendants without declaring the `CompositionLocal`
|
||||
as a parameter in the composable function.
|
||||
|
||||
`CompositionLocal` is used to propagate values for Android framework types in Compose such as `Context`, `Configuration` or the `View` in which the Compose code is hosted with the corresponding [`LocalContext`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalContext()), [`LocalConfiguration`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalConfiguration()), or [`LocalView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalView()). Note that `CompositionLocal` classes are prefixed with `Local` for better discoverability with auto-complete in the IDE.
|
||||
`CompositionLocal` is used to propagate values for Android framework types in
|
||||
Compose such as `Context`, `Configuration` or the `View` in which the Compose
|
||||
code is hosted with the corresponding
|
||||
[`LocalContext`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalContext()),
|
||||
[`LocalConfiguration`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalConfiguration()),
|
||||
or
|
||||
[`LocalView`](https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary#LocalView()).
|
||||
Note that `CompositionLocal` classes are prefixed with `Local` for better
|
||||
discoverability with auto-complete in the IDE.
|
||||
|
||||
Access the current value of a `CompositionLocal` by using its `current` property. For example, the code below shows a toast message by providing `LocalContext.current` into the `Toast.makeToast` method.
|
||||
Access the current value of a `CompositionLocal` by using its `current`
|
||||
property. For example, the code below shows a toast message by providing
|
||||
`LocalContext.current` into the `Toast.makeToast` method.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -161,16 +194,18 @@ fun ToastGreetingButton(greeting: String) {
|
||||
Text("Greet")
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Broadcast receivers
|
||||
|
||||
To showcase `CompositionLocal` and [side effects](https://developer.android.com/develop/ui/compose/side-effects), if a [`BroadcastReceiver`](https://developer.android.com/guide/components/broadcasts) needs to be registered from a composable function, use of `LocalContext` to use the current context, and `rememberUpdatedState` and `DisposableEffect` side effects.
|
||||
To showcase `CompositionLocal` and [side
|
||||
effects](https://developer.android.com/develop/ui/compose/side-effects), if a
|
||||
[`BroadcastReceiver`](https://developer.android.com/guide/components/broadcasts) needs to be registered from
|
||||
a composable function, use of `LocalContext` to use the current context, and
|
||||
`rememberUpdatedState` and `DisposableEffect` side effects.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -212,16 +247,18 @@ fun HomeScreen() {
|
||||
|
||||
/* Rest of the HomeScreen */
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Other interactions
|
||||
|
||||
If there isn't a utility defined for the interaction you need, the best practice is to follow the general Compose guideline, *data flows down, events flow up* (discussed at more length in [Thinking in Compose](https://developer.android.com/develop/ui/compose/mental-model)). For example, this composable launches a different activity:
|
||||
If there isn't a utility defined for the interaction you need, the best practice
|
||||
is to follow the general Compose guideline,
|
||||
*data flows down, events flow up* (discussed at more length in [Thinking
|
||||
in Compose](https://developer.android.com/develop/ui/compose/mental-model)). For example, this composable
|
||||
launches a different activity:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
class OtherInteractionsActivity : ComponentActivity() {
|
||||
@@ -244,7 +281,6 @@ fun ExampleComposable(data: DataExample, onButtonClick: () -> Unit) {
|
||||
Text(data.title)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
+31
-14
@@ -1,7 +1,9 @@
|
||||
For Gradle, use the Compose Compiler Gradle plugin to set up and configure Compose.
|
||||
For Gradle, use the Compose Compiler Gradle plugin to set up and configure
|
||||
Compose.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The Compose Compiler Gradle Plugin is only available from Kotlin 2.0+. For migration instructions, see ["Jetpack Compose compiler moving to the Kotlin repository"](https://android-developers.googleblog.com/2024/04/jetpack-compose-compiler-moving-to-kotlin-repository.html).
|
||||
> **Note:** The Compose Compiler Gradle Plugin is only available from Kotlin 2.0+. For migration instructions, see ["Jetpack Compose compiler moving to the Kotlin
|
||||
> repository"](https://android-developers.googleblog.com/2024/04/jetpack-compose-compiler-moving-to-kotlin-repository.html).
|
||||
|
||||
### Set up with Gradle version catalogs
|
||||
|
||||
@@ -19,7 +21,8 @@ Set up the Compose Compiler Gradle plugin:
|
||||
// Add this line
|
||||
compose-compiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }
|
||||
|
||||
3. In the project's root `build.gradle.kts` file, add the following to the `plugins` section.
|
||||
3. In the project's root `build.gradle.kts` file, add the following to the
|
||||
`plugins` section.
|
||||
|
||||
plugins {
|
||||
// Existing plugins
|
||||
@@ -33,11 +36,14 @@ Set up the Compose Compiler Gradle plugin:
|
||||
alias(libs.plugins.compose.compiler)
|
||||
}
|
||||
|
||||
The project should now build and compile if it was using the default set up. If it had configured custom options on the Compose compiler, follow the next section.
|
||||
The project should now build and compile if it was using the default set up. If
|
||||
it had configured custom options on the Compose compiler, follow the next
|
||||
section.
|
||||
|
||||
### Set up the Compose Compiler without Gradle version catalogs
|
||||
|
||||
Add the plugin to `build.gradle.kts` files associated with modules where Compose is used:
|
||||
Add the plugin to `build.gradle.kts` files associated with modules where Compose
|
||||
is used:
|
||||
|
||||
plugins {
|
||||
id("org.jetbrains.kotlin.plugin.compose") version "2.3.21" // this version matches your Kotlin version
|
||||
@@ -53,7 +59,9 @@ Add the classpath to your top-level project `build.gradle.kts` file:
|
||||
|
||||
### Configuration options with the Compose Compiler Gradle Plugin
|
||||
|
||||
To configure the Compose compiler using the Gradle plugin, add the `composeCompiler` block to the module's `build.gradle.kts` file at the top level:
|
||||
To configure the Compose compiler using the Gradle plugin, add the
|
||||
`composeCompiler` block to the module's `build.gradle.kts` file at the top
|
||||
level:
|
||||
|
||||
android { ... }
|
||||
|
||||
@@ -66,9 +74,10 @@ For the full list of available options, see the [documentation](https://www.jetb
|
||||
|
||||
## Set up Compose dependencies
|
||||
|
||||
Always use the latest Compose BOM version: `2026.06.01`.
|
||||
Always use the latest Compose BOM version: `2026.08.00`.
|
||||
|
||||
Set the `compose` flag to `true` inside the Android [`BuildFeatures`](https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/dsl/BuildFeatures) to enable [Compose functionality](https://developer.android.com/develop/ui/compose/tooling) in Android Studio.
|
||||
Set the `compose` flag to `true` inside the Android [`BuildFeatures`](https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/dsl/BuildFeatures) to
|
||||
enable [Compose functionality](https://developer.android.com/develop/ui/compose/tooling) in Android Studio.
|
||||
|
||||
Add the following definition to your app's `build.gradle` file:
|
||||
|
||||
@@ -94,7 +103,7 @@ Add the Compose BOM and the subset of Compose library dependencies:
|
||||
|
||||
dependencies {
|
||||
|
||||
def composeBom = platform('androidx.compose:compose-bom:2026.06.01')
|
||||
def composeBom = platform('androidx.compose:compose-bom:2026.08.00')
|
||||
implementation composeBom
|
||||
androidTestImplementation composeBom
|
||||
|
||||
@@ -133,7 +142,7 @@ Add the Compose BOM and the subset of Compose library dependencies:
|
||||
|
||||
dependencies {
|
||||
|
||||
val composeBom = platform("androidx.compose:compose-bom:2026.06.01")
|
||||
val composeBom = platform("androidx.compose:compose-bom:2026.08.00")
|
||||
implementation(composeBom)
|
||||
androidTestImplementation(composeBom)
|
||||
|
||||
@@ -169,12 +178,20 @@ Add the Compose BOM and the subset of Compose library dependencies:
|
||||
}
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Jetpack Compose is shipped using a Bill of Materials (BOM), to keep the versions of all library groups in sync. Read more about it in the [Bill of Materials page](https://developer.android.com/develop/ui/compose/bom/bom).
|
||||
> **Note:** Jetpack Compose is shipped using a Bill of Materials (BOM), to keep the versions of all library groups in sync. Read more about it in the [Bill of
|
||||
> Materials page](https://developer.android.com/develop/ui/compose/bom/bom).
|
||||
|
||||
## `compileSdk` and Android Gradle Plugin compatibility
|
||||
|
||||
Compose library releases continually adopt the latest `compileSdk` versions to provide access to the latest Android features. Newer `compileSdk` versions require newer versions of Android Gradle Plugin, so adopting new Compose releases also requires projects to adopt new versions of the Android Gradle Plugin. We recommend keeping your project's `compileSdk` up to date with the latest released versions. `compileSdk` is unrelated from `targetSdk`.
|
||||
Compose library releases continually adopt the latest `compileSdk` versions to
|
||||
provide access to the latest Android features. Newer `compileSdk` versions
|
||||
require newer versions of Android Gradle Plugin, so adopting new Compose
|
||||
releases also requires projects to adopt new versions of the Android Gradle
|
||||
Plugin. We recommend keeping your project's `compileSdk` up to date with the
|
||||
latest released versions. `compileSdk` is unrelated from `targetSdk`.
|
||||
|
||||
For example, starting with Compose 1.12.0, projects are required to use `compileSdk 37` and Android Gradle Plugin (AGP) 9.
|
||||
For example, starting with Compose 1.12.0, projects are required to use
|
||||
`compileSdk 37` and Android Gradle Plugin (AGP) 9.
|
||||
|
||||
To check which version of AGP is supported for different API levels, see the [Android Gradle plugin API level support](https://developer.android.com/build/releases/about-agp#api-level-support) documentation.
|
||||
To check which version of AGP is supported for different API levels, see the
|
||||
[Android Gradle plugin API level support](https://developer.android.com/build/releases/about-agp#api-level-support) documentation.
|
||||
+8
-2
@@ -14,12 +14,18 @@ Prioritize layouts that meet the following criteria:
|
||||
|
||||
### 3. Risk assessment
|
||||
|
||||
Evaluate the migration risk based on: \* **Reusability:** Find layouts with **minimum reuse** across the project to limit regression impact. \* **Accessibility:** Ensure the layout has an **easily accessible entry point** (e.g., used in a simple Activity, Fragment, or as a standalone include).
|
||||
Evaluate the migration risk based on:
|
||||
\* **Reusability:** Find layouts with **minimum reuse** across the project to limit regression impact.
|
||||
\* **Accessibility:** Ensure the layout has an **easily accessible entry point** (e.g., used in a simple Activity, Fragment, or as a standalone include).
|
||||
|
||||
*** ** * ** ***
|
||||
|
||||
## Output requirements
|
||||
|
||||
Provide a ranked list of the top 3-5 candidates. For each candidate, include: 1. **File path:** (e.g., `res/layout/item_user_profile.xml`) 2. **Rationale:** Why this is a good candidate based on the provided criteria. 3. **Complexity score:** A rating from 1-5 (1 being simplest). 4. **Dependency count:** List of custom/external views found within.
|
||||
Provide a ranked list of the top 3-5 candidates. For each candidate, include:
|
||||
1. **File path:** (e.g., `res/layout/item_user_profile.xml`)
|
||||
2. **Rationale:** Why this is a good candidate based on the provided criteria.
|
||||
3. **Complexity score:** A rating from 1-5 (1 being simplest).
|
||||
4. **Dependency count:** List of custom/external views found within.
|
||||
|
||||
**Action:** If you support user interaction, ask the user to choose which XML to proceed with. Else proceed with the best option, based on the previous criteria.
|
||||
+7
-5
@@ -1,6 +1,7 @@
|
||||
## 1. Structural analysis \& mapping
|
||||
|
||||
**Identify the precise mapping** between XML elements and Compose equivalents. You must determine:
|
||||
**Identify the precise mapping** between XML elements and Compose equivalents.
|
||||
You must determine:
|
||||
|
||||
- The exact `@Composable` functions (e.g., `ConstraintLayout`, `Column`, `LazyColumn`) that replace the XML tag hierarchy.
|
||||
- The specific parameters and `Modifier` extensions required to replicate XML attributes (e.g., `layout_width`, `padding`, `elevation`).
|
||||
@@ -8,7 +9,9 @@
|
||||
|
||||
## 2. Migration execution
|
||||
|
||||
**Convert the XML layout code to Jetpack Compose**, ensuring the visual hierarchy and layout logic are preserved while leveraging Compose's declarative nature.
|
||||
**Convert the XML layout code to Jetpack Compose**, ensuring the visual
|
||||
hierarchy and layout logic are preserved while leveraging Compose's declarative
|
||||
nature.
|
||||
|
||||
## 3. Theming \& design system integrity
|
||||
|
||||
@@ -20,7 +23,8 @@
|
||||
|
||||
## 4. Component layering \& reusability
|
||||
|
||||
Evaluate if the XML layout serves as a foundation-level design system component (reused across the app with a distinct role). If it is:
|
||||
Evaluate if the XML layout serves as a foundation-level design system component
|
||||
(reused across the app with a distinct role). If it is:
|
||||
|
||||
- **Create a reusable composable:** Do not just inline the code. Define a new standalone `@Composable`.
|
||||
- **Parameterization:** Expose specific parameters for variable data (text, colors, styles) and use `Modifier` for layout-specific customizations.
|
||||
@@ -40,7 +44,6 @@ Example before migration:
|
||||
|
||||
Example after migration:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -70,7 +73,6 @@ fun RoundedBorderlessButton(
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Use this skill to integrate the Jetpack Compose Styles API into an
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-14'
|
||||
keywords:
|
||||
- Jetpack Compose
|
||||
- Styles
|
||||
@@ -30,11 +30,13 @@ metadata:
|
||||
- The project must use `compileSdk` version 37 or higher.
|
||||
- The project must use `androidx.compose.foundation:foundation` version `1.12.0-alpha01` or higher.
|
||||
- Alternatively, the project must use Compose BOM version `2026.04.01` or higher.
|
||||
- The API requires this exact package: `import androidx.compose.foundation.style.Style`
|
||||
- The API requires this exact package: `import
|
||||
androidx.compose.foundation.style.Style`
|
||||
|
||||
### 2. Configure compiler options to enable experimental API
|
||||
|
||||
You must opt-in to the experimental API at the project level. Add the following block to your module's `build.gradle.kts`:
|
||||
You must opt-in to the experimental API at the project level. Add the following
|
||||
block to your module's `build.gradle.kts`:
|
||||
|
||||
kotlin {
|
||||
compilerOptions {
|
||||
@@ -47,9 +49,12 @@ You must opt-in to the experimental API at the project level. Add the following
|
||||
|
||||
Refer to the official documentation to complete specific development tasks:
|
||||
|
||||
- Basic Style Usage: To set backgrounds, sizes, and alignments on a component, follow the [Compose Styles Fundamentals Guide](references/android/develop/ui/compose/styles/fundamentals.md).
|
||||
- State and Transitions: To configure property changes for state shifts (like pressed or hovered), follow the [Animations and State-Based Styling Guide](references/android/develop/ui/compose/styles/state-animations.md).
|
||||
- Architecture Trade offs: To decide when to use a Style versus a standard Modifier, follow the [Styles versus Modifiers Comparison](references/android/develop/ui/compose/styles/styles-vs-modifiers.md).
|
||||
- Basic Style Usage: To set backgrounds, sizes, and alignments on a component, follow the [Compose Styles Fundamentals
|
||||
Guide](references/android/develop/ui/compose/styles/fundamentals.md).
|
||||
- State and Transitions: To configure property changes for state shifts (like pressed or hovered), follow the [Animations and State-Based Styling
|
||||
Guide](references/android/develop/ui/compose/styles/state-animations.md).
|
||||
- Architecture Trade offs: To decide when to use a Style versus a standard Modifier, follow the [Styles versus Modifiers
|
||||
Comparison](references/android/develop/ui/compose/styles/styles-vs-modifiers.md).
|
||||
- Theme Level Integration: To connect style definitions with custom themes, follow [Theming with Styles](references/android/develop/ui/compose/styles/theming.md) and [Custom Themes in Compose](references/android/develop/ui/compose/designsystems/custom.md).
|
||||
|
||||
## Step-by-Step Migration Workflow
|
||||
@@ -66,7 +71,6 @@ Refer to the official documentation to complete specific development tasks:
|
||||
1. Create a new file named `ComponentStyles.kt` in your theme directory.
|
||||
2. Define a top-level data class to hold your component styles, for example, the Jetsnack one is called `JetsnackStyles`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
object ExampleComponentStyles {
|
||||
@@ -77,14 +81,13 @@ Refer to the official documentation to complete specific development tasks:
|
||||
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
3. Expose this class through your custom theme with a static reference, don't use `CompositionLocals` here as it's not required.
|
||||
3. Expose this class through your custom theme with a static reference, don't
|
||||
use `CompositionLocals` here as it's not required.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Immutable
|
||||
@@ -101,14 +104,13 @@ Refer to the official documentation to complete specific development tasks:
|
||||
val styles: ComponentStyles = ComponentStyles
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
4. Provide extensions on `StyleScope` to reference theme tokens directly if they are exposed using `CompositionLocals`. For example:
|
||||
4. Provide extensions on `StyleScope` to reference theme tokens directly if
|
||||
they are exposed using `CompositionLocals`. For example:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val StyleScope.colors: JetsnackColors
|
||||
@@ -119,15 +121,14 @@ Refer to the official documentation to complete specific development tasks:
|
||||
|
||||
val StyleScope.shapes: Shapes
|
||||
get() = LocalJetsnackTheme.currentValue.shapes
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Step 3: Migrate a component to Styles API
|
||||
|
||||
For each custom component (for example, `CustomButton`), complete the following sequence:
|
||||
For each custom component (for example, `CustomButton`), complete the following
|
||||
sequence:
|
||||
|
||||
1. **Establish a visual baseline (If an emulator is available):**
|
||||
- **If you CANNOT run an Android emulator:** Skip this step entirely and proceed to Step 2.
|
||||
@@ -136,7 +137,8 @@ For each custom component (for example, `CustomButton`), complete the following
|
||||
- **Option B (If no test exists):** Create a test using the project's existing testing framework, then run it.
|
||||
- **Option C (If no framework exists):** Create a minimal screenshot test using UI Automator or Espresso, then run it.
|
||||
2. **Remove individual styling parameters** : Remove styling parameters such as `backgroundColor`, `shape`, `textStyle`, and `contentPadding` from the signature - anything that `StyleScope` supports.
|
||||
3. **Add the style parameter** : Add `style: Style = Style` to the function signature. Always ensure the default value is exactly `Style` (e.g., `style: Style = Style`) and not a specific style default like `ChipStyleDefault` or any other value.
|
||||
3. **Add the style parameter** : Add `style: Style = Style` to the function signature. Always ensure the default value is exactly `Style` (e.g., `style:
|
||||
Style = Style`) and not a specific style default like `ChipStyleDefault` or any other value.
|
||||
4. **Declare state tracking** : If the component is interactable, create a `MutableStyleState` using the interaction source. Update state fields (such as `isEnabled`) inside the Composable to track the state correctly.
|
||||
5. **Apply styleable modifier** : Replace specific layout modifiers on the root element with `Modifier.styleable()`.
|
||||
6. **Move defaults to ComponentStyles** : Move hardcoded values from the component definition to a dedicated `Style` instance in `ComponentStyles.kt`.
|
||||
@@ -146,7 +148,6 @@ For each custom component (for example, `CustomButton`), complete the following
|
||||
|
||||
Before Migration:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -171,14 +172,12 @@ fun CustomButton(
|
||||
content = content,
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
After Migration:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Exposed via ComponentStyles.kt
|
||||
@@ -216,7 +215,6 @@ fun CustomButton(
|
||||
content = content,
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
+69
-42
@@ -1,4 +1,7 @@
|
||||
While Material is our recommended design system and Jetpack Compose ships an implementation of Material, you are not forced to use it. Material is built entirely on public APIs, so it's possible to create your own design system in the same manner.
|
||||
While Material is our recommended design system and Jetpack Compose ships an
|
||||
implementation of Material, you are not forced to use it. Material is built
|
||||
entirely on public APIs, so it's possible to create your own design system in
|
||||
the same manner.
|
||||
|
||||
There are several approaches you might take:
|
||||
|
||||
@@ -6,15 +9,21 @@ There are several approaches you might take:
|
||||
- [Replace one or more Material systems](https://developer.android.com/develop/ui/compose/designsystems/custom#replacing-systems) --- `Colors`, `Typography`, or `Shapes` --- with custom implementations while keeping the others.
|
||||
- [Implement a fully custom design system](https://developer.android.com/develop/ui/compose/designsystems/custom#implementing-fully-custom) to replace `MaterialTheme`.
|
||||
|
||||
You may also want to continue using Material components with a custom design system. It's possible to do this but there are things to keep in mind to suit the approach you've taken.
|
||||
You may also want to continue using Material components with a custom design
|
||||
system. It's possible to do this but there are things to keep in mind to suit
|
||||
the approach you've taken.
|
||||
|
||||
To learn more about the lower-level constructs and APIs used by `MaterialTheme` and custom design systems, check out the [Anatomy of a theme in Compose](https://developer.android.com/develop/ui/compose/designsystems/anatomy) guide.
|
||||
To learn more about the lower-level constructs and APIs used by `MaterialTheme`
|
||||
and custom design systems, check out the [Anatomy of a theme in Compose](https://developer.android.com/develop/ui/compose/designsystems/anatomy) guide.
|
||||
|
||||
## Extend Material Theming
|
||||
|
||||
Compose Material closely models [Material Theming](https://m3.material.io/) to make it straightforward and type-safe to follow the Material guidelines. However, it's possible to extend the color, typography, and shape sets with additional values. The simplest approach is to add extension properties:
|
||||
Compose Material closely models
|
||||
[Material Theming](https://m3.material.io/)
|
||||
to make it straightforward and type-safe to follow the Material guidelines.
|
||||
However, it's possible to extend the color, typography, and shape sets with
|
||||
additional values. The simplest approach is to add extension properties:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Use with MaterialTheme.colorScheme.snackbarAction
|
||||
@@ -29,21 +38,26 @@ val Typography.textFieldInput: TextStyle
|
||||
// Use with MaterialTheme.shapes.card
|
||||
val Shapes.card: Shape
|
||||
get() = RoundedCornerShape(size = 20.dp)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
This provides consistency with `MaterialTheme` usage APIs. An example of this defined by Compose itself is [`surfaceColorAtElevation`](https://developer.android.com/reference/kotlin/androidx/compose/material3/package-summary#(androidx.compose.material3.ColorScheme).surfaceColorAtElevation(androidx.compose.ui.unit.Dp)), which determines the surface color that should be used depending on the elevation.
|
||||
This provides consistency with `MaterialTheme` usage APIs. An example of this
|
||||
defined by Compose itself is
|
||||
[`surfaceColorAtElevation`](https://developer.android.com/reference/kotlin/androidx/compose/material3/package-summary#(androidx.compose.material3.ColorScheme).surfaceColorAtElevation(androidx.compose.ui.unit.Dp)),
|
||||
which determines the surface color that should be used depending on the
|
||||
elevation.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** This approach is only recommended for straightforward theming value additions, or for values that are the same in different themes. If you have multiple themes, it's better to define a class with new properties instead.
|
||||
|
||||
Another approach is to define an extended theme that "wraps" `MaterialTheme` and its values.
|
||||
Another approach is to define an extended theme that "wraps" `MaterialTheme` and
|
||||
its values.
|
||||
|
||||
Suppose you want to add two additional colors --- `caution` and `onCaution`, a yellow color used for actions that are semi-dangerous --- whilst keeping the existing Material colors:
|
||||
Suppose you want to add two additional colors --- `caution` and `onCaution`, a
|
||||
yellow color used for actions that are semi-dangerous --- whilst keeping the
|
||||
existing Material colors:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Immutable
|
||||
@@ -82,20 +96,22 @@ object ExtendedTheme {
|
||||
@Composable
|
||||
get() = LocalExtendedColors.current
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
This is similar to `MaterialTheme` usage APIs. It also supports multiple themes as you can nest `ExtendedTheme`s in the same way as `MaterialTheme`.
|
||||
This is similar to `MaterialTheme` usage APIs. It also supports multiple themes
|
||||
as you can nest `ExtendedTheme`s in the same way as `MaterialTheme`.
|
||||
|
||||
### Use Material components
|
||||
|
||||
When extending Material Theming, existing `MaterialTheme` values are maintained and Material components still have reasonable defaults.
|
||||
When extending Material Theming, existing `MaterialTheme` values are maintained
|
||||
and Material components still have reasonable defaults.
|
||||
|
||||
If you want to use extended values in components, wrap them in your own composable functions, directly setting the values you want to alter, and exposing others as parameters to the containing composable:
|
||||
If you want to use extended values in components, wrap them in your own
|
||||
composable functions, directly setting the values you want to alter, and
|
||||
exposing others as parameters to the containing composable:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -115,14 +131,13 @@ fun ExtendedButton(
|
||||
content = content
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
You would then replace usages of `Button` with `ExtendedButton` where appropriate.
|
||||
You would then replace usages of `Button` with `ExtendedButton` where
|
||||
appropriate.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -134,18 +149,19 @@ fun ExtendedApp() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Replace Material subsystems
|
||||
|
||||
Instead of extending Material Theming, you may want to replace one or more systems --- `Colors`, `Typography`, or `Shapes` --- with a custom implementation, while maintaining the others.
|
||||
Instead of extending Material Theming, you may want to replace one or more
|
||||
systems --- `Colors`, `Typography`, or `Shapes` --- with a custom implementation,
|
||||
while maintaining the others.
|
||||
|
||||
Suppose you want to replace the type and shape systems while keeping the color system:
|
||||
Suppose you want to replace the type and shape systems while keeping the color
|
||||
system:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Immutable
|
||||
@@ -206,21 +222,22 @@ object ReplacementTheme {
|
||||
@Composable
|
||||
get() = LocalReplacementShapes.current
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Use Material components
|
||||
|
||||
When one or more systems of `MaterialTheme` have been replaced, using Material components as-is may result in unwanted Material color, type, or shape values.
|
||||
When one or more systems of `MaterialTheme` have been replaced, using Material
|
||||
components as-is may result in unwanted Material color, type, or shape values.
|
||||
|
||||
If you want to use replacement values in components, wrap them in your own composable functions, directly setting the values for the relevant system, and exposing others as parameters to the containing composable.
|
||||
If you want to use replacement values in components, wrap them in your own
|
||||
composable functions, directly setting the values for the relevant system, and
|
||||
exposing others as parameters to the containing composable.
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** Not all values may be exposed as parameters in Material composables, in particular with `CompositionLocal` composables (such as `LocalTextStyle`). In such cases you may need to wrap `content` lambdas in provider functions (like `ProvideTextStyle`).
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -242,14 +259,13 @@ fun ReplacementButton(
|
||||
}
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
You would then replace usages of `Button` with `ReplacementButton` where appropriate.
|
||||
You would then replace usages of `Button` with `ReplacementButton` where
|
||||
appropriate.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -261,28 +277,33 @@ fun ReplacementApp() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Implement a fully custom design system
|
||||
|
||||
You may want to replace Material Theming with a fully custom design system. Consider that `MaterialTheme` provides the following systems:
|
||||
You may want to replace Material Theming with a fully custom design system.
|
||||
Consider that `MaterialTheme` provides the following systems:
|
||||
|
||||
- `Colors`, `Typography`, and `Shapes`: Material Theming systems
|
||||
- `TextSelectionColors`: Colors used for text selection by `Text` and `TextField`
|
||||
- `Ripple` and `RippleTheme`: Material implementation of `Indication`
|
||||
|
||||
If you want to continue using Material components, you must replace some of these systems in your custom themes or handle the systems in your components to avoid unwanted behavior.
|
||||
If you want to continue using Material components, you must replace some of
|
||||
these systems in your custom themes or handle the systems in your
|
||||
components to avoid unwanted behavior.
|
||||
|
||||
However, design systems are not limited to the concepts Material relies on. You can modify existing systems and introduce entirely new ones --- with new classes and types --- to make other concepts compatible with themes.
|
||||
However, design systems are not limited to the concepts Material relies on. You
|
||||
can modify existing systems and introduce entirely new ones --- with new classes
|
||||
and types --- to make other concepts compatible with themes.
|
||||
|
||||
In the following code, we model a custom color system that includes gradients (`List<Color>`), include a type system, introduce a new elevation system, and exclude other systems provided by `MaterialTheme`:
|
||||
In the following code, we model a custom color system that includes gradients
|
||||
(`List<Color>`), include a type system, introduce a new elevation system,
|
||||
and exclude other systems provided by `MaterialTheme`:
|
||||
|
||||

|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Immutable
|
||||
@@ -362,20 +383,23 @@ object CustomTheme {
|
||||
@Composable
|
||||
get() = LocalCustomElevation.current
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Use Material components
|
||||
|
||||
When no `MaterialTheme` is present, using Material components as-is will result in unwanted Material color, type, and shape values and indication behavior.
|
||||
When no `MaterialTheme` is present, using Material components as-is will result
|
||||
in unwanted Material color, type, and shape values and indication behavior.
|
||||
|
||||
If you want to use custom values in components, wrap them in your own composable functions, directly setting the values for the relevant system, and exposing others as parameters to the containing composable.
|
||||
If you want to use custom values in components, wrap them in your own composable
|
||||
functions, directly setting the values for the relevant system, and exposing
|
||||
others as parameters to the containing composable.
|
||||
|
||||
We recommend that you access values you set from your custom theme. Alternatively, if your theme doesn't provide `Color`, `TextStyle`, `Shape`, or other systems, you can hardcode them.
|
||||
We recommend that you access values you set from your custom theme.
|
||||
Alternatively, if your theme doesn't provide `Color`, `TextStyle`, `Shape`, or
|
||||
other systems, you can hardcode them.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -414,7 +438,6 @@ fun CustomButton(
|
||||
}
|
||||
|
||||
val ButtonShape = RoundedCornerShape(percent = 50)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -422,7 +445,11 @@ val ButtonShape = RoundedCornerShape(percent = 50)
|
||||
> [!NOTE]
|
||||
> **Note:** `Button` uses `rememberRipple()` internally to provide a `Ripple` `Indication`. It's a good idea to check the source code when implementing other custom components that wrap existing components.
|
||||
|
||||
If you've introduced new class types --- such as `List<Color>` to represent gradients --- then it may be better to implement components from scratch instead of wrapping them. For an example, take a look at [`JetsnackButton`](https://github.com/android/compose-samples/blob/main/Jetsnack/app/src/main/java/com/example/jetsnack/ui/components/Button.kt) from the Jetsnack sample.
|
||||
If you've introduced new class types --- such as `List<Color>` to represent
|
||||
gradients --- then it may be better to implement components from scratch instead
|
||||
of wrapping them. For an example, take a look at
|
||||
[`JetsnackButton`](https://github.com/android/compose-samples/blob/main/Jetsnack/app/src/main/java/com/example/jetsnack/ui/components/Button.kt)
|
||||
from the Jetsnack sample.
|
||||
|
||||
## Recommended for you
|
||||
|
||||
|
||||
+58
-52
@@ -6,7 +6,10 @@ There are three ways you can adopt Styles throughout your app:
|
||||
|
||||
## Available properties on Styles
|
||||
|
||||
Styles support many of the same properties that modifiers support; however, not everything that is a modifier can be replicated with a Style. You still need modifiers for certain behaviors, like interactions, custom drawing, or stacking of properties.
|
||||
Styles support many of the same properties that modifiers support; however, not
|
||||
everything that is a modifier can be replicated with a Style. You still need
|
||||
modifiers for certain behaviors, like interactions, custom drawing, or stacking
|
||||
of properties.
|
||||
|
||||
| Grouping | Properties | Inherited by children |
|
||||
|---|---|---|
|
||||
@@ -33,7 +36,6 @@ Styles support many of the same properties that modifiers support; however, not
|
||||
|
||||
Components that expose a `Style` parameter allow you to set their styling:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
BaseButton(
|
||||
@@ -42,14 +44,13 @@ BaseButton(
|
||||
) {
|
||||
BaseText("Click me")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Within the style lambda, you can set various properties, such as `externalPadding` or `background`:
|
||||
Within the style lambda, you can set various properties, such as `externalPadding`
|
||||
or `background`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
BaseButton(
|
||||
@@ -58,18 +59,19 @@ BaseButton(
|
||||
) {
|
||||
BaseText("Click me")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
For the full list of supported properties, see [Available properties on Styles](https://developer.android.com/develop/ui/compose/styles/fundamentals#properties-styles).
|
||||
For the full list of supported properties, see [Available properties on
|
||||
Styles](https://developer.android.com/develop/ui/compose/styles/fundamentals#properties-styles).
|
||||
|
||||
## Apply Styles using modifiers for components with no existing parameter
|
||||
|
||||
For components that lack a built-in style parameter, you can still apply styles with the `styleable` modifier. This approach is also useful when developing your own custom components.
|
||||
For components that lack a built-in style parameter, you can still apply styles
|
||||
with the `styleable` modifier. This approach is also useful when developing your
|
||||
own custom components.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Row(
|
||||
@@ -77,14 +79,13 @@ Row(
|
||||
) {
|
||||
BaseText("Content")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Similar to the `style` parameter, you can include properties like `background`, `contentPadding`, or `externalPadding` inside the lambda.
|
||||
Similar to the `style` parameter, you can include properties like `background`,
|
||||
`contentPadding`, or `externalPadding` inside the lambda.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
Row(
|
||||
@@ -94,7 +95,6 @@ Row(
|
||||
) {
|
||||
BaseText("Content")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -102,28 +102,35 @@ Row(
|
||||
> [!NOTE]
|
||||
> **Note:** When using `Modifier.styleable`, the child composables won't have those properties applied to them, unless they are inherited properties. Only the container with the `styleable` modifier has those properties applied.
|
||||
|
||||
Multiple chained `Modifier.styleable` modifiers are additive with non-inherited properties on the applied composable, behaving similarly to multiple modifiers defining the same properties. For inherited properties, these are overridden, and the last `styleable` modifier in the chain sets the values.
|
||||
Multiple chained `Modifier.styleable` modifiers are additive with non-inherited
|
||||
properties on the applied composable, behaving similarly to multiple modifiers
|
||||
defining the same properties. For inherited properties, these are overridden,
|
||||
and the last `styleable` modifier in the chain sets the values.
|
||||
|
||||
When using `Modifier.styleable`, you may also want to create and supply a `StyleState` to be used with the modifier to apply state-based styling. For more details, see [State and animations with Styles](https://developer.android.com/develop/ui/compose/styles/state-animations).
|
||||
When using `Modifier.styleable`, you may also want to create and supply a
|
||||
`StyleState` to be used with the modifier to apply state-based styling. For more
|
||||
details, see [State and animations with
|
||||
Styles](https://developer.android.com/develop/ui/compose/styles/state-animations).
|
||||
|
||||
## Define a standalone Style
|
||||
|
||||
You can define a standalone Style for reusability purposes:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val style = Style { background(Color.Blue) }
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
You can then pass that defined style into a composable's style parameter or with `Modifier.styleable`. When using `Modifier.styleable`, you also need to create a `StyleState` object. `StyleState` is covered in detail in the [State and animations with Styles](https://developer.android.com/develop/ui/compose/styles/state-animations) documentation.
|
||||
You can then pass that defined style into a composable's style parameter or with
|
||||
`Modifier.styleable`. When using `Modifier.styleable`, you also need to create a
|
||||
`StyleState` object. `StyleState` is covered in detail in the [State and
|
||||
animations with Styles](https://developer.android.com/develop/ui/compose/styles/state-animations) documentation.
|
||||
|
||||
The following example shows how you can apply a Style either directly through a component's built-in parameters, or through a `Modifier.styleable`:
|
||||
The following example shows how you can apply a Style either directly through a
|
||||
component's built-in parameters, or through a `Modifier.styleable`:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val style = Style { background(Color.Blue) }
|
||||
@@ -140,14 +147,12 @@ Column(
|
||||
) {
|
||||
BaseText("Column content")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
You can also pass that Style into multiple components:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val style = Style { background(Color.Blue) }
|
||||
@@ -171,16 +176,15 @@ Row(
|
||||
) {
|
||||
BaseText("Row")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Add multiple Style properties
|
||||
|
||||
You can add multiple Style properties by setting different properties on each line:
|
||||
You can add multiple Style properties by setting different properties on each
|
||||
line:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
BaseButton(
|
||||
@@ -192,7 +196,6 @@ BaseButton(
|
||||
) {
|
||||
BaseText("Button")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -200,9 +203,12 @@ BaseButton(
|
||||
> [!IMPORTANT]
|
||||
> **Important:** Unlike modifier-based styling, properties in Styles override one another; the last property defined takes precedence.
|
||||
|
||||
Properties in Styles are not additive, unlike modifier-based styling. Styles take the last set value in the list of properties within one style block. In the following example, with the background set twice, the `TealColor` is the applied background. For padding, `contentPaddingTop` overrides the top padding set by `contentPadding` and does not combine the values.
|
||||
Properties in Styles are not additive, unlike modifier-based styling. Styles
|
||||
take the last set value in the list of properties within one style block. In the
|
||||
following example, with the background set twice, the `TealColor` is the applied
|
||||
background. For padding, `contentPaddingTop` overrides the top
|
||||
padding set by `contentPadding` and does not combine the values.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
BaseButton(
|
||||
@@ -221,7 +227,6 @@ BaseButton(
|
||||
) {
|
||||
BaseText("Click me!")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -231,9 +236,9 @@ overrides](https://developer.android.com/static/develop/ui/compose/styles/images
|
||||
|
||||
## Merge multiple style objects
|
||||
|
||||
You can create multiple Style objects and pass them into the style parameter of your composable.
|
||||
You can create multiple Style objects and pass them into the style parameter of
|
||||
your composable.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val style1 = Style { background(TealColor) }
|
||||
@@ -247,7 +252,6 @@ BaseButton(
|
||||
) {
|
||||
BaseText("Click me!")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -255,9 +259,12 @@ BaseButton(
|
||||
 **Figure 2.** Button with background color and `contentPaddingTop` set.
|
||||
|
||||
When multiple Styles specify the same property, the last set property is chosen. Because properties are not additive in Styles, the last padding passed in overrides the `contentPaddingHorizontal` set by the initial `contentPadding`. Additionally, the last background color overrides the background color set by the initial style passed in.
|
||||
When multiple Styles specify the same property, the last set
|
||||
property is chosen. Because properties are not additive in Styles, the last
|
||||
padding passed in overrides the `contentPaddingHorizontal` set by the initial
|
||||
`contentPadding`. Additionally, the last background color overrides the
|
||||
background color set by the initial style passed in.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val style1 = Style {
|
||||
@@ -278,12 +285,12 @@ BaseButton(
|
||||
) {
|
||||
BaseText("Click me!")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
In this case, the styling applied has a light gray background and `32.dp` padding, except for the left and right padding, which has a value of `8.dp`.
|
||||
In this case, the styling applied has a light gray background and `32.dp` padding,
|
||||
except for the left and right padding, which has a value of `8.dp`.
|
||||
 **Figure 3.** Button with `contentPadding` that's overridden by different Styles.
|
||||
|
||||
@@ -292,7 +299,9 @@ Styles](https://developer.android.com/static/develop/ui/compose/styles/images/bu
|
||||
> [!NOTE]
|
||||
> **Note:** While the Style APIs are experimental, you need to opt-in to enable Style inheritance by setting the flag `ComposeFoundationFlags.isInheritedTextStyleEnabled = true`.
|
||||
|
||||
Certain style properties, such as `contentColor` and text style-related properties, propagate to the child composables. A style set on a child composable overrides the inherited parent styling for that specific child.
|
||||
Certain style properties, such as `contentColor` and text style-related
|
||||
properties, propagate to the child composables. A style set on a child
|
||||
composable overrides the inherited parent styling for that specific child.
|
||||
 **Figure 4.** Style propagation with `Style`, `styleable`, and direct parameters.
|
||||
|
||||
@@ -308,9 +317,9 @@ parameters](https://developer.android.com/static/develop/ui/compose/styles/image
|
||||
|
||||
### Parent styling
|
||||
|
||||
You can set text properties (such as `contentColor`) from the parent composable, and they propagate to all child `Text` composables.
|
||||
You can set text properties (such as `contentColor`) from the parent composable,
|
||||
and they propagate to all child `Text` composables.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val styleState = remember { MutableStyleState(null) }
|
||||
@@ -327,7 +336,6 @@ Column(
|
||||
BaseText("certain properties")
|
||||
BaseText("from their parents")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -337,9 +345,10 @@ inheritance](https://developer.android.com/static/develop/ui/compose/styles/imag
|
||||
|
||||
### Child override of properties
|
||||
|
||||
You can also set styling on a specific `Text` composable. If the parent composable has styling set, the styling set on the child composable overrides the parent composable's styling.
|
||||
You can also set styling on a specific `Text` composable. If the parent composable
|
||||
has styling set, the styling set on the child composable overrides the
|
||||
parent composable's styling.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val styleState = remember { MutableStyleState(null) }
|
||||
@@ -358,7 +367,6 @@ Column(
|
||||
BaseText("override properties")
|
||||
BaseText("set by their parents")
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -368,40 +376,39 @@ properties](https://developer.android.com/static/develop/ui/compose/styles/image
|
||||
|
||||
## Implement custom Style properties
|
||||
|
||||
You can create custom properties that map to existing Style definitions by using extension functions on the `StyleScope`, as shown in the following example:
|
||||
You can create custom properties that map to existing Style definitions by using
|
||||
extension functions on the `StyleScope`, as shown in the following example:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
fun StyleScope.outlinedBackground(color: Color) {
|
||||
border(1.dp, color)
|
||||
background(color)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Apply this new property within a Style definition:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val customExtensionStyle = Style {
|
||||
outlinedBackground(Color.Blue)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Creating new styleable properties is unsupported. If your use case requires such support, submit a [feature request](https://issuetracker.google.com/issues/new?component=612128).
|
||||
Creating new styleable properties is unsupported. If your use case
|
||||
requires such support, submit a [feature request](https://issuetracker.google.com/issues/new?component=612128).
|
||||
|
||||
## Read `CompositionLocal` values
|
||||
|
||||
It's a common pattern to store design system tokens within a `CompositionLocal`, to access the variables without needing to pass them as parameters. Styles can access `CompositionLocal`s to retrieve system-wide values within a style:
|
||||
It's a common pattern to store design system tokens within a `CompositionLocal`,
|
||||
to access the variables without needing to pass them as parameters. Styles
|
||||
can access `CompositionLocal`s to retrieve system-wide values within a style:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val buttonStyle = Style {
|
||||
@@ -409,7 +416,6 @@ val buttonStyle = Style {
|
||||
shape(RoundedCornerShape(50))
|
||||
background(Brush.verticalGradient(LocalCustomColors.currentValue.background))
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
+50
-38
@@ -1,8 +1,15 @@
|
||||
<br />
|
||||
|
||||
The Styles API offers a declarative and streamlined approach to managing UI changes during interaction states like `hovered`, `focused`, and `pressed`. With this API, you can significantly decrease the boilerplate code typically required when using modifiers.
|
||||
The Styles API offers a declarative and streamlined approach to managing UI
|
||||
changes during interaction states like `hovered`, `focused`, and `pressed`. With
|
||||
this API, you can significantly decrease the boilerplate code typically required
|
||||
when using modifiers.
|
||||
|
||||
To facilitate reactive styling, `StyleState` acts as a stable, read-only interface that tracks the active state of an element (such as its enabled, pressed, or focused status). Within a `StyleScope`, you can access this through the `state` property to implement conditional logic directly in your Style definitions.
|
||||
To facilitate reactive styling, `StyleState` acts as a stable, read-only
|
||||
interface that tracks the active state of an element (such as its enabled,
|
||||
pressed, or focused status). Within a `StyleScope`, you can access this through
|
||||
the `state` property to implement conditional logic directly in your Style
|
||||
definitions.
|
||||
|
||||
## State-based interaction: Hovered, focused, pressed, selected, enabled, toggled
|
||||
|
||||
@@ -14,13 +21,15 @@ Styles come with built-in support for common interactions:
|
||||
- Enabled
|
||||
- Toggled
|
||||
|
||||
It's also possible to support custom states. See the [Custom State Styling with StyleState](https://developer.android.com/develop/ui/compose/styles/state-animations#custom-state) section for more information.
|
||||
It's also possible to support custom states. See the [Custom State Styling with
|
||||
StyleState](https://developer.android.com/develop/ui/compose/styles/state-animations#custom-state) section for more information.
|
||||
|
||||
### Handle interaction states with Style parameters
|
||||
|
||||
The following example demonstrates modifying the `background` and `borderColor` in response to interaction states, specifically switching to purple when hovered and blue when focused:
|
||||
The following example demonstrates modifying the `background` and `borderColor`
|
||||
in response to interaction states, specifically switching to purple when hovered
|
||||
and blue when focused:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Preview
|
||||
@@ -47,17 +56,16 @@ private fun OpenButton() {
|
||||
}
|
||||
)
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
**Figure 1.** Changing background color based on hovered and focused states.
|
||||
|
||||
You can also create nested state definitions. For example, you can define a specific style for when a button is being both pressed and hovered simultaneously:
|
||||
You can also create nested state definitions. For example, you can define a
|
||||
specific style for when a button is being both pressed and hovered
|
||||
simultaneously:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -91,7 +99,6 @@ private fun OpenButton_CombinedStates() {
|
||||
}
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -100,15 +107,18 @@ private fun OpenButton_CombinedStates() {
|
||||
|
||||
### Custom composables with Modifier.styleable
|
||||
|
||||
When creating your own `styleable` components, you must connect an `interactionSource` to a `styleState`. Then, pass this state into `Modifier.styleable` to utilize it.
|
||||
When creating your own `styleable` components, you must connect an
|
||||
`interactionSource` to a `styleState`. Then, pass this state into
|
||||
`Modifier.styleable` to utilize it.
|
||||
|
||||
Consider a scenario where your design system includes a `GradientButton`. You may want to create a `LoginButton` that inherits from `GradientButton`, but alters its colors during interactions, like being pressed.
|
||||
Consider a scenario where your design system includes a `GradientButton`. You
|
||||
may want to create a `LoginButton` that inherits from `GradientButton`, but
|
||||
alters its colors during interactions, like being pressed.
|
||||
|
||||
- To enable `interactionSource` style updates, include an `interactionSource` as a parameter within your composable. Use the provided parameter or, if one is not supplied, initialize a new `MutableInteractionSource`.
|
||||
- Initialize the `styleState` by providing the `interactionSource`. Make sure the `styleState`'s enabled status reflects the value of the provided enabled parameter.
|
||||
- Assign the `interactionSource` to the `focusable` and `clickable` modifiers. Finally, apply the `styleState` to the modifier's `styleable` parameter.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -137,14 +147,13 @@ private fun GradientButton(
|
||||
content = content,
|
||||
)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
You can now use the `interactionSource` state to drive style modifications with the pressed, focused, and hovered options inside the style block:
|
||||
You can now use the `interactionSource` state to drive style modifications with
|
||||
the pressed, focused, and hovered options inside the style block:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Preview
|
||||
@@ -165,7 +174,6 @@ fun LoginButton() {
|
||||
BaseText("Login")
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -174,9 +182,12 @@ fun LoginButton() {
|
||||
|
||||
## Animate style changes
|
||||
|
||||
Styles state changes come with built-in animation support. You can wrap the new property within any state change block with `animate` to automatically add animations between different states. This is similar to the `animate*AsState` APIs. The following example animates the `borderColor` from black to blue when the state changes to focused:
|
||||
Styles state changes come with built-in animation support. You can wrap the new
|
||||
property within any state change block with `animate` to automatically add
|
||||
animations between different states. This is similar to the `animate*AsState`
|
||||
APIs. The following example animates the `borderColor` from black to blue when
|
||||
the state changes to focused:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val animatingStyle = Style {
|
||||
@@ -211,16 +222,16 @@ private fun AnimatingStyleChanges() {
|
||||
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
**Figure 4.** Animating color changes on press.
|
||||
|
||||
The `animate` API accepts an `animationSpec` to change the duration or shape of the animation curve. The following example animates the size of the box with a `spring` spec:
|
||||
The `animate` API accepts an `animationSpec` to change the duration or shape of
|
||||
the animation curve. The following example animates the size of the box with a
|
||||
`spring` spec:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
val animatingStyleSpec = Style {
|
||||
@@ -256,7 +267,6 @@ fun AnimatingStyleChangesSpec() {
|
||||
)
|
||||
.styleable(styleState, animatingStyleSpec))
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -265,7 +275,11 @@ fun AnimatingStyleChangesSpec() {
|
||||
|
||||
## Custom state styling with StyleState
|
||||
|
||||
Depending on your composable use case, you may have different styles that are backed by custom states. For example, if you have a media app, you may want to have different styling for the buttons in your `MediaPlayer` composable depending on the playback state of the player. Follow these steps to create and use your own custom state:
|
||||
Depending on your composable use case, you may have different styles that are
|
||||
backed by custom states. For example, if you have a media app, you may want to
|
||||
have different styling for the buttons in your `MediaPlayer` composable
|
||||
depending on the playback state of the player. Follow these steps to create and
|
||||
use your own custom state:
|
||||
|
||||
1. Define custom key
|
||||
2. Create `StyleState` extension
|
||||
@@ -273,9 +287,11 @@ Depending on your composable use case, you may have different styles that are ba
|
||||
|
||||
### Define custom key
|
||||
|
||||
To create a custom state-based style, first create a [`StyleStateKey`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/style/StyleStateKey) and pass in the default state value. When the app launches, the media player is in the `Stopped` state, so it's initialized in this way:
|
||||
To create a custom state-based style, first create a
|
||||
[`StyleStateKey`](https://developer.android.com/reference/kotlin/androidx/compose/foundation/style/StyleStateKey) and pass in the default state value. When the
|
||||
app launches, the media player is in the `Stopped` state, so it's initialized in
|
||||
this way:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
enum class PlayerState {
|
||||
@@ -285,16 +301,16 @@ enum class PlayerState {
|
||||
}
|
||||
|
||||
val playerStateKey = StyleStateKey(PlayerState.Stopped)
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Create StyleState extension functions
|
||||
|
||||
Define an extension function on `StyleState` to query the current `playState`. Then, create extension functions on `StyleScope` with your custom states passing in the `playStateKey`, a lambda with the specific state, and the style.
|
||||
Define an extension function on `StyleState` to query the current `playState`.
|
||||
Then, create extension functions on `StyleScope` with your custom states passing
|
||||
in the `playStateKey`, a lambda with the specific state, and the style.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Extension Function on MutableStyleState to query and set the current playState
|
||||
@@ -308,16 +324,16 @@ fun StyleScope.playerPlaying(block: () -> Unit) {
|
||||
fun StyleScope.playerPaused(block: () -> Unit) {
|
||||
state(playerStateKey, block, { key, state -> state[key] == PlayerState.Paused })
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Link to custom state
|
||||
|
||||
Define the `styleState` in your composable and set the `styleState.playState` equal to incoming state. Pass `styleState` into the `styleable` function on the modifier.
|
||||
Define the `styleState` in your composable and set the `styleState.playState`
|
||||
equal to incoming state. Pass `styleState` into the `styleable` function on the
|
||||
modifier.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -336,14 +352,13 @@ fun MediaPlayer(
|
||||
///..
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Within the `style` lambda, you can apply state-based styling for custom states, using the previously defined extension functions.
|
||||
Within the `style` lambda, you can apply state-based styling for custom states,
|
||||
using the previously defined extension functions.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -370,14 +385,12 @@ fun StyleStateKeySample() {
|
||||
style = style,
|
||||
state = PlayerState.Stopped)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
The following code is the full snippet for this example:
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
enum class PlayerState {
|
||||
@@ -443,7 +456,6 @@ fun StyleStateKeySample() {
|
||||
style = style,
|
||||
state = PlayerState.Stopped)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
+12
-5
@@ -1,4 +1,7 @@
|
||||
Styles differ from modifiers by design. Styles don't replace modifiers; instead, the two systems coexist with different goals. Internally, a Style is a modifier. You can do everything Styles can do with modifiers, but not all functionality in modifiers is available in Styles.
|
||||
Styles differ from modifiers by design. Styles don't replace modifiers; instead,
|
||||
the two systems coexist with different goals. Internally, a Style is a modifier.
|
||||
You can do everything Styles can do with modifiers, but not all functionality in
|
||||
modifiers is available in Styles.
|
||||
**Important:**
|
||||
|
||||
- **Choose Styles if:** You need to override a default of an existing component, perform high-performance animations, or define a theme-wide set of properties for a component.
|
||||
@@ -16,7 +19,8 @@ The following is a comparison between Styles versus modifiers:
|
||||
|
||||
## Limitations of modifiers
|
||||
|
||||
Modifiers have many benefits in the current Compose landscape. However, Styles address some limitations of modifiers, which the following list describes:
|
||||
Modifiers have many benefits in the current Compose landscape. However, Styles
|
||||
address some limitations of modifiers, which the following list describes:
|
||||
|
||||
- Modifiers are typically created in the Composition phase. Updates can force a full rerun of Composition, Layout, and Draw, even for small visual changes like color, unless you create lambda-based modifiers.
|
||||
- Conditional modifiers require disruptive if-else logic within fluent chains. Animating them requires manual state boilerplate and lacks a high-performance "auto-animate" mechanism.
|
||||
@@ -25,15 +29,18 @@ Modifiers have many benefits in the current Compose landscape. However, Styles a
|
||||
|
||||
## Limitations of Styles
|
||||
|
||||
While Styles can fill in some of the gaps that modifiers have, they also have some limitations, which show how they cannot entirely replace modifiers:
|
||||
While Styles can fill in some of the gaps that modifiers have, they also have
|
||||
some limitations, which show how they cannot entirely replace modifiers:
|
||||
|
||||
- Styles are specialized Modifiers. While a modifier can do anything a Style does, the reverse is not true. Consequently, Styles can supplement, but cannot replace, modifiers.
|
||||
- Styles are limited to visual configuration (backgrounds, padding, borders). They cannot handle behaviors like click logic, gesture detection, or accessibility semantics.
|
||||
- Resolving a Style into its final state is *more expensive than applying a single modifier*. The system must generate a data structure containing all possible property values, and the lookup of inherited properties further complicates this.
|
||||
- Resolving a Style into its final state is *more expensive than applying a
|
||||
single modifier*. The system must generate a data structure containing all possible property values, and the lookup of inherited properties further complicates this.
|
||||
|
||||
## When to use Styles over modifiers
|
||||
|
||||
While the choice to use Styles is largely dependent on your app and use cases, the following guidance helps determine when to prefer a style over a modifier:
|
||||
While the choice to use Styles is largely dependent on your app and use cases,
|
||||
the following guidance helps determine when to prefer a style over a modifier:
|
||||
|
||||
- **To achieve theme-wide consistency:** Styles are designed to be "lifted" into a global theme. Instead of passing repetitive Modifiers to every component, you can define a single Style in your theme to create a unified look across the entire app.
|
||||
- **When performing frequent animations:** Styles evaluate during the Layout and Draw phases, allowing properties like color or scale to animate while bypassing the Composition phase entirely. This significantly reduces performance overhead. Use a Style instead of a modifier when doing visual property animations.
|
||||
|
||||
+46
-21
@@ -1,7 +1,8 @@
|
||||
> [!NOTE]
|
||||
> **Note:** Styles are `@Experimental` and likely to change in upcoming releases, with Material support for Styles added in future releases. If you have any feedback, [file Styles issues](https://issuetracker.google.com/issues/new?component=612128).
|
||||
|
||||
There are several ways you can build out your apps using Styles. What you choose depends on where your app sits in relation to its adoption of Material Design:
|
||||
There are several ways you can build out your apps using Styles. What you choose
|
||||
depends on where your app sits in relation to its adoption of Material Design:
|
||||
|
||||
1. Fully custom design system, not using Material Design
|
||||
- **Recommendation**: Define component styles that consume values from the theme, and expose style parameters on design system components.
|
||||
@@ -10,9 +11,15 @@ There are several ways you can build out your apps using Styles. What you choose
|
||||
|
||||
## The Style layer
|
||||
|
||||
In the traditional Compose model, customization often relies heavily on overriding global tokens (colors and typography) provided by `MaterialTheme`, or wrapping and overriding properties of a design system composable where possible. Sometimes, there are properties within the Material layer that are not exposed through the subsystems or parameters, but are hardcoded defaults on the component itself.
|
||||
In the traditional Compose model, customization often relies heavily on
|
||||
overriding global tokens (colors and typography) provided by `MaterialTheme`, or
|
||||
wrapping and overriding properties of a design system composable where possible.
|
||||
Sometimes, there are properties within the Material layer that are not exposed
|
||||
through the subsystems or parameters, but are hardcoded defaults on the
|
||||
component itself.
|
||||
|
||||
With the Styles API, there's a new layer of abstraction that's a bridge between subsystems and components: **Styles**.
|
||||
With the Styles API, there's a new layer of abstraction that's a bridge between
|
||||
subsystems and components: **Styles**.
|
||||
|
||||
| Layer | Responsibility | Example |
|
||||
|---|---|---|
|
||||
@@ -25,9 +32,11 @@ With the Styles API, there's a new layer of abstraction that's a bridge between
|
||||
|
||||
### Atomic versus monolithic Styles
|
||||
|
||||
With the Styles API, you can break down a Style into separate atomic styles. Instead of defining complex, component-specific styles like `baseButtonStyle`, you can also create small, single-purpose utility styles. These act as your "atoms".
|
||||
With the Styles API, you can break down a Style into separate atomic styles.
|
||||
Instead of defining complex, component-specific styles like `baseButtonStyle`,
|
||||
you can also create small, single-purpose utility styles. These act as your
|
||||
"atoms".
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
// Define single-purpose "atomic" styles
|
||||
@@ -60,18 +69,19 @@ val interactiveShadowAtomic = Style {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
#### Composition using "then"
|
||||
|
||||
One of the powerful features of the new Styles API is the `then` operator, which lets you merge multiple `Style` objects. This lets you build a component using atomic utility classes.
|
||||
One of the powerful features of the new Styles API is the `then` operator, which
|
||||
lets you merge multiple `Style` objects. This lets you build a component using
|
||||
atomic utility classes.
|
||||
|
||||
**Traditional (non-atomic)**:
|
||||
|
||||
|
||||
```kotlin
|
||||
// One large monolithic style
|
||||
val buttonStyle = Style {
|
||||
@@ -79,39 +89,49 @@ val buttonStyle = Style {
|
||||
shape(RoundedCornerShape(8.dp))
|
||||
background(Color.Blue)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
**Atomic refactor**:
|
||||
|
||||
|
||||
```kotlin
|
||||
// Combine atoms to create the final appearance
|
||||
val buttonStyle = paddingAtomic then roundedCornerShapeAtomic then primaryBackgroundAtomic then interactiveShadowAtomic
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Adopt Styles in your design system
|
||||
|
||||
Consider the following options when adopting Styles within your design system, depending on where in the spectrum your design system lies.
|
||||
Consider the following options when adopting Styles within your design system,
|
||||
depending on where in the spectrum your design system lies.
|
||||
|
||||
### Custom design system with Styles
|
||||
|
||||
***Consider when**: You've been handed an extensive brand guide that is not based on Material Design, and you are not planning to use Material Design*.
|
||||
***Consider when**: You've been handed an extensive brand guide that is not
|
||||
based on Material Design, and you are not planning to use Material Design*.
|
||||
|
||||
***Strategy**: Implement a fully custom design system, and expose styles as part of the theme*.
|
||||
***Strategy**: Implement a fully custom design system, and expose styles as part
|
||||
of the theme*.
|
||||
|
||||
This option is the custom path if you don't use Material as your main design system language. You bypass `MaterialTheme` entirely for visual definitions and have created your [own custom theme already](https://developer.android.com/develop/ui/compose/designsystems/custom#implementing-fully-custom). You build a `CompanyTheme` that acts as a container for your Styles.
|
||||
This option is the custom path if you don't use Material as your main design
|
||||
system language. You bypass `MaterialTheme` entirely for visual definitions and
|
||||
have created your [own custom theme already](https://developer.android.com/develop/ui/compose/designsystems/custom#implementing-fully-custom). You build a `CompanyTheme` that
|
||||
acts as a container for your Styles.
|
||||
|
||||
- **How it works** : Create a `CompanyTheme` object that holds `Style` objects for every component in your system. Your components (either wrappers around Material logic or custom `Box` or `Layout` implementations) consume these styles directly, and expose a `Style` parameter for consumers of your design system.
|
||||
- **The Style layer**: Styles are the primary definition of your design system. Tokens are named variables fed into these styles. This allows for deep customization, such as defining unique animations for state changes (for example, animating scale and color on press).
|
||||
|
||||
If you are building out your own [custom theme](https://developer.android.com/develop/ui/compose/designsystems/custom) without using Material, and want to adopt styles, add your list of styles to your Theme. This lets you access your base styles from anywhere in your project.
|
||||
If you are building out your own [custom theme](https://developer.android.com/develop/ui/compose/designsystems/custom) without using Material, and
|
||||
want to adopt styles, add your list of styles to your Theme. This lets you
|
||||
access your base styles from anywhere in your project.
|
||||
|
||||
1. Create a `Styles` class that stores the various styles in your application
|
||||
and create the defaults. For example, in the Jetsnack app - the class is
|
||||
named `JetsnackStyles`:
|
||||
|
||||
1. Create a `Styles` class that stores the various styles in your application and create the defaults. For example, in the Jetsnack app - the class is named `JetsnackStyles`:
|
||||
|
||||
```kotlin
|
||||
object JetsnackStyles{
|
||||
@@ -134,12 +154,13 @@ If you are building out your own [custom theme](https://developer.android.com/de
|
||||
contentColor(colors.textPrimary)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
2. Provide `Styles` as part of your overall theme, and expose helper extension functions on `StyleScope` to access the subsystems:
|
||||
2. Provide `Styles` as part of your overall theme, and expose helper extension
|
||||
functions on `StyleScope` to access the subsystems:
|
||||
|
||||
|
||||
```kotlin
|
||||
@Immutable
|
||||
@@ -194,13 +215,13 @@ If you are building out your own [custom theme](https://developer.android.com/de
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
3. Access `JetsnackStyles` within your composable:
|
||||
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
fun CustomButton(modifier: Modifier,
|
||||
@@ -224,9 +245,13 @@ If you are building out your own [custom theme](https://developer.android.com/de
|
||||
Text(text)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Beyond global theme adoption, there are alternative strategies for incorporating `Styles` into your apps. You can leverage `Styles` inline for specific call sites or use static definitions when full theming capabilities are unnecessary. `Styles` shouldn't be swapped conditionally unless the whole style is fundamentally different. You should prefer accessing dynamic tokens inside a visual definition rather than switching between distinct style objects.
|
||||
Beyond global theme adoption, there are alternative strategies for incorporating
|
||||
`Styles` into your apps. You can leverage `Styles` inline for specific call
|
||||
sites or use static definitions when full theming capabilities are unnecessary.
|
||||
`Styles` shouldn't be swapped conditionally unless the whole style is
|
||||
fundamentally different. You should prefer accessing dynamic tokens inside a
|
||||
visual definition rather than switching between distinct style objects.
|
||||
@@ -8,7 +8,7 @@ description: Implements Google Cast support in Android apps using Jetpack Media3
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-14'
|
||||
keywords:
|
||||
- Android
|
||||
- Media3
|
||||
@@ -42,9 +42,10 @@ metadata:
|
||||
|
||||
To complete this step, you **MUST** ensure the following:
|
||||
|
||||
- In the app-level build file, declare the `media3-cast` dependency version 1.9.0 or higher.
|
||||
- In the app-level build file, declare the `media3-cast` dependency version
|
||||
1.9.0 or higher.
|
||||
|
||||
implementation("androidx.media3:media3-cast:1.10.1")
|
||||
implementation("androidx.media3:media3-cast:1.11.0")
|
||||
|
||||
- Ensure required Media3 dependencies are present:
|
||||
|
||||
@@ -55,7 +56,9 @@ To complete this step, you **MUST** ensure the following:
|
||||
|
||||
- Enforce the same versions across all Media3 dependencies.
|
||||
|
||||
- Use configurations in "Add build dependencies" section of [Getting started with CastPlayer](references/android/media/media3/cast/create-castplayer.md) as the source of truth.
|
||||
- Use configurations in "Add build dependencies" section of [Getting started
|
||||
with CastPlayer](references/android/media/media3/cast/create-castplayer.md) as the source of
|
||||
truth.
|
||||
|
||||
- **For apps without an existing Cast integration:**
|
||||
|
||||
@@ -70,7 +73,8 @@ To complete this step, you **MUST** ensure the following:
|
||||
To complete this step, you **MUST** ensure the following:
|
||||
|
||||
- Inside the manifest's `<application>` tag, declare the Cast options provider.
|
||||
- Use `DefaultCastOptionsProvider` by default. See the "OptionsProvider" section in [Getting started with CastPlayer](references/android/media/media3/cast/create-castplayer.md).
|
||||
- Use `DefaultCastOptionsProvider` by default. See the "OptionsProvider" section in [Getting started with
|
||||
CastPlayer](references/android/media/media3/cast/create-castplayer.md).
|
||||
- Declare a custom `OptionsProvider` only if explicitly requested. See [Customize CastOptions](references/android/media/media3/cast/customize-castoptions.md).
|
||||
- Ensure `INTERNET` permission is present. Don't add any unnecessary permissions.
|
||||
- **If Migrating from Legacy Cast SDK:**
|
||||
@@ -88,7 +92,8 @@ Before integrating Media3 Cast, an existing app follows one of two setups:
|
||||
To complete this step, you **MUST** ensure the following:
|
||||
|
||||
- Inside the application's `MediaSessionService` (or `MediaLibraryService`) `onCreate()` method, initialize `ExoPlayer` and `CastPlayer`.
|
||||
- Use `CastPlayer` by default unless `RemoteCastPlayer` is explicitly requested. See the "Build a CastPlayer" section in [Getting started with CastPlayer](references/android/media/media3/cast/create-castplayer.md).
|
||||
- Use `CastPlayer` by default unless `RemoteCastPlayer` is explicitly requested. See the "Build a CastPlayer" section in [Getting started with
|
||||
CastPlayer](references/android/media/media3/cast/create-castplayer.md).
|
||||
- For `CastPlayer`, pass the instance directly to `MediaSession.Builder`.
|
||||
- Replace all legacy forwarding player wrappers.
|
||||
- Don't delete legacy class files yet to prevent compilation errors during migration.
|
||||
@@ -151,8 +156,10 @@ To complete this step, you **MUST** ensure the following:
|
||||
- Use the [`MediaRouteButton` composable](https://developer.android.com/reference/kotlin/androidx/media3/cast/MediaRouteButton.composable) from `androidx.media3.cast` package.
|
||||
- Don't use `AndroidView` in the Compose UI hierarchy.
|
||||
- Place `MediaRouteButton` in an area next to playback controls. Don't hide it behind system UI.
|
||||
- Don't use `PlayerSurface` for custom player UI. Use the Material3 [`Player` composable](https://developer.android.com/reference/kotlin/androidx/media3/ui/compose/material3/Player.composable).
|
||||
- Force recomposition on playback location shifts to ensure UI sync. Use key constraints on `DeviceInfo` changes:
|
||||
- Don't use `PlayerSurface` for custom player UI. Use the Material3 [`Player`
|
||||
composable](https://developer.android.com/reference/kotlin/androidx/media3/ui/compose/material3/Player.composable).
|
||||
- Force recomposition on playback location shifts to ensure UI sync. Use key
|
||||
constraints on `DeviceInfo` changes:
|
||||
|
||||
@OptIn(UnstableApi::class)
|
||||
@Composable
|
||||
@@ -188,11 +195,13 @@ To complete this step, you **MUST** ensure the following:
|
||||
|
||||
To complete this step, you **MUST** ensure the following:
|
||||
|
||||
- For View-based UI setups, see the "Add UI elements" section in [Getting started with CastPlayer](references/android/media/media3/cast/create-castplayer.md).
|
||||
- For View-based UI setups, see the "Add UI elements" section in [Getting
|
||||
started with CastPlayer](references/android/media/media3/cast/create-castplayer.md).
|
||||
- Casting Activities must extend `AppCompatActivity` or `FragmentActivity` and use a `Theme.AppCompat` descendant.
|
||||
- Ensure the `AppCompat` theme has a visible `ActionBar` if adding `MediaRouteButton` to the options menu.
|
||||
- Replace all instances and imports of `CastButtonFactory` with `MediaRouteButtonFactory`.
|
||||
- Rebind `PlayerView.player` references upon `onDeviceInfoChanged` events to prevent black screens or UI freezes:
|
||||
- Rebind `PlayerView.player` references upon `onDeviceInfoChanged` events to
|
||||
prevent black screens or UI freezes:
|
||||
|
||||
private val playerListener: Player.Listener =
|
||||
object : Player.Listener {
|
||||
|
||||
+67
-44
@@ -1,36 +1,48 @@
|
||||
The [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) is a Jetpack Media3 [Player](https://developer.android.com/reference/kotlin/androidx/media3/common/Player) implementation that supports both local playback and casting to a remote Cast-enabled device. [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) simplifies adding cast functionality to your app and provides rich features to seamlessly switch between local and remote playback. This guide shows you how to integrate [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) into your media app.
|
||||
The [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) is a Jetpack Media3 [Player](https://developer.android.com/reference/kotlin/androidx/media3/common/Player) implementation that supports
|
||||
both local playback and casting to a remote Cast-enabled device. [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer)
|
||||
simplifies adding cast functionality to your app and provides rich features to
|
||||
seamlessly switch between local and remote playback. This guide shows you how to
|
||||
integrate [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) into your media app.
|
||||
|
||||
To integrate Cast with other platforms, see the [Cast SDK](https://developers.google.com/cast/docs/developers).
|
||||
|
||||
## Get a Cast-enabled device
|
||||
|
||||
To test `CastPlayer`, you need a [Cast-enabled device](https://store.google.com/gb/category/connected_home?hl=en-GB). Choices include Android TV, Chromecast, smart speakers, and smart displays. Verify that your device is set up and connected to the same Wi-Fi network as your development mobile for discovery.
|
||||
To test `CastPlayer`, you need a [Cast-enabled device](https://store.google.com/gb/category/connected_home?hl=en-GB). Choices include Android
|
||||
TV, Chromecast, smart speakers, and smart displays. Verify that your device is
|
||||
set up and connected to the same Wi-Fi network as your development mobile for
|
||||
discovery.
|
||||
|
||||
## Add build dependencies
|
||||
|
||||
To start using `CastPlayer`, add the AndroidX Media3 and `CastPlayer` dependencies to the `build.gradle` file of your app module.
|
||||
To start using `CastPlayer`, add the AndroidX Media3 and `CastPlayer`
|
||||
dependencies to the `build.gradle` file of your app module.
|
||||
|
||||
### Kotlin
|
||||
|
||||
implementation("androidx.media3:media3-exoplayer:1.10.1")
|
||||
implementation("androidx.media3:media3-ui:1.10.1")
|
||||
implementation("androidx.media3:media3-session:1.10.1")
|
||||
implementation("androidx.media3:media3-cast:1.10.1")
|
||||
implementation("androidx.media3:media3-exoplayer:1.11.0")
|
||||
implementation("androidx.media3:media3-ui:1.11.0")
|
||||
implementation("androidx.media3:media3-session:1.11.0")
|
||||
implementation("androidx.media3:media3-cast:1.11.0")
|
||||
|
||||
### Groovy
|
||||
|
||||
implementation "androidx.media3:media3-exoplayer:1.10.1"
|
||||
implementation "androidx.media3:media3-ui:1.10.1"
|
||||
implementation "androidx.media3:media3-session:1.10.1"
|
||||
implementation "androidx.media3:media3-cast:1.10.1"
|
||||
implementation "androidx.media3:media3-exoplayer:1.11.0"
|
||||
implementation "androidx.media3:media3-ui:1.11.0"
|
||||
implementation "androidx.media3:media3-session:1.11.0"
|
||||
implementation "androidx.media3:media3-cast:1.11.0"
|
||||
|
||||
## Configure your CastPlayer
|
||||
|
||||
To configure the [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer), update your `AndroidManifest.xml` file with an options provider.
|
||||
To configure the [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer), update your `AndroidManifest.xml` file with an
|
||||
options provider.
|
||||
|
||||
### Options provider
|
||||
|
||||
The [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) requires an options provider to configure its behavior. For a basic setup, you can use the [`DefaultCastOptionsProvider`](https://developer.android.com/reference/androidx/media3/cast/DefaultCastOptionsProvider) by adding it to your `AndroidManifest.xml` file. This uses default settings, including the default receiver application.
|
||||
The [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) requires an options provider to configure its behavior. For a
|
||||
basic setup, you can use the [`DefaultCastOptionsProvider`](https://developer.android.com/reference/androidx/media3/cast/DefaultCastOptionsProvider) by adding it to your
|
||||
`AndroidManifest.xml` file. This uses default settings, including the default
|
||||
receiver application.
|
||||
|
||||
<application>
|
||||
...
|
||||
@@ -40,11 +52,15 @@ The [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/
|
||||
...
|
||||
</application>
|
||||
|
||||
To customize the configuration, implement your own custom `OptionsProvider`. See the [CastOptions](https://developer.android.com/media/media3/cast/customize-castoptions) guide to learn how.
|
||||
To customize the configuration, implement your own custom `OptionsProvider`. See
|
||||
the [CastOptions](https://developer.android.com/media/media3/cast/customize-castoptions) guide to learn how.
|
||||
|
||||
### Add a receiver for media transfers
|
||||
|
||||
Adding a `MediaTransferReceiver` to your manifest enables the System UI to discover Cast-enabled devices on the network and reroute media without opening the app activity. For example, a user can change the device playing your app's media from the [media notification](https://developer.android.com/media/implement/surfaces/mobile).
|
||||
Adding a `MediaTransferReceiver` to your manifest enables the System UI to
|
||||
discover Cast-enabled devices on the network and reroute media without opening
|
||||
the app activity. For example, a user can change the device playing your app's
|
||||
media from the [media notification](https://developer.android.com/media/implement/surfaces/mobile).
|
||||
|
||||
<application>
|
||||
...
|
||||
@@ -54,10 +70,19 @@ Adding a `MediaTransferReceiver` to your manifest enables the System UI to disco
|
||||
|
||||
## Build a CastPlayer
|
||||
|
||||
For remote playback with Cast, your app should be able to manage playback even when the user isn't interacting with an Activity from your app, such as through the system media notification. For this reason, you should create your `ExoPlayer` (for local playback) and `CastPlayer` (for remote playback) instances in a service, such as [MediaSessionService](https://developer.android.com/media/media3/session/background-playback#service-lifecycle) or [MediaLibraryService](https://developer.android.com/guide/topics/media/session/medialibraryservice). First, create your `ExoPlayer` instance and then when building your [`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) instance, set `ExoPlayer` as the local player instance. You can then switch media playback between your mobile and the Cast-enabled device from the media notification or the lock screen notification. Media3 uses the **Output Switcher** feature to handle player transfers when the output route changes from local to remote or from remote to local.
|
||||
For remote playback with Cast, your app should be able to manage playback even
|
||||
when the user isn't interacting with an Activity from your app, such as through
|
||||
the system media notification. For this reason, you should create your
|
||||
`ExoPlayer` (for local playback) and `CastPlayer` (for remote playback)
|
||||
instances in a service, such as [MediaSessionService](https://developer.android.com/media/media3/session/background-playback#service-lifecycle) or [MediaLibraryService](https://developer.android.com/guide/topics/media/session/medialibraryservice).
|
||||
First, create your `ExoPlayer` instance and then when building your
|
||||
[`CastPlayer`](https://developer.android.com/reference/androidx/media3/cast/CastPlayer) instance, set `ExoPlayer` as the local player instance. You can
|
||||
then switch media playback between your mobile and the Cast-enabled device from
|
||||
the media notification or the lock screen notification. Media3 uses the **Output
|
||||
Switcher** feature to handle player transfers when the output route changes from
|
||||
local to remote or from remote to local.
|
||||
 Figure 1: (a) Device chip on Media notification (b) Cast-enabled devices shown on tapping the device chip (c) Device chip on Lock screen notification
|
||||
|
||||
<br />
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -70,8 +95,6 @@ override fun onCreate() {
|
||||
|
||||
mediaSession = MediaSession.Builder(context, castPlayer).build()
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
### Java
|
||||
@@ -87,8 +110,6 @@ public void onCreate() {
|
||||
mediaSession =
|
||||
new MediaSession.Builder(/* context= */ context, /* player= */ castPlayer).build();
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -98,11 +119,17 @@ public void onCreate() {
|
||||
|
||||
## Add UI elements
|
||||
|
||||
Add a [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) to your app's UI. Tapping the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) opens a dialog displaying a list of available Cast-enabled devices on the network. When the user selects a device, the media playback is transferred from the mobile to the selected receiver device. This section shows you how to add the button and listen for events to update your UI when playback switches between local and remote devices.
|
||||
Add a [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) to your app's UI. Tapping the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton)
|
||||
opens a dialog displaying a list of available Cast-enabled devices on the
|
||||
network. When the user selects a device, the media playback is transferred from
|
||||
the mobile to the selected receiver device. This section shows you how to add
|
||||
the button and listen for events to update your UI when playback switches
|
||||
between local and remote devices.
|
||||
|
||||
### Set the MediaRouteButton
|
||||
|
||||
There are four ways to add the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) to your activity's UI. The best choice depends on your app's design and requirements.
|
||||
There are four ways to add the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) to your activity's UI. The
|
||||
best choice depends on your app's design and requirements.
|
||||
|
||||
- **Compose UI**: Add a button composable.
|
||||
- **Views UI** :
|
||||
@@ -120,9 +147,9 @@ There are four ways to add the [`MediaRouteButton`](https://developer.android.co
|
||||
|
||||
#### Add a Composable `MediaRouteButton` to the Player
|
||||
|
||||
You can add the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) Composable to your player's UI. For more information, see the [Compose](https://developer.android.com/media/media3/ui/compose) guide.
|
||||
You can add the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) Composable to your player's UI. For more
|
||||
information, see the [Compose](https://developer.android.com/media/media3/ui/compose) guide.
|
||||
|
||||
<br />
|
||||
|
||||
```kotlin
|
||||
@Composable
|
||||
@@ -147,17 +174,17 @@ fun PlayerComposeView(player: Player, modifier: Modifier = Modifier) {
|
||||
fun PrimaryControls(player: Player, modifier: Modifier = Modifier) {
|
||||
// ...
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
#### Add the `MediaRouteButton` to the PlayerView
|
||||
|
||||
You can add the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) directly within the [PlayerView](https://developer.android.com/guide/topics/media/ui/playerview)'s UI controls. After setting the [MediaController](https://developer.android.com/guide/topics/media/session/mediacontroller) as the player for your `PlayerView`, provide a `MediaRouteButtonViewProvider` to display the Cast button on the Player.
|
||||
You can add the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) directly within the [PlayerView](https://developer.android.com/guide/topics/media/ui/playerview)'s UI
|
||||
controls. After setting the [MediaController](https://developer.android.com/guide/topics/media/session/mediacontroller) as the player for your
|
||||
`PlayerView`, provide a `MediaRouteButtonViewProvider` to display the Cast
|
||||
button on the Player.
|
||||
|
||||
<br />
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -168,7 +195,6 @@ override fun onStart() {
|
||||
playerView.player = mediaController
|
||||
playerView.setMediaRouteButtonViewProvider(MediaRouteButtonViewProvider())
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Java
|
||||
@@ -181,14 +207,14 @@ public void onStart() {
|
||||
playerView.setPlayer(mediaController);
|
||||
playerView.setMediaRouteButtonViewProvider(new MediaRouteButtonViewProvider());
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
#### Add the `MediaRouteButton` to the app bar menu
|
||||
|
||||
To set up a [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) in the app bar menu, create an XML menu and override `onCreateOptionsMenu` in your `Activity`.
|
||||
To set up a [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton) in the app bar menu, create an XML menu and
|
||||
override `onCreateOptionsMenu` in your `Activity`.
|
||||
|
||||
<menu xmlns:android="http://schemas.android.com/apk/res/android"
|
||||
xmlns:app="http://schemas.android.com/apk/res-auto">
|
||||
@@ -198,7 +224,6 @@ To set up a [`MediaRouteButton`](https://developer.android.com/reference/android
|
||||
app:actionProviderClass="androidx.mediarouter.app.MediaRouteActionProvider"/>
|
||||
</menu>
|
||||
|
||||
<br />
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -224,7 +249,6 @@ override fun onCreateOptionsMenu(menu: Menu): Boolean {
|
||||
// ...
|
||||
return true
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Java
|
||||
@@ -253,7 +277,6 @@ public boolean onCreateOptionsMenu(Menu menu) {
|
||||
// ...
|
||||
return true;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -268,9 +291,9 @@ You can set up a [`MediaRouteButton`](https://developer.android.com/reference/an
|
||||
android:layout_height="wrap_content"
|
||||
app:mediaRouteButtonTint="@android:color/white" />
|
||||
|
||||
To complete the setup for the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton), use the Media3 Cast `MediaRouteButtonFactory` in your `Activity` code.
|
||||
To complete the setup for the [`MediaRouteButton`](https://developer.android.com/reference/androidx/mediarouter/app/MediaRouteButton), use the Media3 Cast
|
||||
`MediaRouteButtonFactory` in your `Activity` code.
|
||||
|
||||
<br />
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -282,7 +305,6 @@ override fun onCreate(savedInstanceState: Bundle?) {
|
||||
val unused = MediaRouteButtonFactory.setUpMediaRouteButton(context, it)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Java
|
||||
@@ -296,16 +318,18 @@ public void onCreate(Bundle savedInstanceState) {
|
||||
ListenableFuture<Void> setUpFuture =
|
||||
MediaRouteButtonFactory.setUpMediaRouteButton(context, button);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Activity Listener
|
||||
|
||||
Create a `Player.Listener` in your `Activity` to listen for changes to media playback location. When the `playbackType` changes between `PLAYBACK_TYPE_LOCAL` and `PLAYBACK_TYPE_REMOTE`, you can adjust your UI as needed. To prevent memory leaks and to confine listener activity to only when your app is visible, register the listener in `onStart` and unregister it in `onStop`:
|
||||
Create a `Player.Listener` in your `Activity` to listen for changes to media
|
||||
playback location. When the `playbackType` changes between `PLAYBACK_TYPE_LOCAL`
|
||||
and `PLAYBACK_TYPE_REMOTE`, you can adjust your UI as needed. To prevent memory
|
||||
leaks and to confine listener activity to only when your app is visible,
|
||||
register the listener in `onStart` and unregister it in `onStop`:
|
||||
|
||||
<br />
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -330,7 +354,6 @@ override fun onStop() {
|
||||
super.onStop()
|
||||
mediaController.removeListener(playerListener)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Java
|
||||
@@ -359,9 +382,9 @@ protected void onStop() {
|
||||
super.onStop();
|
||||
mediaController.removeListener(playerListener);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
For more information about listening and responding to playback events, see the [player events](https://developer.android.com/media/media3/exoplayer/listening-to-player-events) guide.
|
||||
For more information about listening and responding to playback events, see the
|
||||
[player events](https://developer.android.com/media/media3/exoplayer/listening-to-player-events) guide.
|
||||
+13
-8
@@ -1,8 +1,11 @@
|
||||
To configure your app's Cast session, provide an [`OptionsProvider`](https://developers.google.com/android/reference/com/google/android/gms/cast/framework/OptionsProvider). Use the [`CastOptions`](https://developers.google.com/android/reference/com/google/android/gms/cast/framework/CastOptions) object built by the provider to set the receiver application ID, manage session lifecycles, and customize media playback behavior.
|
||||
To configure your app's Cast session, provide an [`OptionsProvider`](https://developers.google.com/android/reference/com/google/android/gms/cast/framework/OptionsProvider). Use the
|
||||
[`CastOptions`](https://developers.google.com/android/reference/com/google/android/gms/cast/framework/CastOptions) object built by the provider to set the receiver application ID,
|
||||
manage session lifecycles, and customize media playback behavior.
|
||||
|
||||
## Use the default options provider
|
||||
|
||||
For a basic setup that uses the default Cast receiver application, add the `DefaultCastOptionsProvider` to your app's `AndroidManifest.xml` file:
|
||||
For a basic setup that uses the default Cast receiver application, add the
|
||||
`DefaultCastOptionsProvider` to your app's `AndroidManifest.xml` file:
|
||||
|
||||
<application>
|
||||
...
|
||||
@@ -14,11 +17,13 @@ For a basic setup that uses the default Cast receiver application, add the `Defa
|
||||
|
||||
## Create a custom options provider
|
||||
|
||||
For more advanced configurations, such as setting a custom receiver application ID, you need to create your own `OptionsProvider`.
|
||||
For more advanced configurations, such as setting a custom receiver application
|
||||
ID, you need to create your own `OptionsProvider`.
|
||||
|
||||
### 1. Declare the provider in your manifest
|
||||
|
||||
First, declare your custom provider in `AndroidManifest.xml`. Make sure to use the fully qualified class name.
|
||||
First, declare your custom provider in `AndroidManifest.xml`. Make sure to use
|
||||
the fully qualified class name.
|
||||
|
||||
<application>
|
||||
...
|
||||
@@ -30,11 +35,13 @@ First, declare your custom provider in `AndroidManifest.xml`. Make sure to use t
|
||||
|
||||
### 2. Implement the OptionsProvider interface
|
||||
|
||||
Next, create a class that implements the `OptionsProvider` interface. In this class, you must override `getCastOptions()` to return a `CastOptions` instance. The custom `OptionsProvider` class is where you configure your Cast session, for example, by setting your custom receiver application ID.
|
||||
Next, create a class that implements the `OptionsProvider` interface. In this
|
||||
class, you must override `getCastOptions()` to return a `CastOptions` instance.
|
||||
The custom `OptionsProvider` class is where you configure your Cast session, for
|
||||
example, by setting your custom receiver application ID.
|
||||
|
||||
For more information, see [CastOptions.Builder](https://developers.google.com/android/reference/com/google/android/gms/cast/framework/CastOptions.Builder).
|
||||
|
||||
<br />
|
||||
|
||||
### Kotlin
|
||||
|
||||
@@ -57,7 +64,6 @@ class MyCustomCastOptionsProvider : OptionsProvider {
|
||||
private const val APP_ID = "<APP_ID>"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Java
|
||||
@@ -82,7 +88,6 @@ public static final class MyCustomCastOptionsProvider implements OptionsProvider
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<br />
|
||||
@@ -1,13 +1,21 @@
|
||||
The Media3 [`cast`](https://developer.android.com/reference/androidx/media3/cast/package-summary) module extends your media playback experience to Cast devices. It lets your app cast content to [compatible devices](https://developer.android.com/media/media3/cast/create-castplayer#get-device), such as TVs and speakers. The [sender](https://developers.google.com/cast/glossary#sender) app acts as a remote controller for media playback on the [receiver](https://developers.google.com/cast/glossary#receiver) device. This module integrates with the [Jetpack Media3](https://developer.android.com/guide/topics/media/media3) library, so you can use the same `Player` interface and UI components for both local and remote playback.
|
||||
The Media3 [`cast`](https://developer.android.com/reference/androidx/media3/cast/package-summary) module extends your media playback experience to
|
||||
Cast devices. It lets your app cast content to [compatible devices](https://developer.android.com/media/media3/cast/create-castplayer#get-device),
|
||||
such as TVs and speakers. The [sender](https://developers.google.com/cast/glossary#sender) app acts as a remote controller for media
|
||||
playback on the [receiver](https://developers.google.com/cast/glossary#receiver) device. This module integrates with the [Jetpack
|
||||
Media3](https://developer.android.com/guide/topics/media/media3) library, so you can use the same `Player` interface and UI
|
||||
components for both local and remote playback.
|
||||
|
||||
## Media3 CastPlayer
|
||||
|
||||
The `CastPlayer` is a media player API included in Media3 that supports both local and remote media playback. It implements the `Player` interface to manage playback, simplifying the integration of casting into your media experience.
|
||||
The `CastPlayer` is a media player API included in Media3 that supports both
|
||||
local and remote media playback. It implements the `Player` interface to manage
|
||||
playback, simplifying the integration of casting into your media experience.
|
||||
|
||||
[Go to Media3 CastPlayer](https://developer.android.com/media/media3/cast/create-castplayer)
|
||||
|
||||
## Other Cast integrations
|
||||
|
||||
The Cast SDK overview explains how to integrate Cast with other platforms, such as building a receiver app or integrating with the web sender SDK.
|
||||
The Cast SDK overview explains how to integrate Cast with other platforms, such
|
||||
as building a receiver app or integrating with the web sender SDK.
|
||||
|
||||
[Explore Cast SDK](https://developers.google.com/cast/docs/developers)
|
||||
@@ -8,7 +8,7 @@ description: Learn how to install and migrate to Jetpack Navigation 3, and how t
|
||||
license: Complete terms in LICENSE.txt
|
||||
metadata:
|
||||
author: Google LLC
|
||||
last-updated: '2026-08-06'
|
||||
last-updated: '2026-08-14'
|
||||
keywords:
|
||||
- recipe
|
||||
- Android
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
<br />
|
||||
|
||||
## Android skills
|
||||
|
||||
[View on GitHub](https://github.com/android/skills/tree/main/navigation/navigation-3)
|
||||
@@ -12,7 +10,10 @@ Use an Android skill to help you build using Jetpack Navigation 3. To install th
|
||||
|
||||
<br />
|
||||
|
||||
Navigation 3 is a new navigation library designed to work with Compose. With Navigation 3, you have full control over your back stack, and navigating to and from destinations is as simple as adding and removing items from a list. It creates a flexible app navigation system by providing:
|
||||
Navigation 3 is a new navigation library designed to work with Compose. With
|
||||
Navigation 3, you have full control over your back stack, and navigating to and
|
||||
from destinations is as simple as adding and removing items from a list. It
|
||||
creates a flexible app navigation system by providing:
|
||||
|
||||
- Conventions for modeling a back stack, where each entry on the back stack represents content that the user has navigated to
|
||||
- A UI that automatically updates with back stack changes (including animations)
|
||||
@@ -22,23 +23,28 @@ Navigation 3 is a new navigation library designed to work with Compose. With Nav
|
||||
|
||||
At a high level, you implement Navigation 3 in the following ways:
|
||||
|
||||
1. Define the content that users can navigate to in your app, each with a unique key, and add a function to resolve that key to the content. See [Resolve keys to content](https://developer.android.com/guide/navigation/navigation-3/basics#resolve-keys).
|
||||
1. Define the content that users can navigate to in your app, each with a unique key, and add a function to resolve that key to the content. See [Resolve keys
|
||||
to content](https://developer.android.com/guide/navigation/navigation-3/basics#resolve-keys).
|
||||
2. Create a back stack that keys are pushed onto and removed as users navigate your app. See [Create a back stack](https://developer.android.com/guide/navigation/navigation-3/basics#create-back).
|
||||
3. Use a [`NavDisplay`](https://developer.android.com/reference/kotlin/androidx/navigation3/ui/NavDisplay.composable) to display your app's back stack. Whenever the back stack changes, it updates the UI to display relevant content. See [Display the back stack](https://developer.android.com/guide/navigation/navigation-3/basics#display-back).
|
||||
3. Use a [`NavDisplay`](https://developer.android.com/reference/kotlin/androidx/navigation3/ui/NavDisplay.composable) to display your app's back stack. Whenever the back stack changes, it updates the UI to display relevant content. See [Display
|
||||
the back stack](https://developer.android.com/guide/navigation/navigation-3/basics#display-back).
|
||||
4. Modify `NavDisplay`'s [scene strategies](https://developer.android.com/guide/navigation/navigation-3/custom-layouts) as needed to support adaptive layouts and different platforms.
|
||||
|
||||
You can see the [full source code](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigation3/) for Navigation 3 on AOSP.
|
||||
|
||||
## Improvements upon Jetpack Navigation
|
||||
|
||||
Navigation 3 improves upon the original Jetpack Navigation API in the following ways:
|
||||
Navigation 3 improves upon the original Jetpack Navigation API in the following
|
||||
ways:
|
||||
|
||||
- Provides a simpler integration with Compose
|
||||
- Offers you full control of the back stack
|
||||
- Makes it possible to create layouts that can read more than one destination from the back stack at the same time, allowing them to adapt to changes in window size and other inputs.
|
||||
|
||||
Read more about Navigation 3's principles and API design choices in [this blog post](https://android-developers.googleblog.com/2025/05/announcing-jetpack-navigation-3-for-compose.html).
|
||||
Read more about Navigation 3's principles and API design choices in [this blog
|
||||
post](https://android-developers.googleblog.com/2025/05/announcing-jetpack-navigation-3-for-compose.html).
|
||||
|
||||
## Code samples
|
||||
|
||||
The [recipes repository](https://github.com/android/nav3-recipes) contains examples of how to use the Navigation 3 building blocks to solve common navigation challenges.
|
||||
The [recipes repository](https://github.com/android/nav3-recipes) contains examples of how to use the
|
||||
Navigation 3 building blocks to solve common navigation challenges.
|
||||
+327
-203
@@ -1,5 +1,3 @@
|
||||
<br />
|
||||
|
||||
## Android skills
|
||||
|
||||
[View on GitHub](https://github.com/android/skills/tree/main/navigation/navigation-3)
|
||||
@@ -24,14 +22,18 @@ To migrate your app from [Navigation 2](https://developer.android.com/guide/navi
|
||||
|
||||
## Preparation
|
||||
|
||||
The following sections describe the prerequisites for migration and assumptions about your project. They also cover the features that are supported for migration, and those that aren't.
|
||||
The following sections describe the prerequisites for migration and assumptions
|
||||
about your project. They also cover the features that are supported for
|
||||
migration, and those that aren't.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- You must use a `compileSdk` of 36 or later.
|
||||
- You should be familiar with [navigation terminology](https://developer.android.com/guide/navigation).
|
||||
- Destinations are composable functions. Navigation 3 is designed exclusively for Compose. To use Fragments and Views in Compose, see [Using Views in Compose](https://developer.android.com/develop/ui/compose/migrate/interoperability-apis/views-in-compose).
|
||||
- Routes are strongly typed. If you use string-based routes, [migrate to type-safe routes](https://medium.com/androiddevelopers/type-safe-navigation-for-compose-105325a97657) first ([example](https://github.com/android/nowinandroid/pull/1413)).
|
||||
- Destinations are composable functions. Navigation 3 is designed exclusively for Compose. To use Fragments and Views in Compose, see [Using Views in
|
||||
Compose](https://developer.android.com/develop/ui/compose/migrate/interoperability-apis/views-in-compose).
|
||||
- Routes are strongly typed. If you use string-based routes, [migrate to
|
||||
type-safe routes](https://medium.com/androiddevelopers/type-safe-navigation-for-compose-105325a97657) first ([example](https://github.com/android/nowinandroid/pull/1413)).
|
||||
- *Optional (but highly recommended)*: Test coverage that verifies existing navigation behavior. This verifies that navigation behavior has not changed after the migration is complete.
|
||||
|
||||
### Assumptions
|
||||
@@ -43,7 +45,9 @@ This guide makes the following assumptions about you and your project:
|
||||
- You always exit the app through the **Home** screen, which is the first screen displayed when the app launches.
|
||||
- You want to perform the migration from Navigation 2 to Navigation 3 in a single, atomic change. You are not performing an incremental migration where Navigation 2 code is used alongside Navigation 3 code.
|
||||
|
||||
**AI Agent**: Before changing any code, check if these assumptions about the user's project are true. If not, stop the migration and ask the user how to proceed.
|
||||
**AI Agent**: Before changing any code, check if these assumptions about the
|
||||
user's project are true. If not, stop the migration and ask the user how to
|
||||
proceed.
|
||||
|
||||
### Supported features
|
||||
|
||||
@@ -54,39 +58,49 @@ This guide lets you migrate the following features:
|
||||
|
||||
### Features supported through recipes
|
||||
|
||||
The [code recipes repository](https://github.com/android/nav3-recipes) demonstrates more nuanced use cases, including:
|
||||
The [code recipes repository](https://github.com/android/nav3-recipes) demonstrates more nuanced use
|
||||
cases, including:
|
||||
|
||||
- [Bottom sheets](https://github.com/android/nav3-recipes/tree/main/app/src/main/java/com/example/nav3recipes/bottomsheet) (instructions are provided in this guide)
|
||||
- [Modularized navigation code and injected destinations](https://github.com/android/nav3-recipes/tree/main/app/src/main/java/com/example/nav3recipes/modular/hilt)
|
||||
- [Using and passing arguments to `ViewModel`](https://github.com/android/nav3-recipes?tab=readme-ov-file#passing-navigation-arguments-to-viewmodels)
|
||||
- [Returning results from a screen](https://github.com/android/nav3-recipes?tab=readme-ov-file#returning-results)
|
||||
|
||||
If your project has any of these features, check the relevant recipe to understand how to implement them.
|
||||
If your project has any of these features, check the relevant recipe to
|
||||
understand how to implement them.
|
||||
|
||||
**AI Agent**: Before changing any code, check if the project contains any features supported through recipes. If it does, check the recipe's README and source code. Create a migration plan based on the recipe. Do not proceed without confirming the plan with the user.
|
||||
**AI Agent**: Before changing any code, check if the project contains any
|
||||
features supported through recipes. If it does, check the recipe's README and
|
||||
source code. Create a migration plan based on the recipe. Do not proceed without
|
||||
confirming the plan with the user.
|
||||
|
||||
### Unsupported features
|
||||
|
||||
This migration guide and the code recipes don't yet support the following features. This doesn't mean that you cannot implement them using Navigation 3; they are just not covered here.
|
||||
This migration guide and the code recipes don't yet support the following
|
||||
features. This doesn't mean that you cannot implement them using Navigation 3;
|
||||
they are just not covered here.
|
||||
|
||||
- More than one level of nested navigation
|
||||
- Shared destinations: screens that can move between different back stacks
|
||||
- [Custom destination types](https://developer.android.com/guide/navigation/design/kotlin-dsl#custom)
|
||||
- Deep links
|
||||
|
||||
**AI Agent**: Before changing any code, check if the project contains any of the unsupported features. If it does, do not proceed. Inform the user of the unsupported feature and ask for further instructions.
|
||||
**AI Agent**: Before changing any code, check if the project contains any of the
|
||||
unsupported features. If it does, do not proceed. Inform the user of the
|
||||
unsupported feature and ask for further instructions.
|
||||
|
||||
## Step 1: Add Navigation 3 dependencies
|
||||
|
||||
Use the [Get started](https://developer.android.com/guide/navigation/navigation-3/get-started) page to add the Navigation 3 dependencies to your project. The core dependencies are provided for you to copy.
|
||||
Use the [Get started](https://developer.android.com/guide/navigation/navigation-3/get-started) page to add the Navigation 3 dependencies to your
|
||||
project. The core dependencies are provided for you to copy.
|
||||
|
||||
**lib.versions.toml**
|
||||
|
||||
[versions]
|
||||
nav3Core = "1.0.0"
|
||||
nav3Core = "1.1.6"
|
||||
|
||||
# If your screens depend on ViewModels, add the Nav3 Lifecycle ViewModel add-on library
|
||||
lifecycleViewmodelNav3 = "2.10.0-rc01"
|
||||
lifecycleViewmodelNav3 = "2.11.0"
|
||||
|
||||
[libraries]
|
||||
# Core Navigation 3 libraries
|
||||
@@ -106,19 +120,32 @@ Use the [Get started](https://developer.android.com/guide/navigation/navigation-
|
||||
implementation(libs.androidx.lifecycle.viewmodel.navigation3)
|
||||
}
|
||||
|
||||
Also update the project's `minSdk` to 23 and the `compileSdk` to 36. You usually find these in `app/build.gradle.kts` or `lib.versions.toml`.
|
||||
Also update the project's `minSdk` to 23 and the `compileSdk` to 36. You usually
|
||||
find these in `app/build.gradle.kts` or `lib.versions.toml`.
|
||||
|
||||
## Step 2: Update navigation routes to implement the `NavKey` interface
|
||||
|
||||
Update every navigation [route](https://developer.android.com/guide/navigation#types) so that it implements the `NavKey` interface. This lets you use `rememberNavBackStack` to assist with [saving your navigation state](https://developer.android.com/guide/navigation/navigation-3/save-state).
|
||||
Update every navigation [route](https://developer.android.com/guide/navigation#types) so that it implements the `NavKey`
|
||||
interface. This lets you use `rememberNavBackStack` to assist with [saving your
|
||||
navigation state](https://developer.android.com/guide/navigation/navigation-3/save-state).
|
||||
|
||||
Before:
|
||||
|
||||
@Serializable data object RouteA
|
||||
|
||||
```kotlin
|
||||
@Serializable data object RouteA
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
After:
|
||||
|
||||
@Serializable data object RouteA : NavKey
|
||||
|
||||
```kotlin
|
||||
@Serializable data object RouteA : NavKey
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
> [!NOTE]
|
||||
> **Note:** The `@Serializable` annotation is provided by the KotlinX Serialization plugin. You can add this by following [these project setup steps](https://developer.android.com/guide/navigation/navigation-3/get-started#project-setup).
|
||||
@@ -127,139 +154,156 @@ After:
|
||||
|
||||
### Step 3.1: Create a navigation state holder
|
||||
|
||||
Copy the following code into a file named `NavigationState.kt`. Add your package name to match your project structure.
|
||||
Copy the following code into a file named `NavigationState.kt`. Add your package
|
||||
name to match your project structure.
|
||||
|
||||
// package com.example.project
|
||||
|
||||
import androidx.compose.runtime.Composable
|
||||
import androidx.compose.runtime.MutableState
|
||||
import androidx.compose.runtime.getValue
|
||||
import androidx.compose.runtime.mutableStateOf
|
||||
import androidx.compose.runtime.remember
|
||||
import androidx.compose.runtime.saveable.rememberSerializable
|
||||
import androidx.compose.runtime.setValue
|
||||
import androidx.compose.runtime.snapshots.SnapshotStateList
|
||||
import androidx.compose.runtime.toMutableStateList
|
||||
import androidx.navigation3.runtime.NavBackStack
|
||||
import androidx.navigation3.runtime.NavEntry
|
||||
import androidx.navigation3.runtime.NavKey
|
||||
import androidx.navigation3.runtime.rememberDecoratedNavEntries
|
||||
import androidx.navigation3.runtime.rememberNavBackStack
|
||||
import androidx.navigation3.runtime.rememberSaveableStateHolderNavEntryDecorator
|
||||
import androidx.navigation3.runtime.serialization.NavKeySerializer
|
||||
import androidx.savedstate.compose.serialization.serializers.MutableStateSerializer
|
||||
```kotlin
|
||||
// package com.example.project
|
||||
|
||||
/**
|
||||
* Create a navigation state that persists config changes and process death.
|
||||
*/
|
||||
@Composable
|
||||
fun rememberNavigationState(
|
||||
startRoute: NavKey,
|
||||
topLevelRoutes: Set<NavKey>
|
||||
): NavigationState {
|
||||
import androidx.compose.runtime.Composable
|
||||
import androidx.compose.runtime.MutableState
|
||||
import androidx.compose.runtime.getValue
|
||||
import androidx.compose.runtime.mutableStateOf
|
||||
import androidx.compose.runtime.remember
|
||||
import androidx.compose.runtime.saveable.rememberSerializable
|
||||
import androidx.compose.runtime.setValue
|
||||
import androidx.compose.runtime.snapshots.SnapshotStateList
|
||||
import androidx.compose.runtime.toMutableStateList
|
||||
import androidx.navigation3.runtime.NavBackStack
|
||||
import androidx.navigation3.runtime.NavEntry
|
||||
import androidx.navigation3.runtime.NavKey
|
||||
import androidx.navigation3.runtime.rememberDecoratedNavEntries
|
||||
import androidx.navigation3.runtime.rememberNavBackStack
|
||||
import androidx.navigation3.runtime.rememberSaveableStateHolderNavEntryDecorator
|
||||
import androidx.navigation3.runtime.serialization.NavKeySerializer
|
||||
import androidx.savedstate.compose.serialization.serializers.MutableStateSerializer
|
||||
|
||||
val topLevelRoute = rememberSerializable(
|
||||
startRoute, topLevelRoutes,
|
||||
serializer = MutableStateSerializer(NavKeySerializer())
|
||||
) {
|
||||
mutableStateOf(startRoute)
|
||||
}
|
||||
/**
|
||||
* Create a navigation state that persists config changes and process death.
|
||||
*/
|
||||
@Composable
|
||||
fun rememberNavigationState(
|
||||
startRoute: NavKey,
|
||||
topLevelRoutes: Set<NavKey>
|
||||
): NavigationState {
|
||||
|
||||
val backStacks = topLevelRoutes.associateWith { key -> rememberNavBackStack(key) }
|
||||
|
||||
return remember(startRoute, topLevelRoutes) {
|
||||
NavigationState(
|
||||
startRoute = startRoute,
|
||||
topLevelRoute = topLevelRoute,
|
||||
backStacks = backStacks
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* State holder for navigation state.
|
||||
*
|
||||
* @param startRoute - the start route. The user will exit the app through this route.
|
||||
* @param topLevelRoute - the current top level route
|
||||
* @param backStacks - the back stacks for each top level route
|
||||
*/
|
||||
class NavigationState(
|
||||
val startRoute: NavKey,
|
||||
topLevelRoute: MutableState<NavKey>,
|
||||
val backStacks: Map<NavKey, NavBackStack<NavKey>>
|
||||
val topLevelRoute = rememberSerializable(
|
||||
startRoute, topLevelRoutes,
|
||||
serializer = MutableStateSerializer(NavKeySerializer())
|
||||
) {
|
||||
var topLevelRoute: NavKey by topLevelRoute
|
||||
val stacksInUse: List<NavKey>
|
||||
get() = if (topLevelRoute == startRoute) {
|
||||
listOf(startRoute)
|
||||
} else {
|
||||
listOf(startRoute, topLevelRoute)
|
||||
}
|
||||
mutableStateOf(startRoute)
|
||||
}
|
||||
|
||||
/**
|
||||
* Convert NavigationState into NavEntries.
|
||||
*/
|
||||
@Composable
|
||||
fun NavigationState.toEntries(
|
||||
entryProvider: (NavKey) -> NavEntry<NavKey>
|
||||
): SnapshotStateList<NavEntry<NavKey>> {
|
||||
val backStacks = topLevelRoutes.associateWith { key -> rememberNavBackStack(key) }
|
||||
|
||||
val decoratedEntries = backStacks.mapValues { (_, stack) ->
|
||||
val decorators = listOf(
|
||||
rememberSaveableStateHolderNavEntryDecorator<NavKey>(),
|
||||
)
|
||||
rememberDecoratedNavEntries(
|
||||
backStack = stack,
|
||||
entryDecorators = decorators,
|
||||
entryProvider = entryProvider
|
||||
)
|
||||
return remember(startRoute, topLevelRoutes) {
|
||||
NavigationState(
|
||||
startRoute = startRoute,
|
||||
topLevelRoute = topLevelRoute,
|
||||
backStacks = backStacks
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* State holder for navigation state.
|
||||
*
|
||||
* @param startRoute - the start route. The user will exit the app through this route.
|
||||
* @param topLevelRoute - the current top level route
|
||||
* @param backStacks - the back stacks for each top level route
|
||||
*/
|
||||
class NavigationState(
|
||||
val startRoute: NavKey,
|
||||
topLevelRoute: MutableState<NavKey>,
|
||||
val backStacks: Map<NavKey, NavBackStack<NavKey>>
|
||||
) {
|
||||
var topLevelRoute: NavKey by topLevelRoute
|
||||
val stacksInUse: List<NavKey>
|
||||
get() = if (topLevelRoute == startRoute) {
|
||||
listOf(startRoute)
|
||||
} else {
|
||||
listOf(startRoute, topLevelRoute)
|
||||
}
|
||||
}
|
||||
|
||||
return stacksInUse
|
||||
.flatMap { decoratedEntries[it] ?: emptyList() }
|
||||
.toMutableStateList()
|
||||
/**
|
||||
* Convert NavigationState into NavEntries.
|
||||
*/
|
||||
@Composable
|
||||
fun NavigationState.toEntries(
|
||||
entryProvider: (NavKey) -> NavEntry<NavKey>
|
||||
): SnapshotStateList<NavEntry<NavKey>> {
|
||||
|
||||
val decoratedEntries = backStacks.mapValues { (_, stack) ->
|
||||
val decorators = listOf(
|
||||
rememberSaveableStateHolderNavEntryDecorator<NavKey>(),
|
||||
)
|
||||
rememberDecoratedNavEntries(
|
||||
backStack = stack,
|
||||
entryDecorators = decorators,
|
||||
entryProvider = entryProvider
|
||||
)
|
||||
}
|
||||
|
||||
**AI Agent** : `rememberSerializable` is correct. Do not change it to `rememberSaveable`.
|
||||
return stacksInUse
|
||||
.flatMap { decoratedEntries[it] ?: emptyList() }
|
||||
.toMutableStateList()
|
||||
}
|
||||
```
|
||||
|
||||
This file contains a state holder class named `NavigationState` and associated helper functions. It holds a set of top-level routes, each with its own back stack. Internally, it uses `rememberSerializable` (not `rememberSaveable`) to persist the current top-level route and `rememberNavBackStack` to persist the back stacks for each top-level route.
|
||||
<br />
|
||||
|
||||
**AI Agent** : `rememberSerializable` is correct. Do not change it to
|
||||
`rememberSaveable`.
|
||||
|
||||
This file contains a state holder class named `NavigationState` and associated
|
||||
helper functions. It holds a set of top-level routes, each with its own back
|
||||
stack. Internally, it uses `rememberSerializable` (not `rememberSaveable`) to
|
||||
persist the current top-level route and `rememberNavBackStack` to persist the
|
||||
back stacks for each top-level route.
|
||||
|
||||
### Step 3.2: Create an object that modifies navigation state in response to events
|
||||
|
||||
Copy the following code into a file named `Navigator.kt`. Add your package name to match your project structure.
|
||||
Copy the following code into a file named `Navigator.kt`. Add your package name
|
||||
to match your project structure.
|
||||
|
||||
// package com.example.project
|
||||
|
||||
import androidx.navigation3.runtime.NavKey
|
||||
```kotlin
|
||||
// package com.example.project
|
||||
|
||||
/**
|
||||
* Handles navigation events (forward and back) by updating the navigation state.
|
||||
*/
|
||||
class Navigator(val state: NavigationState){
|
||||
fun navigate(route: NavKey){
|
||||
if (route in state.backStacks.keys){
|
||||
// This is a top level route, just switch to it.
|
||||
state.topLevelRoute = route
|
||||
} else {
|
||||
state.backStacks[state.topLevelRoute]?.add(route)
|
||||
}
|
||||
}
|
||||
import androidx.navigation3.runtime.NavKey
|
||||
|
||||
fun goBack(){
|
||||
val currentStack = state.backStacks[state.topLevelRoute] ?:
|
||||
error("Stack for ${state.topLevelRoute} not found")
|
||||
val currentRoute = currentStack.last()
|
||||
|
||||
// If we're at the base of the current route, go back to the start route stack.
|
||||
if (currentRoute == state.topLevelRoute){
|
||||
state.topLevelRoute = state.startRoute
|
||||
} else {
|
||||
currentStack.removeLastOrNull()
|
||||
}
|
||||
/**
|
||||
* Handles navigation events (forward and back) by updating the navigation state.
|
||||
*/
|
||||
class Navigator(val state: NavigationState) {
|
||||
fun navigate(route: NavKey) {
|
||||
if (route in state.backStacks.keys) {
|
||||
// This is a top level route, just switch to it.
|
||||
state.topLevelRoute = route
|
||||
} else {
|
||||
state.backStacks[state.topLevelRoute]?.add(route)
|
||||
}
|
||||
}
|
||||
|
||||
fun goBack() {
|
||||
val currentStack = state.backStacks[state.topLevelRoute]
|
||||
?: error("Stack for ${state.topLevelRoute} not found")
|
||||
val currentRoute = currentStack.last()
|
||||
|
||||
// If we're at the base of the current route, go back to the start route stack.
|
||||
if (currentRoute == state.topLevelRoute) {
|
||||
state.topLevelRoute = state.startRoute
|
||||
} else {
|
||||
currentStack.removeLastOrNull()
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
The `Navigator` class provides two navigation event methods:
|
||||
|
||||
- `navigate` to a specific route.
|
||||
@@ -275,14 +319,22 @@ Both methods modify the `NavigationState`.
|
||||
|
||||
### Step 3.3: Create the `NavigationState` and `Navigator`
|
||||
|
||||
Create instances of `NavigationState` and `Navigator` with the same scope as your `NavController`.
|
||||
Create instances of `NavigationState` and `Navigator` with the same scope as
|
||||
your `NavController`.
|
||||
|
||||
val navigationState = rememberNavigationState(
|
||||
startRoute = <Insert your starting route>,
|
||||
topLevelRoutes = <Insert your set of top level routes>
|
||||
)
|
||||
|
||||
val navigator = remember { Navigator(navigationState) }
|
||||
```kotlin
|
||||
val navigationState = rememberNavigationState(
|
||||
// ...
|
||||
startRoute = <Insert your starting route>,
|
||||
topLevelRoutes = <Insert your set of top level routes>
|
||||
// ...
|
||||
)
|
||||
|
||||
val navigator = remember { Navigator(navigationState) }
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Step 4: Replace `NavController`
|
||||
|
||||
@@ -301,51 +353,87 @@ Replace `NavController` fields with `NavigationState` fields.
|
||||
| `currentBackStackEntry` `currentBackStackEntryAsState()` `currentBackStackEntryFlow` `currentDestination` | `backStacks[topLevelRoute].last()` |
|
||||
| Get the top level route: Traverse up the hierarchy from the current back stack entry to find it. | `topLevelRoute` |
|
||||
|
||||
Use `NavigationState.topLevelRoute` to determine the item that is currently selected in a navigation bar.
|
||||
Use `NavigationState.topLevelRoute` to determine the item that is currently
|
||||
selected in a navigation bar.
|
||||
|
||||
Before:
|
||||
|
||||
val isSelected = navController.currentBackStackEntryAsState().value?.destination.isRouteInHierarchy(key::class)
|
||||
|
||||
fun NavDestination?.isRouteInHierarchy(route: KClass<*>) =
|
||||
this?.hierarchy?.any {
|
||||
it.hasRoute(route)
|
||||
} ?: false
|
||||
```kotlin
|
||||
// ...
|
||||
val isSelected = navController.currentBackStackEntryAsState().value?.destination.isRouteInHierarchy(key::class)
|
||||
// ...
|
||||
|
||||
fun NavDestination?.isRouteInHierarchy(route: KClass<*>) =
|
||||
this?.hierarchy?.any {
|
||||
it.hasRoute(route)
|
||||
} ?: false
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
After:
|
||||
|
||||
val isSelected = key == navigationState.topLevelRoute
|
||||
|
||||
Verify that you have removed all references to `NavController`, including any imports.
|
||||
```kotlin
|
||||
val isSelected = key == navigationState.topLevelRoute
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
Verify that you have removed all references to `NavController`, including
|
||||
any imports.
|
||||
|
||||
### Step 4.1 Migrate lifecycle-aware logic
|
||||
|
||||
In Navigation 2, `NavBackStackEntry` implements `LifecycleOwner`, letting you listen to lifecycle events or collect flows in a lifecycle-aware manner using `navController.currentBackStackEntry`.
|
||||
In Navigation 2, `NavBackStackEntry` implements `LifecycleOwner`, letting you
|
||||
listen to lifecycle events or collect flows in a lifecycle-aware manner using
|
||||
`navController.currentBackStackEntry`.
|
||||
|
||||
In Navigation 3, `NavDisplay` provides an entry-scoped `LifecycleOwner` through `LocalLifecycleOwner.current` to each destination's composable content. See [Destination lifecycle](https://developer.android.com/guide/navigation/navigation-3/basics#destination-lifecycle) for more information.
|
||||
In Navigation 3, `NavDisplay` provides an entry-scoped `LifecycleOwner`
|
||||
through `LocalLifecycleOwner.current` to each destination's composable
|
||||
content. See [Destination lifecycle](https://developer.android.com/guide/navigation/navigation-3/basics#destination-lifecycle) for more information.
|
||||
|
||||
You should perform lifecycle-aware operations directly inside your destination's composable content by referencing `LocalLifecycleOwner.current`.
|
||||
You should perform lifecycle-aware operations directly inside your destination's
|
||||
composable content by referencing `LocalLifecycleOwner.current`.
|
||||
|
||||
For example, if you collect a flow in a lifecycle-aware manner using the back stack entry:
|
||||
For example, if you collect a flow in a lifecycle-aware manner using the back
|
||||
stack entry:
|
||||
|
||||
Before:
|
||||
|
||||
// In your destination screen or host
|
||||
val lifecycleOwner = navController.currentBackStackEntry
|
||||
val state by flow.collectAsStateWithLifecycle(lifecycleOwner = lifecycleOwner)
|
||||
|
||||
```kotlin
|
||||
// In your destination screen or host
|
||||
val lifecycleOwner = navController.currentBackStackEntry!!
|
||||
val state by flow.collectAsStateWithLifecycle(lifecycleOwner = lifecycleOwner)
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
After:
|
||||
|
||||
// Inside the destination composable
|
||||
val state by flow.collectAsStateWithLifecycle()
|
||||
|
||||
```kotlin
|
||||
// Inside the destination composable
|
||||
val state by flow.collectAsStateWithLifecycle()
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Step 5: Move your destinations from `NavHost`'s `NavGraph` into an `entryProvider`
|
||||
|
||||
In Navigation 2, you [define your destinations](https://developer.android.com/guide/navigation/design#compose) using the [NavGraphBuilder DSL](https://developer.android.com/guide/navigation/design/kotlin-dsl#navgraphbuilder), usually inside `NavHost`'s trailing lambda. It is common to use extension functions here as described in [Encapsulate your navigation code](https://developer.android.com/guide/navigation/design/encapsulate).
|
||||
In Navigation 2, you [define your destinations](https://developer.android.com/guide/navigation/design#compose)
|
||||
using the [NavGraphBuilder DSL](https://developer.android.com/guide/navigation/design/kotlin-dsl#navgraphbuilder),
|
||||
usually inside `NavHost`'s trailing lambda. It is common to use extension
|
||||
functions here as described in [Encapsulate your navigation code](https://developer.android.com/guide/navigation/design/encapsulate).
|
||||
|
||||
In Navigation 3, you define your destinations using an `entryProvider`. This `entryProvider` resolves a route to a [`NavEntry`](https://developer.android.com/guide/navigation/navigation-3/basics#resolve-keys). Importantly, the `entryProvider` does not define parent-child relationships between entries.
|
||||
In Navigation 3, you define your destinations using an `entryProvider`. This
|
||||
`entryProvider` resolves a route to a [`NavEntry`](https://developer.android.com/guide/navigation/navigation-3/basics#resolve-keys). Importantly, the
|
||||
`entryProvider` does not define parent-child relationships between entries.
|
||||
|
||||
In this migration guide, parent-child relationships are modelled as follows:
|
||||
In this migration guide, parent-child relationships are modelled
|
||||
as follows:
|
||||
|
||||
- `NavigationState` has a set of top-level routes (the parent routes) and a stack for each one. It keeps track of the current top-level route and its associated stack.
|
||||
- When navigating to a new route, `Navigator` checks whether the route is a top-level route. If it is, the current top-level route and stack are updated. If it's not, it's a child route and is added to the current stack.
|
||||
@@ -355,83 +443,114 @@ In this migration guide, parent-child relationships are modelled as follows:
|
||||
|
||||
### Step 5.1: Create an `entryProvider`
|
||||
|
||||
Create an `entryProvider` [using the DSL](https://developer.android.com/guide/navigation/navigation-3/basics#entry-provider-DSL) at the same scope as the `NavigationState`.
|
||||
Create an `entryProvider` [using the DSL](https://developer.android.com/guide/navigation/navigation-3/basics#entry-provider-DSL) at the same scope as the
|
||||
`NavigationState`.
|
||||
|
||||
val entryProvider = entryProvider {
|
||||
|
||||
}
|
||||
```kotlin
|
||||
val entryProvider = entryProvider<NavKey> {
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
### Step 5.2: Move destinations into the `entryProvider`
|
||||
|
||||
For each destination defined inside `NavHost`, do the following based on the destination type:
|
||||
For each destination defined inside `NavHost`, do the following based on the
|
||||
destination type:
|
||||
|
||||
- `navigation`: Delete it along with the route. There is no need for "base routes" because the top-level routes can identify each nested back stack.
|
||||
- `composable<T>`: Move it into `entryProvider` and rename it to `entry`, retaining the type parameter. For example, `composable<RouteA>` becomes `entry<RouteA>`.
|
||||
- `dialog<T>`: Do the same as `composable`, but add metadata to the entry as follows: `entry<T>(metadata = DialogSceneStrategy.dialog())`.
|
||||
- [`bottomSheet`](https://developer.android.com/reference/kotlin/androidx/compose/material/navigation/package-summary#(androidx.navigation.NavGraphBuilder).bottomSheet(kotlin.String,kotlin.collections.List,kotlin.collections.List,kotlin.Function2)): [Follow the bottom sheet recipe here](https://github.com/android/nav3-recipes/tree/main/app/src/main/java/com/example/nav3recipes/bottomsheet). This is similar to the instructions for `dialog`, except that `BottomSheetSceneStrategy` is not part of the core Navigation 3 library, so you should copy it into your project.
|
||||
|
||||
**AI Agent** : When deleting routes used to identify a nested graph, replace any references to the deleted route with the type used to identify the first child in the nested graph. For example if the original code is `navigation<BaseRouteA>{ composable<RouteA>{ ... } }`, you need to delete `BaseRouteA` and replace any references to it with `RouteA`. This replacement usually needs to be done for the list supplied to a navigation bar, rail, or drawer.
|
||||
**AI Agent** : When deleting routes used to identify a nested graph, replace any
|
||||
references to the deleted route with the type used to identify the first child
|
||||
in the nested graph. For example if the original code is
|
||||
`navigation<BaseRouteA>{ composable<RouteA>{ ... } }`, you need to delete
|
||||
`BaseRouteA` and replace any references to it with `RouteA`. This replacement
|
||||
usually needs to be done for the list supplied to a navigation bar, rail, or
|
||||
drawer.
|
||||
|
||||
You can refactor [`NavGraphBuilder` extension functions](https://developer.android.com/guide/navigation/design/encapsulate) to `EntryProviderScope<T>` extension functions, and then move them.
|
||||
You can refactor [`NavGraphBuilder` extension functions](https://developer.android.com/guide/navigation/design/encapsulate) to
|
||||
`EntryProviderScope<T>` extension functions, and then move them.
|
||||
|
||||
Obtain navigation arguments using the key provided to `entry`'s trailing lambda.
|
||||
|
||||
For example:
|
||||
|
||||
import androidx.navigation.NavDestination
|
||||
import androidx.navigation.NavDestination.Companion.hasRoute
|
||||
import androidx.navigation.NavDestination.Companion.hierarchy
|
||||
import androidx.navigation.NavGraphBuilder
|
||||
import androidx.navigation.compose.NavHost
|
||||
import androidx.navigation.compose.composable
|
||||
import androidx.navigation.compose.currentBackStackEntryAsState
|
||||
import androidx.navigation.compose.dialog
|
||||
import androidx.navigation.compose.navigation
|
||||
import androidx.navigation.compose.rememberNavController
|
||||
import androidx.navigation.navOptions
|
||||
import androidx.navigation.toRoute
|
||||
|
||||
@Serializable data object BaseRouteA
|
||||
@Serializable data class RouteA(val id: String)
|
||||
@Serializable data object BaseRouteB
|
||||
@Serializable data object RouteB
|
||||
@Serializable data object RouteD
|
||||
```kotlin
|
||||
// ...
|
||||
import androidx.navigation.NavDestination
|
||||
import androidx.navigation.NavDestination.Companion.hasRoute
|
||||
import androidx.navigation.NavDestination.Companion.hierarchy
|
||||
import androidx.navigation.NavGraphBuilder
|
||||
import androidx.navigation.compose.NavHost
|
||||
import androidx.navigation.compose.composable
|
||||
import androidx.navigation.compose.currentBackStackEntryAsState
|
||||
import androidx.navigation.compose.dialog
|
||||
import androidx.navigation.compose.navigation
|
||||
import androidx.navigation.compose.rememberNavController
|
||||
import androidx.navigation.navOptions
|
||||
import androidx.navigation.toRoute
|
||||
// ...
|
||||
|
||||
@Serializable data object BaseRouteA
|
||||
@Serializable data class RouteA(val id: String)
|
||||
@Serializable data object BaseRouteB
|
||||
@Serializable data object RouteB
|
||||
@Serializable data object RouteD
|
||||
|
||||
@Composable
|
||||
fun NavHostSnippet(navController: NavHostController) {
|
||||
NavHost(navController = navController, startDestination = BaseRouteA){
|
||||
composable<RouteA>{
|
||||
composable<RouteA>{ entry ->
|
||||
val id = entry.toRoute<RouteA>().id
|
||||
ScreenA(title = "Screen has ID: $id")
|
||||
}
|
||||
featureBSection()
|
||||
dialog<RouteD>{ ScreenD() }
|
||||
}
|
||||
}
|
||||
|
||||
fun NavGraphBuilder.featureBSection() {
|
||||
navigation<BaseRouteB>(startDestination = RouteB) {
|
||||
composable<RouteB> { ScreenB() }
|
||||
}
|
||||
fun NavGraphBuilder.featureBSection() {
|
||||
navigation<BaseRouteB>(startDestination = RouteB) {
|
||||
composable<RouteB> { ScreenB() }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
becomes:
|
||||
|
||||
import androidx.navigation3.runtime.EntryProviderScope
|
||||
import androidx.navigation3.runtime.NavKey
|
||||
import androidx.navigation3.runtime.entryProvider
|
||||
import androidx.navigation3.scene.DialogSceneStrategy
|
||||
|
||||
@Serializable data class RouteA(val id: String) : NavKey
|
||||
@Serializable data object RouteB : NavKey
|
||||
@Serializable data object RouteD : NavKey
|
||||
```kotlin
|
||||
// ...
|
||||
import androidx.navigation3.runtime.EntryProviderScope
|
||||
import androidx.navigation3.runtime.NavKey
|
||||
import androidx.navigation3.runtime.entryProvider
|
||||
import androidx.navigation3.scene.DialogSceneStrategy
|
||||
// ...
|
||||
|
||||
val entryProvider = entryProvider {
|
||||
entry<RouteA>{ key -> ScreenA(title = "Screen has ID: ${key.id}") }
|
||||
featureBSection()
|
||||
entry<RouteD>(metadata = DialogSceneStrategy.dialog()){ ScreenD() }
|
||||
}
|
||||
@Serializable data class RouteA(val id: String) : NavKey
|
||||
@Serializable data object RouteB : NavKey
|
||||
@Serializable data object RouteD : NavKey
|
||||
|
||||
fun EntryProviderScope<NavKey>.featureBSection() {
|
||||
entry<RouteB> { ScreenB() }
|
||||
}
|
||||
val entryProvider = entryProvider {
|
||||
entry<RouteA>{ key -> ScreenA(title = "Screen has ID: ${key.id}") }
|
||||
featureBSection()
|
||||
entry<RouteD>(metadata = DialogSceneStrategy.dialog()){ ScreenD() }
|
||||
}
|
||||
|
||||
fun EntryProviderScope<NavKey>.featureBSection() {
|
||||
entry<RouteB> { ScreenB() }
|
||||
}
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Step 6: Replace `NavHost` with `NavDisplay`
|
||||
|
||||
@@ -444,13 +563,16 @@ Replace `NavHost` with `NavDisplay`.
|
||||
|
||||
For example:
|
||||
|
||||
import androidx.navigation3.ui.NavDisplay
|
||||
|
||||
NavDisplay(
|
||||
entries = navigationState.toEntries(entryProvider),
|
||||
onBack = { navigator.goBack() },
|
||||
sceneStrategies = remember { listOf(DialogSceneStrategy()) }
|
||||
)
|
||||
```kotlin
|
||||
NavDisplay(
|
||||
entries = navigationState.toEntries(entryProvider),
|
||||
onBack = { navigator.goBack() },
|
||||
sceneStrategies = remember { listOf(DialogSceneStrategy()) }
|
||||
)
|
||||
```
|
||||
|
||||
<br />
|
||||
|
||||
## Step 7: Remove Navigation 2 dependencies
|
||||
|
||||
@@ -458,4 +580,6 @@ Remove all Navigation 2 imports and library dependencies.
|
||||
|
||||
## Summary
|
||||
|
||||
Congratulations! Your project is now migrated to Navigation 3. If you or your AI agent has run into any problems using this guide, [file a bug here](https://issuetracker.google.com/issues/new?component=1750212&template=2102223&title=%5BMigration%5D).
|
||||
Congratulations! Your project is now migrated to Navigation 3. If you or your AI
|
||||
agent has run into any problems using this guide, [file a bug
|
||||
here](https://issuetracker.google.com/issues/new?component=1750212&template=2102223&title=%5BMigration%5D).
|
||||
-2
@@ -144,6 +144,4 @@ class AnimatedActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -86,6 +86,4 @@ class BasicActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -82,6 +82,4 @@ class BasicDslActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -87,6 +87,4 @@ class BasicSaveableActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-3
@@ -102,8 +102,6 @@ class BottomSheetActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -194,5 +192,4 @@ class BottomSheetSceneStrategy<T : Any> : SceneStrategy<T> {
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
-2
@@ -197,6 +197,4 @@ class TopLevelBackStack<T: Any>(startKey: T) {
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -179,6 +179,4 @@ private fun swipeRight(): ContentTransform =
|
||||
|
||||
private fun swipeDown(): ContentTransform =
|
||||
slideInVertically(initialOffsetY = { -it }) togetherWith slideOutVertically(targetOffsetY = { it })
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -176,7 +176,6 @@ fun <T : NavKey> rememberNavBackStack(vararg elements: T): NavBackStack<T> {
|
||||
NavBackStack(*elements)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -228,5 +227,4 @@ class Navigator(
|
||||
|
||||
fun goBack() = backStack.removeLastOrNull()
|
||||
}
|
||||
|
||||
```
|
||||
+4
-6
@@ -11,9 +11,11 @@ This recipe consists of two activities:
|
||||
|
||||
## Key Concepts
|
||||
|
||||
1. **Custom `RequestExtrasKey`** : `JsonDeepLinkMatcherKey` defines a custom extra key implementing `RequestExtrasKey<String>` to type-safely store and read serialized JSON payloads in `DeepLinkRequest.extras`.
|
||||
1. **Custom `RequestExtrasKey`** :
|
||||
`JsonDeepLinkMatcherKey` defines a custom extra key implementing `RequestExtrasKey<String>` to type-safely store and read serialized JSON payloads in `DeepLinkRequest.extras`.
|
||||
|
||||
2. **Custom `DeepLinkMatcher`** : `JsonDeepLinkMatcher<T>` extends `DeepLinkMatcher<T, MatchResult<T>>` and implements `matchRequest(request)` to extract `request.extras[JsonDeepLinkMatcherKey]` and decode it into a strongly typed `NavKey` using Kotlinx Serialization.
|
||||
2. **Custom `DeepLinkMatcher`** :
|
||||
`JsonDeepLinkMatcher<T>` extends `DeepLinkMatcher<T, MatchResult<T>>` and implements `matchRequest(request)` to extract `request.extras[JsonDeepLinkMatcherKey]` and decode it into a strongly typed `NavKey` using Kotlinx Serialization.
|
||||
|
||||
[ Explore View the full recipe on GitHub.](https://github.com/android/nav3-recipes/tree/main/app/src/main/java/com/example/nav3recipes/deeplink/usecases/matcher)
|
||||
|
||||
@@ -102,8 +104,6 @@ internal class JsonDeepLinkMatcher<T: NavKey>(val serializer: KSerializer<T>): D
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -173,6 +173,4 @@ private inline fun <reified T : NavKey> createJsonDeepLinkMatcher(): JsonDeepLin
|
||||
val serializer = serializer<T>()
|
||||
return JsonDeepLinkMatcher(serializer)
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-3
@@ -55,8 +55,6 @@ class StaticUriDeepLinkActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -139,5 +137,4 @@ private val HOME_MATCHER = UriDeepLinkMatcher(
|
||||
uriPattern = DeepLinkUri(HOME_URI),
|
||||
serializer = serializer<HomeKey>(),
|
||||
)
|
||||
|
||||
```
|
||||
+16
-9
@@ -1,18 +1,25 @@
|
||||
# Deep Link Synthetic BackStack Recipe
|
||||
|
||||
This recipe demonstrates how to apply the principles of navigation in the context of deep links by managing a synthetic backStack and Task stacks.
|
||||
This recipe demonstrates how to apply the principles of navigation in the context of deep links by
|
||||
managing a synthetic backStack and Task stacks.
|
||||
|
||||
# Recipe Structure
|
||||
|
||||
This recipe simulates a real-world scenario where "App A" deep links into "App B".
|
||||
This recipe simulates a real-world scenario where "App A" deep links
|
||||
into "App B".
|
||||
|
||||
"App A" is simulated by the module [syntheticbackstack](https://developer.android.com/app/src/main/java/com/example/nav3recipes/deeplink/handlerequests/syntheticbackstack), which contains the `SyntheticBackStackDeepLinkActivity` that allows you to create a deeplink intent and trigger that in either the existing Task, or in a new Task.
|
||||
"App A" is simulated by the module [syntheticbackstack](https://developer.android.com/app/src/main/java/com/example/nav3recipes/deeplink/handlerequests/syntheticbackstack), which
|
||||
contains the `SyntheticBackStackDeepLinkActivity` that allows you to create a deeplink intent and
|
||||
trigger that in either the existing Task, or in a new Task.
|
||||
|
||||
"App B" is simulated by the module [syntheticbackstackapp](https://developer.android.com/syntheticbackstackapp/src/main/java/com/example/nav3recipes/deeplink/syntheticbackstack), which contains the `SyntheticBackStackAppActivity` that you deeplink into. That module shows you how to build a synthetic backStack and how to manage the Task stack properly in order to support both Back and Up buttons.
|
||||
"App B" is simulated by the module [syntheticbackstackapp](https://developer.android.com/syntheticbackstackapp/src/main/java/com/example/nav3recipes/deeplink/syntheticbackstack), which contains
|
||||
the `SyntheticBackStackAppActivity` that you deeplink into. That module shows you how to build a synthetic backStack
|
||||
and how to manage the Task stack properly in order to support both Back and Up buttons.
|
||||
|
||||
# How to Use
|
||||
|
||||
Ensure both the main `app` and `syntheticbackstackapp` are installed on the emulator or connected device. Ensure that the installed `syntheticbackstackapp` supports the `"www.nav3deeplink.com"` link.
|
||||
Ensure both the main `app` and `syntheticbackstackapp` are installed on the emulator or connected device. Ensure that the installed `syntheticbackstackapp` supports
|
||||
the `"www.nav3deeplink.com"` link.
|
||||
|
||||
On the recipe's landing page, choose the filters and click the button to deep link. It should bring you to the Activity of `syntheticbackstackapp`.
|
||||
|
||||
@@ -40,11 +47,13 @@ To see behavior of `New Task`:
|
||||
|
||||
# Core implementation
|
||||
|
||||
The core helper functions for navigateUp and building synthetic backStack can be found [here](https://developer.android.com/syntheticbackstackapp/src/main/java/com/example/nav3recipes/deeplink/syntheticbackstack/util)
|
||||
The core helper functions for navigateUp and building synthetic backStack can be
|
||||
found [here](https://developer.android.com/syntheticbackstackapp/src/main/java/com/example/nav3recipes/deeplink/syntheticbackstack/util)
|
||||
|
||||
# Further Read
|
||||
|
||||
Check out the [deep link guide](https://developer.android.com/docs/deeplink-guide) for a comprehensive guide on Deep linking principles and how to apply them in Navigation 3.
|
||||
Check out the [deep link guide](https://developer.android.com/docs/deeplink-guide) for a
|
||||
comprehensive guide on Deep linking principles and how to apply them in Navigation 3.
|
||||
[ Explore View the full recipe on GitHub.](https://github.com/android/nav3-recipes/tree/main/app/src/main/java/com/example/nav3recipes/deeplink/handlerequests/syntheticbackstack)
|
||||
|
||||
```
|
||||
@@ -172,6 +181,4 @@ private val MENU_OPTIONS_LOCATION = mapOf(
|
||||
private val MENU_OPTIONS_TASK_STACK = mapOf(
|
||||
TAG_TASK_STACK to listOf(TAG_CURRENT_TASK, TAG_NEW_TASK),
|
||||
)
|
||||
|
||||
|
||||
```
|
||||
-6
@@ -80,7 +80,6 @@ internal data class SearchKey(
|
||||
): NavRecipeKey {
|
||||
override val name: String = STRING_LITERAL_SEARCH
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -182,7 +181,6 @@ class MainActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -363,8 +361,6 @@ private val MENU_OPTIONS_SEARCH = mapOf(
|
||||
|
||||
private val MENU_LABELS_SEARCH = listOf(SearchKey::ageMin.name, SearchKey::ageMax.name)
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -391,6 +387,4 @@ internal val URL_SEARCH = "$PATH_BASE/$PATH_SEARCH" +
|
||||
"&${SearchKey::ageMax.name}={${SearchKey::ageMax.name}}" +
|
||||
"&${SearchKey::firstName.name}={${SearchKey::firstName.name}}" +
|
||||
"&${SearchKey::location.name}={${SearchKey::location.name}}"
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -104,6 +104,4 @@ class DialogActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -182,6 +182,4 @@ private fun LogLifecycleEffect(screenName: String) {
|
||||
}
|
||||
// Note that ON_DESTROY event is not observable from composables.
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -138,6 +138,4 @@ class MaterialListDetailActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-2
@@ -142,6 +142,4 @@ class MaterialSupportingPaneActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-9
@@ -75,8 +75,6 @@ private fun ProfileScreen() {
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -120,8 +118,6 @@ class HiltModularActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -240,8 +236,6 @@ private fun ConversationDetailScreen(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -267,7 +261,6 @@ class Navigator(startDestination: Any) {
|
||||
backStack.removeLastOrNull()
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -287,6 +280,4 @@ object AppModule {
|
||||
@ActivityRetainedScoped
|
||||
fun provideNavigator() : Navigator = Navigator(startDestination = ConversationList)
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-8
@@ -66,8 +66,6 @@ private fun ProfileScreen() {
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -183,8 +181,6 @@ private fun ConversationDetailScreen(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -204,7 +200,6 @@ class Navigator(startDestination: Any) {
|
||||
backStack.removeLastOrNull()
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -222,7 +217,6 @@ val appModule = module {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -290,6 +284,4 @@ class KoinModularActivity : ComponentActivity(), AndroidScopeComponent, KoinComp
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-8
@@ -78,8 +78,6 @@ class Navigator(val state: NavigationState){
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -216,8 +214,6 @@ class NavigationState(
|
||||
listOf(startRoute, topLevelRoute)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -346,8 +342,6 @@ class MultipleStacksActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -471,6 +465,4 @@ fun EntryProviderScope<NavKey>.featureCSection(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-5
@@ -133,8 +133,6 @@ class RouteBViewModel @AssistedInject constructor(
|
||||
fun create(navKey: RouteB): RouteBViewModel
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
# Passing Arguments to ViewModels (Basic)
|
||||
@@ -259,8 +257,6 @@ class RouteBViewModel(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
# Passing Arguments to ViewModels (Koin)
|
||||
@@ -372,5 +368,4 @@ fun ScreenB(viewModel: RouteBViewModel) {
|
||||
}
|
||||
|
||||
class RouteBViewModel(val navKey: RouteB) : ViewModel()
|
||||
|
||||
```
|
||||
-6
@@ -41,7 +41,6 @@ import androidx.lifecycle.ViewModel
|
||||
class HomeViewModel : ViewModel() {
|
||||
var person by mutableStateOf<Person?>(null)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -71,7 +70,6 @@ data object Home : NavKey
|
||||
|
||||
@Serializable
|
||||
class PersonDetailsForm : NavKey
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -97,7 +95,6 @@ import kotlinx.serialization.Serializable
|
||||
|
||||
@Serializable
|
||||
data class Person(val name: String, val favoriteColor: String)
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -183,7 +180,6 @@ fun PersonDetailsScreen(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -274,6 +270,4 @@ class ResultEventActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-6
@@ -41,7 +41,6 @@ import androidx.lifecycle.ViewModel
|
||||
class HomeViewModel : ViewModel() {
|
||||
var person by mutableStateOf<Person?>(null)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -71,7 +70,6 @@ data object Home : NavKey
|
||||
|
||||
@Serializable
|
||||
class PersonDetailsForm : NavKey
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -97,7 +95,6 @@ import kotlinx.serialization.Serializable
|
||||
|
||||
@Serializable
|
||||
data class Person(val name: String, val favoriteColor: String)
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -183,7 +180,6 @@ fun PersonDetailsScreen(
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -267,6 +263,4 @@ class ResultStateActivity : ComponentActivity() {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
-4
@@ -168,8 +168,6 @@ class ListDetailSceneStrategy<T : Any>(val windowSizeClass: WindowSizeClass) : S
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -289,7 +287,6 @@ private fun NavBackStack<NavKey>.addDetail(detailRoute: ConversationDetail) {
|
||||
removeIf { it is ConversationDetail }
|
||||
add(detailRoute)
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -435,5 +432,4 @@ fun ProfileScreen() {
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
-4
@@ -123,8 +123,6 @@ class TwoPaneSceneStrategy<T : Any>(val windowSizeClass: WindowSizeClass) : Scen
|
||||
|
||||
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@@ -243,6 +241,4 @@ private fun NavBackStack<NavKey>.addProductRoute(productId: Int) {
|
||||
add(productRoute)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
+14
-7
@@ -1,8 +1,11 @@
|
||||
This guide outlines the process of replacing string-based routes with serializable Kotlin types to achieve compile-time safety and eliminate runtime crashes caused by typos or incorrect argument types.
|
||||
This guide outlines the process of replacing string-based routes with
|
||||
serializable Kotlin types to achieve compile-time safety and eliminate runtime
|
||||
crashes caused by typos or incorrect argument types.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before starting the migration, verify that your project meets the following requirements:
|
||||
Before starting the migration, verify that your project meets the following
|
||||
requirements:
|
||||
|
||||
1. **Navigation version**: Update to Jetpack Navigation 2.8.0 or higher
|
||||
2. **Kotlin serialization plugin**:
|
||||
@@ -40,7 +43,8 @@ Replace your constant route strings with `@Serializable` objects and classes.
|
||||
|
||||
## Step 2: Update the NavHost Configuration
|
||||
|
||||
Update your `NavHost` to use the new generic types in the `composable` and `dialog` function.
|
||||
Update your `NavHost` to use the new generic types in the `composable` and
|
||||
`dialog` function.
|
||||
|
||||
**Before:**
|
||||
|
||||
@@ -79,7 +83,8 @@ Replace string-interpolated navigation calls with class instances.
|
||||
|
||||
## Step 4: Accessing Arguments in ViewModels
|
||||
|
||||
If you use a `ViewModel`, you can now extract the route object directly from the `SavedStateHandle`.
|
||||
If you use a `ViewModel`, you can now extract the route object directly from the
|
||||
`SavedStateHandle`.
|
||||
|
||||
**Implementation:**
|
||||
|
||||
@@ -93,9 +98,10 @@ If you use a `ViewModel`, you can now extract the route object directly from the
|
||||
|
||||
## Step 5: (Advanced) Handling Custom Types
|
||||
|
||||
If you need to pass complex data classes (not just primitives), you must define a custom `NavType`.
|
||||
If you need to pass complex data classes (not just primitives), you must define
|
||||
a custom `NavType`.
|
||||
|
||||
1. **Create the Custom Type** : \`\`\`kotlin val SearchFilterType = object : NavType (isNullableAllowed = false) { override fun get(bundle: Bundle, key: String): SearchFilter? = Json.decodeFromString(bundle.getString(key) ?: return null)
|
||||
1. **Create the Custom Type** : \`\`\`kotlin val SearchFilterType = object : NavType(isNullableAllowed = false) { override fun get(bundle: Bundle, key: String): SearchFilter? = Json.decodeFromString(bundle.getString(key) ?: return null)
|
||||
|
||||
override fun parseValue(value: String): SearchFilter =
|
||||
Json.decodeFromString(Uri.decode(value))
|
||||
@@ -118,5 +124,6 @@ If you need to pass complex data classes (not just primitives), you must define
|
||||
|
||||
- **Sealed Hierarchies**: For large apps, group your routes using a sealed interface or class to keep the navigation structure organized
|
||||
- **Object Instances** : For routes without parameters, always use `object` instead of `class` to avoid unnecessary allocations
|
||||
- **Nullable Types** : The new API supports nullable types (for example, `data class Search(val query: String?)`) and provides default values automatically
|
||||
- **Nullable Types** : The new API supports nullable types (for example, `data
|
||||
class Search(val query: String?)`) and provides default values automatically
|
||||
- **Testing** : Use `navController.currentBackStackEntry?.hasRoute<T>()` to check the current destination in a type-safe manner during UI tests
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user