Obsolete
Status Update
No update yet.
Comments
vi...@gmail.com
Thank you for reporting this issue. We have shared this with our engineering team and will update this issue with more information as it becomes available.
mr...@gmail.com
@2 This bug occurs even if the check is inside onActivityResult, yet I've tested it on Android 7.1.2 and below, and it doesn't occur there.
I've also noticed that the check works fine if I change the orientation after returning from the settings screen (meaning the activity was re-created)
I've also noticed that the check works fine if I change the orientation after returning from the settings screen (meaning the activity was re-created)
bi...@gmail.com
For resolving "draw-on-top feature cannot be toggled", you need to add "android.permission.SYSTEM_ALERT_WINDOW" permission in Android Manifest file.
sm...@android.com
@4 Then the bug is different for this case: why open this screen, if this permission isn't even available for this app... It should do something else. Maybe throw an exception that tells that the permission is missing from the manifest.
Also, the main isssue does exist: the check of the permission always returns false in the case I've shown.
Also, the main isssue does exist: the check of the permission always returns false in the case I've shown.
mm...@commonsware.com
@4 Bug exists on DP3 too (OPP3.170518.006)
sa...@google.com
I can confirm the Settings.canDrawOverlays() always returns false when called from within Activity.onActivityResult() (latest Android O Emulator x86). And no such problems on earlier versions of Android.
However, in onActivityResult(), if instead I post a Runnable to the main thread handler, and call canDrawOverlays() in that, then it returns true. So I guess onActivityResult() is being called a little too early.
However, in onActivityResult(), if instead I post a Runnable to the main thread handler, and call canDrawOverlays() in that, then it returns true. So I guess onActivityResult() is being called a little too early.
Description
For example, READ_LOGS is now defined as android:protectionLevel="signature|system|development", but this new pipe syntax, let alone the "development" value, are undocumented.