Status Update
Comments
vi...@google.com <vi...@google.com> #2
Android 5.0, 5.1: it shows context menu at top of screen, not as popup. See screenshots.
Android framework doesn't support floating toolbar before 23. So this is intended behavior.
The crash information suggests that this is an error from Snapshot. chuckj@ can you please take a look? I don't know what exactly caused the readError
in Snapshot, any suggestions? Thanks a lot!
se...@gmail.com <se...@gmail.com> #3
This looks like another instance of 193006595 which I am looking at now.
ar...@gmail.com <ar...@gmail.com> #4
Branch: androidx-main
commit beeb84e7be604088ad40e080a8d0adb1bacbf695
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Thu Jul 08 10:04:28 2021
Remove updating the transparent snapshot
A transparent snapshot is create for the block exeucted by
`Snapshot.observe()` which registers read and write observers
but without creating a snapshot. The code to advance the
global snapshot, however, created a new transparent snapshot in
an attempt to update it to the new global snapshot it just
created. This is not necessary, however, as the transparent
snapshot will retrieve the current global snapshot from
`currentGlobalSnapshot` instead of `previousSnapshot` if
`previousSnapshot` is `null`. With the previous code, if the
global snapshot is advanced by applying a new snapshot the
"updated" transparent snapshot will be left referring to an
older snapshot instead of the most recent global snapshot.
Any snapshot object created in the newly applied snapshot
will throw an exception when it is accessed, as reported in
the bugs. The solution is to remove the apparent vetiagal code.
Test: ./gradlew :compose:r:r:tDUT
Fixes:
Change-Id: I2c0d0b8f57bf70e5a98ea36ed141d97142a5e53e
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/snapshots/Snapshot.kt
M compose/runtime/runtime/src/test/kotlin/androidx/compose/runtime/snapshots/SnapshotTests.kt
do...@gmail.com <do...@gmail.com> #5
ak...@google.com <ak...@google.com> #6
I hit the same thing on Wear, as a workaround until there is a way to achieve this programmatically this permission can be granted via adb:
adb shell appops set --uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow
ar...@gmail.com <ar...@gmail.com> #7
#6: Thank you, but specially on Android TV, asking users to do this is going to cause a lot of confusion since they would need to connect with a PC of some sort and it's not trivial.
Now that this issue is on Google's radar, is it possible to gain some momentum and still patch existing Android versions?
so...@google.com <so...@google.com> #8
There are no TV devices on Android 13, as we will go from Android 12 -> Android 14 for TV devices. So I am not sure how this was tested on Android 13 for TV. We will check if this has been fixed on Android 14 for TV and then back port to older versions.
ar...@gmail.com <ar...@gmail.com> #9
#8 I believe #3 tested it on an emulator, since there's an Android TV 13 image available.
Thank you for checking on backporting. Since we believe it was fixed in A13, it's a matter of figuring out how to backport to A11/A12 and releasing for existing devices.
so...@google.com <so...@google.com> #10
Ok. We have completed the backporting to R and S on TV
13...@qq.com <13...@qq.com> #11
ar...@gmail.com <ar...@gmail.com> #12
I'm happy to report that the latest update to Chromecast with Google TV (still Android 12) fixes the issue, and now the "install unknown apps" permission screen shows up correctly and our app can be selected. Thank you to all involved who backported the fix.
vi...@google.com <vi...@google.com> #13
The issue has been fixed and watch out for future releases.
hi...@gmail.com <hi...@gmail.com> #14
Where can I get the release with the fix for Wear OS? I am in a hurry to release an app.
Thanks
13...@qq.com <13...@qq.com> #15
he...@gmail.com <he...@gmail.com> #16
The fix that is backported is not for Wear OS but for TV. I'm not sure when they will be fixing the issue on Wear OS.
ko...@gmail.com <ko...@gmail.com>
ar...@gmail.com <ar...@gmail.com> #17
Please fix this for Wear OS as well, which was the original reported target OS.
Description
In Android 11+, I use : try { Log.d(TAG, "requestPermission: try");
But error : android.content.ActivityNotFoundException: No Activity found to handle Intent { act=android.settings.MANAGE_APP_ALL_FILES_ACCESS_PERMISSION