Gray Mackall c0b808c9ed
Unmodified android sdk bundle (#179647)
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>
2025-12-15 20:18:31 +00:00
..
2025-11-26 01:10:39 +00:00
2025-11-26 01:10:39 +00:00
2025-11-25 00:41:40 +00:00

Macrobenchmarks

Performance benchmarks use either flutter drive or the web benchmark harness.

Mobile benchmarks

Cull opacity benchmark

To run the cull opacity benchmark on a device:

flutter drive --profile -t test_driver/run_app.dart --driver test_driver/cull_opacity_perf_test.dart

Results should be in the file build/cull_opacity_perf.timeline_summary.json.

More detailed logs should be in build/cull_opacity_perf.timeline.json.

Cubic bezier benchmark

To run the cubic-bezier benchmark on a device:

flutter drive --profile -t test_driver/run_app.dart --driver test_driver/cubic_bezier_perf_test.dart

Results should be in the file build/cubic_bezier_perf.timeline_summary.json.

More detailed logs should be in build/cubic_bezier_perf.timeline.json.

Backdrop filter benchmark

To run the backdrop filter benchmark on a device: To run a mobile benchmark on a device:

flutter drive --profile -t test_driver/run_app.dart --driver test_driver/[test_name]_test.dart

Results should be in the file build/[test_name].timeline_summary.json.

More detailed logs should be in build/[test_name].timeline.json.

The key [test_name] can be:

  • animated_placeholder_perf
  • backdrop_filter_perf
  • color_filter_and_fade_perf
  • cubic_bezier_perf
  • cull_opacity_perf
  • fading_child_animation_perf
  • imagefiltered_transform_animation_perf
  • multi_widget_construction_perf
  • picture_cache_perf
  • post_backdrop_filter_perf
  • simple_animation_perf
  • textfield_perf
  • fullscreen_textfield_perf

E2E benchmarks

(On-going work)

E2E-based tests are driven independent of the host machine. The following tests are E2E:

  • cull_opacity_perf.dart
  • multi_widget_construction_perf

These tests should be run by:

flutter drive --profile -t test/[test_name]_e2e.dart --driver test_driver/e2e_test.dart

Web benchmarks

Web benchmarks are compiled from the same entry point in lib/web_benchmarks.dart.

How to write a web benchmark

Create a new file for your benchmark under lib/src/web. See bench_draw_rect.dart as an example.

Choose one of the two benchmark types:

  • A "raw benchmark" records performance metrics from direct interactions with dart:ui with no framework. This kind of benchmark is good for benchmarking low-level engine primitives, such as layer, picture, and semantics performance.
  • A "widget benchmark" records performance metrics using a widget. This kind of benchmark is good for measuring the performance of widgets, often together with engine work that widget-under-test incurs.
  • A "widget build benchmark" records the cost of building a widget from nothing. This is different from the "widget benchmark" because typically the latter only performs incremental UI updates, such as an animation. In contrast, this benchmark pumps an empty frame to clear all previously built widgets and rebuilds them from scratch.

For a raw benchmark extend RawRecorder (tip: you can start by copying bench_draw_rect.dart).

For a widget benchmark extend WidgetRecorder (tip: you can start by copying bench_simple_lazy_text_scroll.dart).

For a widget build benchmark extend WidgetBuildRecorder (tip: you can start by copying bench_build_material_checkbox.dart).

Pick a unique benchmark name and class name and add it to the benchmarks list in lib/web_benchmarks.dart.

How to run a web benchmark

Web benchmarks can be run using flutter run in debug, profile, and release modes, using either the CanvasKit or the Skwasm rendering backend. Note, however, that running in debug mode will result in worse numbers. Profile mode is useful for profiling in Chrome DevTools because the numbers are close to release mode and the profile contains unobfuscated names.

Example:

cd dev/benchmarks/macrobenchmarks

# Runs in profile mode
flutter run --profile -d web-server lib/web_benchmarks.dart

You can also run all benchmarks exactly as the devicelab runs them:

cd dev/devicelab

# Runs using the CanvasKit renderer
../../bin/cache/dart-sdk/bin/dart bin/run.dart -t bin/tasks/web_benchmarks_canvaskit.dart

Frame policy test

File test/frame_policy.dart and its driving script test_driver/frame_policy_test.dart are used for testing fullyLive and benchmarkLive policies in terms of its effect on WidgetTester.handlePointerEventRecord.