c0b808c9ed
Changes our cipd hosted android sdk+ndk bundle to no longer modify directory structure from what Android directly provides, allowing AGP to find the ndk automatically and preventing downloading. 1. Changes the `create_cipd_packages.sh` script so we don't move the ndk 2. Uses the new script to upload a [36v4unmodified](https://chrome-infra-packages.appspot.com/p/flutter/android/sdk/all/linux-amd64/+/version:36v4unmodified) bundle 3. Changes DEPS+ci.yaml to reference the new bundle 4. Changes GN build rules accordingly 5. Removes special config in existing build.gradle files to point at the location of the ndk - agp should now know where it is without conig 6. For some tests, passes in an environment variable pointing to the ndk location, to override the environment variable passed by the recipes. This variable is respected by the tool, so the recipes passing it, pointing to the wrong place, is problematic. After this change lands we can stop passing it in the recipes, and then we can remove this special config in the tests. But adding it temporarily allows us to make this change without coordinating a recipes change at the same moment, and probably breaking things out of band. Logs from a random postsubmit run of `Mac build_android_host_app_with_module_aar` on the tree currently: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8695664517253382913/+/u/run_build_android_host_app_with_module_aar/stdout We see > [2025-12-12 10:49:49.223087] [STDOUT] stdout: Checking the license for package NDK (Side by side) 28.2.13676358 in /Volumes/Work/s/w/ir/cache/android/sdk/licenses [2025-12-12 10:49:49.223221] [STDOUT] stdout: License for package NDK (Side by side) 28.2.13676358 accepted. [2025-12-12 10:49:49.223268] [STDOUT] stdout: Preparing "Install NDK (Side by side) 28.2.13676358 v.28.2.13676358". [2025-12-12 10:50:14.093824] [STDOUT] stdout: "Install NDK (Side by side) 28.2.13676358 v.28.2.13676358" ready. [2025-12-12 10:50:14.093909] [STDOUT] stdout: Installing NDK (Side by side) 28.2.13676358 in /Volumes/Work/s/w/ir/cache/android/sdk/ndk/28.2.13676358 [2025-12-12 10:50:14.093947] [STDOUT] stdout: "Install NDK (Side by side) 28.2.13676358 v.28.2.13676358" complete. [2025-12-12 10:50:14.410724] [STDOUT] stdout: "Install NDK (Side by side) 28.2.13676358 v.28.2.13676358" finished. Example of no longer downloading: Logs from a presubmit run: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8695732180931529361/+/u/run_build_android_host_app_with_module_aar/stdout We don't see these logs. We still see android build tools downloading - we can probably tackle that in another pr. ## Pre-launch Checklist - [ ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [ ] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [ ] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [ ] I signed the [CLA]. - [ ] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [ ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [ ] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [ ] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md --------- Co-authored-by: DoLT <dolt@guide.inc> Co-authored-by: Gray Mackall <mackall@google.com> Co-authored-by: John "codefu" McDole <john@mcdole.org>
android_engine_test
This directory contains a sample app and tests that demonstrate how to use the (experimental) native Flutter Driver API to drive Flutter apps that run on Android devices or emulators, interact with and capture screenshots of the app, and compare the screenshots against golden images.
Caution
This test suite is a very end-to-end suite that is testing a combination of the graphics backend, the Android embedder, the Flutter framework, and Flutter tools, and only useful when the documentation and naming stays up to date and is clearly actionable.
Please take extra care when updating the test suite to also update the REAMDE.
How it runs on CI (LUCI)
See dev/bots/suite_runners/run_android_engine_tests.dart, but tl;dr:
# TIP: If golden-files do not exist locally, this command will fail locally.
SHARD=android_engine_vulkan_tests bin/cache/dart-sdk/bin/dart dev/bots/test.dart
SHARD=android_engine_opengles_tests bin/cache/dart-sdk/bin/dart dev/bots/test.dart
Running the apps and tests
Each lib/{prefix}_main.dart file is a standalone Flutter app that you can run
on an Android device or emulator.
flutter_rendered_blue_rectangleexternal_texture/surface_producer_smiley_faceexternal_texture/surface_texture_smiley_faceplatform_view/hybrid_composition_platform_viewplatform_view/texture_layer_hybrid_composition_platform_viewplatform_view/virtual_display_platform_viewplatform_view_tap_color_change
flutter_rendered_blue_rectangle
This app displays a full screen blue rectangle. It mostly serves as a test that Flutter can run at all on the target device, and that the Flutter (native) driver can take a screenshot and compare it to a golden image. If this app or test fails, it's likely none of the other apps or tests will work either.
# Run the app
$ flutter run lib/flutter_rendered_blue_rectangle_main.dart
# Run the test
$ flutter drive lib/flutter_rendered_blue_rectangle_main.dart
external_texture/surface_producer_smiley_face
This app displays a full screen rectangular deformed smiley face with a yellow
background. It tests the SurfaceProducer API end-to-end, including historic regression cases around
backgrounding the app, trimming memory, and resuming the app.
# Run the app
$ flutter run lib/external_texture/surface_producer_smiley_face_main.dart
# Run the test
$ flutter drive lib/external_texture/surface_producer_smiley_face_main.dart
external_texture/surface_texture_smiley_face
This app displays a full screen rectangular deformed smiley face with a yellow
background. It tests the SurfaceTexture API end-to-end.
# Run the app
$ flutter run lib/external_texture/surface_texture_smiley_face_main.dart
# Run the test
$ flutter drive lib/external_texture/surface_texture_smiley_face_main.dart
platform_view/hybrid_composition_platform_view
This app displays a blue orange gradient, the app is backgrounded, and then resumed. It tests the Hybrid Composition implementation.
# Run the app
$ flutter run lib/platform_view/hybrid_composition_platform_view_main.dart
# Run the test
$ flutter drive lib/platform_view/hybrid_composition_platform_view_main.dart
platform_view/texture_layer_hybrid_composition_platform_view
This app displays a blue orange gradient, the app is backgrounded, and then resumed. It tests the Texture Layer Hybrid Composition implementation.
# Run the app
$ flutter run lib/platform_view/texture_layer_hybrid_composition_platform_view_main.dart
# Run the test
$ flutter drive lib/platform_view/texture_layer_hybrid_composition_platform_view_main.dart
platform_view/virtual_display_platform_view
This app displays a blue orange gradient, the app is backgrounded, and then resumed. It tests the Virtual Display implementation.
# Run the app
$ flutter run lib/platform_view/virtual_display_platform_view_main.dart
# Run the test
$ flutter drive lib/platform_view/virtual_display_platform_view_main.dart
platform_view_tap_color_change
This app displays a blue rectangle, using platform views, which upon being tapped (natively, not by Flutter), changes from blue to red.
# Run the app
$ flutter run lib/platform_view_tap_color_change_main.dart
# Run the test
$ flutter drive lib/platform_view_tap_color_change_main_test.dart
Deflaking
Use tool/deflake.dart <path/to/lib/main.dart> to, in 1-command:
- Build an APK.
- Establish a baseline set of golden-files locally.
- Run N tests (by default, 10) in the same state, asserting the same output.
For example:
dart tool/deflake.dart lib/flutter_rendered_blue_rectangle_main.dart
For more options, see dart tool/deflake.dart --help.