diff --git a/docs/platforms/android/New-Android-version.md b/docs/platforms/android/New-Android-version.md index eabe19e5b801e..14b6fcbfceae4 100644 --- a/docs/platforms/android/New-Android-version.md +++ b/docs/platforms/android/New-Android-version.md @@ -4,6 +4,9 @@ go/flutter-android-new-api-level ## Objective Provide a list of areas to consider and examples of former work for how to update flutter to support a new version of the android API. This happens every fall and flutter developers expect to build against the latest versions quickly after they are available. ### Overview +#### Bump compile and target sdk versions in samples +Samples, expecially add to app samples, represent apps that mirror the first types of users we see adopt new android apis. +Example pr https://github.com/flutter/samples/pull/2368 #### New Android features New android features can require a broad spectrum of work. Some will require nothing from flutter. Some will require a lot of work, such as the support for “back preview”. The android team generally needs to be aware and schedule work ahead of time. #### Update Gradle/AGP support @@ -70,4 +73,4 @@ Make a github issue describing that there is a new android release that needs to Fill out the justification with b/12345 - (the form requires a buganizer link, and the addition of b/12345 satisfies this). Reach out to someone on the infra team to get your request approved Run the [create_cipd_packages.sh script](https://github.com/flutter/engine/blob/a2adaa39a2c35d1ab23394d550c9a7e50fe41fe9/tools/android_sdk/create_cipd_packages.sh) with your desired version tag (note that there is a .ci.yaml validation step that requires this version tag to be a combination of lowercase letters and numbers). The script pulls the version that will be uploaded from the packages.txt file in the same subdirectory. -The remaining steps are to consume the changes in the buildroot, and then consume those buildroot changes in the engine. \ No newline at end of file +The remaining steps are to consume the changes in the buildroot, and then consume those buildroot changes in the engine.