Fixed
Status Update
No update yet.
Comments
ma...@google.com
ch...@google.com
Looking into this. It's not clear from looking at the code how this can happen. There are two IDs used as tags:
<item type="id" name="metricsStateHolder"/>
<item type="id" name="metricsDelegator"/>
These are assigned unique values at build time. As long as they are only ever used to assign objects of the correct type with those tags, there shouldn't be the kind of classCast exception seen above, and the assignments look correct, eg:
metricsStateHolder = Holder()
rootView.setTag(R.id.metricsStateHolder, metricsStateHolder)
and
delegator = DelegatingFrameMetricsListener(delegates)
decorView.setTag(R.id.metricsDelegator, delegator)
Logging shows ids are indeed unique and off by one, eg:
2131230959, 2131230958
Still investigating
<item type="id" name="metricsStateHolder"/>
<item type="id" name="metricsDelegator"/>
These are assigned unique values at build time. As long as they are only ever used to assign objects of the correct type with those tags, there shouldn't be the kind of classCast exception seen above, and the assignments look correct, eg:
metricsStateHolder = Holder()
rootView.setTag(R.id.metricsStateHolder, metricsStateHolder)
and
delegator = DelegatingFrameMetricsListener(delegates)
decorView.setTag(R.id.metricsDelegator, delegator)
Logging shows ids are indeed unique and off by one, eg:
2131230959, 2131230958
Still investigating
ch...@google.com
Looks like a race condition. The two keys can be used from different threads: the main thread and the FrameMetricsAggregator thread. SparseArray (used by View tags) is not thread safe, so it is theoretically possible for some of the same items in the array to be used by different threads. The API doesn't make that obvious, since different tags should be sorted with different keys, but since it's not thread safe, the same item may be manipulated by two threads in parallel, thus resulting in ill-defined results like what we're seeing here. I'm not able to repro the issue directly in JankStats, but I am able to create such a situation using SparseArray directly, so it seems like this is probably the root cause.
We synchronize access to some structures in JankStats already for other potential race conditions; we should be able to similarly protect access to the tags array for use between threads.
We synchronize access to some structures in JankStats already for other potential race conditions; we should be able to similarly protect access to the tags array for use between threads.
ch...@google.com
The main culprit (called out in that stack trace) was the call to get the state holder from the FrameMetricsAggregator thread. This is only done to remove SingleFrameStates after processing a frame, but there's a simpler way to do that during frame processing code directly, without needing to access the tags from a non-UI thread.
There are various other calls to getTag/setTag that have been modified to ensure they are called from the UI thread, so things should be more solid (in an upcoming fix).
There are various other calls to getTag/setTag that have been modified to ensure they are called from the UI thread, so things should be more solid (in an upcoming fix).
ch...@google.com
ma...@slice.com
Happened to me as well.
According to datadog a user clicked a deeplink that navigates into our app.
java.lang.ClassCastException: com.xxx.ui.main.MainActivity cannot be cast to androidx.metrics.performance.PerformanceMetricsState$Holder
at androidx.metrics.performance.PerformanceMetricsState$Companion.getHolderForHierarchy(Unknown Source:27)
at androidx.metrics.performance.a.onFrameMetricsAvailable(Unknown Source:162)
at android.view.FrameMetricsObserver.onFrameMetricsAvailable(FrameMetricsObserver.java:59)
at android.graphics.HardwareRendererObserver.lambda$notifyDataAvailable$0$HardwareRendererObserver(HardwareRendererObserver.java:93)
at android.graphics.HardwareRendererObserver$$ExternalSyntheticLambda0.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:980)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loopOnce(Looper.java:238)
at android.os.Looper.loop(Looper.java:357)
at android.os.HandlerThread.run(HandlerThread.java:85)
According to datadog a user clicked a deeplink that navigates into our app.
java.lang.ClassCastException: com.xxx.ui.main.MainActivity cannot be cast to androidx.metrics.performance.PerformanceMetricsState$Holder
at androidx.metrics.performance.PerformanceMetricsState$Companion.getHolderForHierarchy(Unknown Source:27)
at androidx.metrics.performance.a.onFrameMetricsAvailable(Unknown Source:162)
at android.view.FrameMetricsObserver.onFrameMetricsAvailable(FrameMetricsObserver.java:59)
at android.graphics.HardwareRendererObserver.lambda$notifyDataAvailable$0$HardwareRendererObserver(HardwareRendererObserver.java:93)
at android.graphics.HardwareRendererObserver$$ExternalSyntheticLambda0.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:980)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loopOnce(Looper.java:238)
at android.os.Looper.loop(Looper.java:357)
at android.os.HandlerThread.run(HandlerThread.java:85)
ma...@google.com
ni...@datadoghq.com
Is there any update on this issue? I can see pending code changes linked to this bug, but they are not yet merged (seems like CR is hanging without any action for a few months already).
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Chet Haase <
Link:
Make use of View tags thread-safe, and simplify delegate scheduling
Expand for full commit details
Make use of View tags thread-safe, and simplify delegate scheduling
We stash a single library-wide instance of our pre draw listener on
the DecorView on lower API levels. This could previously happen from a
couple of different threads, and View tags are not thread safe, which
can cause potential race condition errors if the underlying tag
storage is accessed in parallel from different threads.
This fix posts any changes to both the onPreDrawListener and the tags
to happen from the main thread to make them safe.
This also removes unnecessary logic from the onPreDraw loop itself,
since delegates cannot be scheduled for addition or removal during the
loop due to the synchronized block.
This fix also simplifies logic of singleFrameState removal (it now
happens while processing frames directly, on the following frame),
which gets rid of the need to synchronously get and use the state
holder from the FrameMetrics thread.
Bug: 311218678
Test: Manual testing to verify correct threading behavior, JankStatsTests passes
Relnote: Fix crashes `DelegatingFrameMetricsListener cannot be cast...`
Change-Id: Id891c0cfdd7f45ef9e3b068644a113f39c8fc383
Files:
- M
metrics/metrics-performance/src/androidTest/java/androidx/metrics/performance/test/JankStatsTest.kt - M
metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStats.kt - M
metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi16Impl.kt - M
metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi24Impl.kt - M
metrics/metrics-performance/src/main/java/androidx/metrics/performance/PerformanceMetricsState.kt
Hash: 68264e9d7d70b0af375d6cf4c27a3407657a5b80
Date: Mon Jan 08 17:23:46 2024
cc...@google.com
cc...@google.com
I still see issues in the API24+ impl, reopening.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Chris Craik <
Link:
Improve tag/listener update safety on API 24+
Expand for full commit details
Improve tag/listener update safety on API 24+
Improve JankStats API 24 impl to reduce thread hops and simplify
delegate iteration/adding/removal. This brings the API 24 impl to be
much closer to the API 16 implementation.
Also ensures that delegates and window frame metrics available
listeners are consistently set on main thread.
Test: JankStatsTest
Fixes: 311218678
Change-Id: I2ab7c892ae114708f3cd8e80f180ab73e32b9d11
Files:
- M
metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi24Impl.kt
Hash: f185f92ddcc005dfaa62ab4ed2816faabddc2288
Date: Wed Feb 26 15:03:31 2025
yo...@flipkart.com
Thanks for this.
Any ETA on the new release?
Any ETA on the new release?
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.metrics:metrics-performance:1.0.0-beta02
yo...@flipkart.com
Any expected date of release?
cc...@google.com
This fix was released yesterday with androidx.metrics:metrics-performance:1.0.0-beta02, see
Please try it out and let us know if it doesn't address the problem.
yo...@flipkart.com
Thanks 🙌🙌
Description
androidx.metricsmodule used:metrics-performanceandroidx.metricsversion used:1.0.0-alpha04Devices/Android versions reproduced on: Android 13 (Galaxy S21 FE 5G)
We have a crash in
androidx.metrics:metrics-performance:1.0.0-alpha04reported by our customer