Status Update
No update yet.
Comments
cc...@google.com
dv...@gmail.com
dv...@gmail.com
Branch: androidx-master-dev
commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020
Create an interface for layouts that can be opened
Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.
Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19
M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java
cc...@google.com
There's a lot of data loss in that trace - if you open up the "info and stats" tab in ui.perfetto.dev, it shows that there is data loss with
I'm not sure if there's any configuration to be improved on the kernel side (maybe the Perfetto team can say if that's a common issue) but one big problem in this configuration is that macrobenchmark traces all apps (with atrace) by default on API 28+ to increase general visiblity and avoid configuration issues, but we should be able to avoid that in most cases, which may entirely solve the problem.
We'll also consider surfacing this sort of error in androidx.benchmark more generally, so it's more obvious when something is significantly wrong, like all of this data loss.
la...@google.com
Lalit, let me know if this might be something we're doing obviously wrong, if not I can add some logging to see if we're failing to append as many bytes as we expect, or try just storing the in-memory trace data separately.
These errors happen if a packet is emitted with write_into_file/flush_period_ms enabled but you are not respecting the flush in your injected packets. Trace processor makes use of knowledge of flushes in the trace to perform a "windowed sorting" algorithm
Unless you're being clever about appending your sythentic packets in the "right" place (i.e. approximately close to the timestamp where the "real" events in the trace are located), trace processor rejects packets it sees out of order.
I'm not sure if there's any configuration to be improved on the kernel side (maybe the Perfetto team can say if that's a common issue)
On modern devices, the default configuration of buffer sizes might be too small. In our internal configs, we've switched the kernel buffer to be 4MB per CPU (i.e. buffer_size_kb: 4096). This is only appropriate for modern devices though with 6GB+ RAM. On lower end devices, this would be too aggressive.
There's also an open bug we're considering implementing to switch our reads of the ftrace buffers to be percentage based (
dv...@gmail.com
so, will you solve this problem? when will you solve this problem?
dv...@gmail.com
So , I have to enlarge the trace buffer ( My device has 12GB memory), remove some trace event
Where can I get this project source code ? androidx.benchmark:benchmark-macro
cc...@google.com
Did the tracing buffer increase improve the problem?
Where can I get this project source code ? androidx.benchmark:benchmark-macro
Here:
or mirrored on github:
If you want to experiment with different perfetto capture configs you can also use this API:
dv...@gmail.com
thank you
dv...@gmail.com
I have a question about perfetto command.
as I found that, the data sources wasn't started after just run the perfetto command so I want to use --background-wait options, to let perfetto wait data sources started , then return.
I also worry about perfetto command process would killed by lmk, so I want to use detach mode to run perfetto, but --background-wait and detach mode are mutually exclusive.
how to achieve my goal: 1、return until all data sources start, 2、 run in background
la...@google.com
If perfetto is started from an adb shell, it cannot be killed by LMKD. So you can safely use --background-wait without worrying.
--detach is realy reserved exclusively for the System Tracing app and should not be used by others.
dv...@gmail.com
dv...@gmail.com
thank you
dv...@gmail.com
It works after enlarge the buffer size and always use --background-wait option
( I have used wsl in windows , following the directions in
Thank you.
by the way, is there better way to simulate high system loads in android during benchmark test?
ap...@google.com
Branch: androidx-main
commit 2bb16072e48a70b44cb208b2c13dbecb79ce66f3
Author: Chris Craik <ccraik@google.com>
Date: Mon Mar 18 14:48:22 2024
Use --background-wait on API 33+
Bug: 310760059
Test: ./gradlew bench:b-m:cC
Test: manually confirmed API 33 has --background-wait, 32 does not
Relnote: "Enable blocking start on Perfetto trace record to reduce
risk of missing data at beginning of trace. Only supported on API
33+."
Change-Id: Ie6e417ad248b431ebf6096e2865265d51553be7f
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoHelper.kt
Description
Component used:MacrobenchmarkRule Version used:1.20 Devices/Android versions reproduced on: OPPO Find N3
If this is a bug in the library, we would appreciate if you could attach:
As proper marcrobenchmark， I dedicated to find out the user perceived janks.
According to some studies, it should be more than 5 consecutive jank frames, or a single jank frame that's more than 5 frames time.
And I add some loads during macrobenchmark testing.
however, when I add some loads(for example, let some app running in background, the system becomes slow, the perfetto command started /stoped by macrobenchmarkrule can't capture the full perfetto trace which happens between measureBlock.
I checked trace, found perfetto command started by macrobenchmark running in little cpu cores. That maybe the cause for the loss of perfetto trace during high system loads.
I still found that, If I keep a perfetto trace running outside macrobenchmark, It merely happens that losing the traces during marcobenchmark ?
can you fix that?