Assigned
Status Update
No update yet.
Comments
cc...@google.com
ma...@google.com
When I run Macrobenchmark via the `connectedCheck` target with info logs on, I can see the arg being set:
```
INFO: Configuring Android Instrumentation driver: android_instrumentation_runtime {
instrumentation_info {
...
args_map {
key: "androidx.benchmark.suppressErrors"
value: "DEBUGGABLE"
}
}
}
```
Attempted to pass the flag via the `-e` option to the `instrument` command of ADB, but no change to error output:
```
$ adb shell am instrument -w com.ring.benchmark/androidx.test.runner.AndroidJUnitRunner -e androidx.benchmark.suppressErrors DEBUGGABLE
...
ERROR: Benchmark Target is Debuggable
```
```
INFO: Configuring Android Instrumentation driver: android_instrumentation_runtime {
instrumentation_info {
...
args_map {
key: "androidx.benchmark.suppressErrors"
value: "DEBUGGABLE"
}
}
}
```
Attempted to pass the flag via the `-e` option to the `instrument` command of ADB, but no change to error output:
```
$ adb shell am instrument -w com.ring.benchmark/androidx.test.runner.AndroidJUnitRunner -e androidx.benchmark.suppressErrors DEBUGGABLE
...
ERROR: Benchmark Target is Debuggable
```
Description
Component used: Macrobenchmark-JUnit4 Version used: 1.2.4 through 1.3.0-beta01 Devices/Android versions reproduced on: Android API 29
For some reason I am unable to get Macrobenchmark to run properly on hardware. The benchmarks themselves run as expected but then crashes after the first iteration. I have traced the problem down to a section where the per-iteration Perfetto trace is being moved from the apps /cache directory to /files/test_data. This move apparently fails silently without and we then move on to attempting to open the (not) moved file and crash on a FileNotFound exception.
After some reading up on this and I concluded that it seems to be related to the movement of files across mount points in Linux. It is strange though as I can see that there should be detection systems and workarounds for this issue in the code, however, in my case they do not seem to be sufficient.
The problem and stack trace is identical to the following issue published on the Performance Sample Github,https://github.com/android/performance-samples/issues/254 .
This might be a configuration problem on my end, and if anyone has an idea what could be causing this issue I would love to hear it. In any case, I would argue that we should never fail in this manner. Perhaps an attempt should be made to copy the file instead if we are unsuccessful in opening it at the destination location?