Status Update
Comments
cc...@google.com <cc...@google.com> #2
I had created the same issue with wrong component earlier
en...@meta.com <en...@meta.com> #3
I noticed in the sample project you're using an emulator with api30.
We found a bug that is being fixed related to api 30 emulator and baseline profile generation.
Could you please try:
- Updating the baseline profile gradle plugin version (alpha14 is the latest as we speak)
- Change api version to 33 (or anything > 30)
Let me know if this works!
Thanks!
cc...@google.com <cc...@google.com> #4
en...@meta.com <en...@meta.com> #5
Thanks for suggestions and I could generate profiles in few scenarios. Few observations:
-
The issue seems to be specific to ARM devices running in FTL, regardless of the API version. When testing the application on a physical device (from FTL) with API 33, the profiles were successfully generated. This suggests that the problem lies in the ARM device profiles not being located where the extraction process expects them to be. It's worth investigating whether this issue originates from the plugin itself and whether it requires attention and resolution.
-
The current behavior of the
BaselineProfileConsumerExtension
does not save the optionssaveInSrc
andbaselineProfileOutputDir
in the designated locations. This inconsistency exists when running in FTL managed device. It would be beneficial to enhance the plugin's functionality to ensure consistent behavior across different environments. This improvement would ensure that the specified options for saving profiles are reliably honored, regardless of the testing environment being used.
en...@meta.com <en...@meta.com> #6
Thanks for your observations.
About your second point: The plugin does not make any distinction around what device the baseline profile generators run, when it come to saveInSrc
and baselineProfileOutputDir
. Could you please describe the issue more in detail? Or update your sample project if you'd like, so I can give a look.
ap...@google.com <ap...@google.com> #7
Actually could you also please check logcat for the devices where it wasn't generated and look for anything related to dex2oat
? I'm wondering if the issue is only in the emulators rather than the gradle task.
cc...@google.com <cc...@google.com> #8
I am trying to save it in the source after generating by following the
I have attached the sample project (Macrobenchmark) and included comments in the build.gradle.kts
file in baselineProfile
module.
cc...@google.com <cc...@google.com> #9
I re-checked the logs related to dex2oat
and could see this mismatch warning generated when it's running:
06-01 21:39:39.930: V/installd(463): Running /apex/com.android.art/bin/dex2oat64 in=base.apk out=/data/app/~~Sc5l67aRwmVS1G6tKcZP3w==/com.example.macrobenchmark.target-B8yQDmvRV9qvZZP0CfMurg==/oat/arm64/base.odex
...
06-01 21:39:39.941: W/dex2oat64(9628): Mismatch between dex2oat instruction set features to use (ISA: Arm64 Feature string: a53,crc,-lse,-fp16,-dotprod,-sve) and those from CPP defines (ISA: Arm64 Feature string: -a53,-crc,-lse,-fp16,-dotprod,-sve) for the command line:
06-01 21:39:39.941: W/dex2oat64(9628): /apex/com.android.art/bin/dex2oat64 --zip-fd=7 --zip-location=base.apk --oat-fd=8 --oat-location=/data/app/~~Sc5l67aRwmVS1G6tKcZP3w==/com.example.macrobenchmark.target-B8yQDmvRV9qvZZP0CfMurg==/oat/arm64/base.odex --input-vdex-fd=9 --output-vdex-fd=10 --app-image-fd=13 --image-format=lz4 --profile-file-fd=12 --swap-fd=11 --classpath-dir=/data/app/~~Sc5l67aRwmVS1G6tKcZP3w==/com.example.macrobenchmark.target-B8yQDmvRV9qvZZP0CfMurg== --class-loader-context=PCL[]{} --instruction-set=arm64 --instruction-set-features=default --instruction-set-variant=generic --compiler-filter=speed-profile --compilation-reason=cmdline --max-image-block-size=524288 --resolve-startup-const-strings=true --generate-mini-debug-info --runtime-arg -Xtarget-sdk-version:33 --runtime-arg -Xhidden-api-policy:enabled --runtime-arg -Xms64m --runtime-arg -Xmx512m
...
06-01 21:39:39.963: I/dex2oat64(9628): /apex/com.android.art/bin/dex2oat64 --input-vdex-fd=9 --output-vdex-fd=10 --profile-file-fd=12 --classpath-dir=/data/app/~~Sc5l67aRwmVS1G6tKcZP3w==/com.example.macrobenchmark.target-B8yQDmvRV9qvZZP0CfMurg== --class-loader-context=PCL[]{} --compiler-filter=speed-profile --compilation-reason=cmdline --max-image-block-size=524288 --resolve-startup-const-strings=true --generate-mini-debug-info
which is also present when running on non-ARM devices. I cannot say if this is an ARM specific issue or not, but this issue is prominent when running on ARM devices.
na...@google.com <na...@google.com> #10
I was looking for something like dex2oat
not found. This is what I suspect should happen on the ARM device api 30 where it doesn't work.
In the log you posted here it seems that it's working (although I'm not sure about that mismatch).
Description
Component used: Version used: Benchmark Macro v.1.2.3 Devices/Android versions reproduced on: Android emulator (API 30)
I am often seeing the error: "Skipping results from iter $iteration, it didn't capture all metrics" from emulator runs of cold start tests. I currently have my test set to 10 iterations and get any where from 2-9 metrics in the output json file although I see 10 successful startups in the UI and. in the Benchmark logs.
If this is a bug in the library, we would appreciate if you could attach: