Status Update
No update yet.
Comments
al...@google.com
al...@google.com
Thanks for the detailed analysis and sample. I've prepared a CL, but I'd also be happy to review an external contribution since you already went through the trouble of identifying a fix. Just let me know here.
al...@google.com
If you have a CL ready go for it.
That being said, I just went down git history and found when this was introduced:
As you can see, this was introduced to fix a "memory leak" though I don't quite understand why creating a new callback wrapper for every setSupportActionBar() call is a problem.
bu...@google.com
Branch: androidx-main
commit 200ccecbc8c7c5ba555e7fa15890edff67affb58
Author: Alan Viverette <alanv@google.com>
Date: Fri Apr 30 14:55:07 2021
Fix case where setSupportActionBar overwrites the window callback
RelNote: """Fix scenario where calling setSupportActionBar after setting the
window callback would overwrite the callback."""
Test: SupportActionBarTestCase
Fixes: 186791590
Change-Id: Ie43eedf8322caa44e7b201a95cbc64197953e020
A appcompat/appcompat/src/androidTest/java/androidx/appcompat/app/SupportActionBarTestCase.kt
M appcompat/appcompat/src/main/java/androidx/appcompat/app/AppCompatDelegateImpl.java
bu...@google.com
se...@gmail.com
je...@gmail.com
je...@gmail.com
po...@gmail.com
there's no guarantee you'll get the same callback (e.g. it might have been wrapped again).
Do you mean the app code may have wrapped the callback?
Description
Public class
androidx.appcompat.graphics.drawable.AnimatedStateListDrawableCompatinherits some public methods from its restricted parent classandroidx.appcompat.graphics.drawable.StateListDrawable. Let's inline those methods intoAnimatedStateListDrawableso they're not hidden.