9e273d5e6e
🚫 **BLOCKED** : Do not merge until
https://github.com/flutter/flutter/issues/161261 (additional test
coverage).
---
This PR eliminates (1) `scenario_app/android`, and all references to an
Android `scenario_app`, including documentation, CI configuration, build
rules, test runner, Android-side test application, and (2), to verify
and disambiguate the remains, renames the folder `ios_scenario_app`,
which is now accurate.
It also eliminates elements that were _only_ used in the Android-side
scenario_app, such as Firebase Test Lab uploading.
I would be open to doing this in phases if we thought it was better to
do so, but given its mostly a mechanical change (and by renaming the
directory, references can be checked merely by looking for
`/\bscenario_app/`, I believe this is safe to iterate on and eventually
merge after the holidays.
## Background
As of the merged mono-repo, there is no longer a requirement for the
engine to be testable as a standalone unit.
As an example,
[`%ENGINE%/testing/scenario_app`](3762f2e973/engine/src/flutter/testing/scenario_app),
which was intended to _emulate_ the Flutter framework (and some of
`flutter_tools` tooling), load the iOS and Android embedder, and run
various "scenarios" (which ran a combination of `dart:ui` code and
Android Java/iOS Obj-C) verifying golden-file screenshots.
Instead, it is now possible to write and run _real_ (full) Flutter apps
the same way that an end-user (or our own tests) would. One such example
is
[`dev/native_driver_test`](https://github.com/flutter/flutter/tree/master/dev/integration_tests/native_driver_test),
which is a full-fledged Flutter app, which uses standard tooling (i.e.
`flutter`), to test most of the same elements that previously were only
tested in the Android version of `scenario_app`.
4.7 KiB
When new Android versions become available, the following steps should be taken in order to fully support the new API version in the Flutter engine. These steps only change the engine to build against and target the new API and do not guarantee that everything works with the changes in the new Android API.
Update the Buildroot:
In build/config/android/config.gni, edit default_android_sdk_version and default_android_sdk_build_tools_version to the new Android version.
NOTE: There is an ongoing effort to move the flutter/buildroot repo into the flutter/engine repo, so this file may have moved by the time you are following these instructions.
Upload new SDK and other dependencies to CIPD:
Flutter now includes a script to download, package, and upload the Android SDK to CIPD. These CIPD packages are then used as dependencies by the Flutter engine and recipes (go/flutter-luci-recipes) so that there is a stable archived version of the Android SDK to depend on. The script is located in the Flutter engine repo under tools/android-sdk/create_cipd_packages.sh.
To upload packages to CIPD (either with the script or manually), the flutter-cipd-writers role is required in order to complete this operation. Googlers can apply for access here. Once this role is granted, cipd auth-login must be run in order for cipd to update the user's available roles.
Edit tools/android-sdk/packages.txt to refer to the updated versions you want. The format for each line in packages.txt is <package_name>:<subdirectory_to_upload>. Typically, each <package_name> should be updated to the latest available version which can be found with the sdkmanager --list --include_obsolete. sdkmanager can be found in your commandline-tools package of the android sdk. Additionally, set the ANDROID_SDK_ROOT environment variable to your local Android SDK installation.
The script must be run on a Linux or Mac host. Run:
`$ cd tools/android-sdk && ./create_cipd_packages.sh <new_version_tag> <path_to_your_local_android_sdk>`
This script will download and re-upload the entire SDK, so it may take a long time to complete. cmdline-tools should be installed in your local SDK as the script uses sdkmanager. Once the CIPD packages are finished uploading, you can update the SDK version tag used in .ci.yaml, DEPS, and elsewhere as described below.
It is no longer recommended to upload CIPD Android SDK packages manually, but if it must be done, run the following commands to zip and upload each package to CIPD:
`$ cipd create -in <your-android-dir>/Android/sdk/<some_package> -name flutter/android/sdk/<some_package> -tag version:<new-version-tag>`
Typically, <your-android-dir> is in your home directory under ~/Library/Android. The <new-version-tag> is what you will use to specify the new package you uploaded in the Flutter engine DEPS file.
Update the Engine:
Update the compile and target SDK versions we use
Modify the following files as described:
DEPS: Roll buildroot hash to that of the PR you used to update the buildrootDEPS: Change the version parameter underflutter/android/sdk/all/${{platform}}to the newly uploaded CIPD version tag, e.g.'version': 'version:30r2'tools/javadoc/gen_javadoc.py: Bump the reference toandroid-XXinclasspathto the latest version.tools/cipd/android_embedding_bundle/build.gradle: BumpcompileSdkVersion XXto the latest version.shell/platform/android/test_runner/build.gradle: BumpcompileSdkVersion XXto the latest version.shell/platform/android/AndroidManifest.xml: Bumpandroid:targetSdkVersion=XXto the latest version.testing/android/native_activity/native_activity.gni: Bump the reference tobuild-tools/XXinandroid_buildtoolsto the latest build-tools version and the reference toandroid-XXinandroid_jarto the latest version.
This list may become outdated, so be sure to change any references to the old SDK version to the latest version in build.gradle files across the repo.
Next Steps: Update the Framework, Examples and Samples
- Templates in the framework: Change
targetSdkVersionin variousbuild.gradle.tmplfiles to use the new API version - Examples and samples: Change
targetSdkVersioninandroid/app/build.gradlefor each project to the new API version.