Verified
Status Update
No update yet.
Comments
yu...@chromium.org
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.
no...@chromium.org
@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)
no...@chromium.org
For resolving "draw-on-top feature cannot be toggled", you need to add "android.permission.SYSTEM_ALERT_WINDOW" permission in Android Manifest file.
no...@chromium.org
@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.
bu...@chromium.org
@4 Bug exists on DP3 too (OPP3.170518.006)
no...@chromium.org
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.
dh...@google.com
On further inspection, you need to wait about a second (in my few tests, between 900ms and 1300ms running the Android O DP3 emulator on a Late 2013 MBP) before canDrawOverlays() begins to return true.
bu...@chromium.org
@8 Even if it was 1ms, it's still a bug. The check should return the immediate, correct answer: the app got the permission.
Not even that, but after going back from the draw-on-top screen on the second time, it should get the new value, because it hasn't changed since.
Not even that, but after going back from the draw-on-top screen on the second time, it should get the new value, because it hasn't changed since.
no...@chromium.org
Please compare:
=1=
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + getPackageName()));
startActivityForResult(intent, ACTION_MANAGE_OVERLAY_PERMISSION_REQUEST_CODE);
--> then Settings.canDrawOverlays returns false;
=2=
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION));
startActivityForResult(intent, ACTION_MANAGE_OVERLAY_PERMISSION_REQUEST_CODE);
--> then Settings.canDrawOverlays returns false;
In case of =2= there is additional step for selecting my app from the list of apps with manage overlay permissions.
=1=
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + getPackageName()));
startActivityForResult(intent, ACTION_MANAGE_OVERLAY_PERMISSION_REQUEST_CODE);
--> then Settings.canDrawOverlays returns false;
=2=
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION));
startActivityForResult(intent, ACTION_MANAGE_OVERLAY_PERMISSION_REQUEST_CODE);
--> then Settings.canDrawOverlays returns false;
In case of =2= there is additional step for selecting my app from the list of apps with manage overlay permissions.
so...@chromium.org
Sorry, for #10, in case of =2= Settings.canDrawOverlays returns true, not false.
so...@chromium.org
I have also stumbled upon this bug.
In my case, I have to wait until the transition back from Settings.ACTION_MANAGE_OVERLAY_PERMISSION to my app is finished. If I request the canDrawOverlays before then, I always get false. It seems like it needs to be performed when the activity is completely in focus.
In my case, I have to wait until the transition back from Settings.ACTION_MANAGE_OVERLAY_PERMISSION to my app is finished. If I request the canDrawOverlays before then, I always get false. It seems like it needs to be performed when the activity is completely in focus.
ke...@google.com
This is also happening for me on a Pixel running Android O DP4.
I have attached a sample that should easily show what we are all talking about. It uses what was mentioned in #7. In onActivityResult(), I call Settings.canDrawOverlays() immediately, and I schedule a Runnable to get exectued after a second that will do the same thing. First time, the method returns false, and the second time it returns true.
1. Run the app
2. Click on "Ask for Permission"
3. Click on the "Allow display over other apps" toggle
4. Press back
Result: First, the text "Cannot display overlays" appears, and after a while, the text "Can display overlays" appears instead.
Expected: We should get "Can display overlays" immediately upon coming back to our Activity (after step 4).
I have attached a sample that should easily show what we are all talking about. It uses what was mentioned in #7. In onActivityResult(), I call Settings.canDrawOverlays() immediately, and I schedule a Runnable to get exectued after a second that will do the same thing. First time, the method returns false, and the second time it returns true.
1. Run the app
2. Click on "Ask for Permission"
3. Click on the "Allow display over other apps" toggle
4. Press back
Result: First, the text "Cannot display overlays" appears, and after a while, the text "Can display overlays" appears instead.
Expected: We should get "Can display overlays" immediately upon coming back to our Activity (after step 4).
bu...@chromium.org
@4 Bug still exist even on official final version of Android O (OPR6.170623.013) .
Decided to make a new post for it, because here it's for preview version:
https://issuetracker.google.com/issues/64919285
Decided to make a new post for it, because here it's for preview version:
bu...@chromium.org
Our engineering team has fixed this issue. It will be available in a future Android release.
bu...@chromium.org
@15 which version?
is...@google.com
Could you tell me this issue was adapted release version? I am using nexus 5x.
Description
1. sign in
2. start ibus-daemon
3. press Ctrl+Shift+Q to shut down the machine
4. boot
5. check the previous /var/log/ui/ui.YYYYMMDD-HHMMSS log
actual:
(process:5041): IBUS-DEBUG: _connection_closed_cb: Underlying GIOStream returned 0 bytes on an async read
[5041:5041:463230574:ERROR:browser_main_loop.cc(155)] GLib-GObject: invalid uninstantiatable type `(null)' in cast to `IBusPanelService'
[5041:5041:463230717:ERROR:browser_main_loop.cc(155)] GLib-GObject: instance of invalid non-instantiatable type `(null)'
[5041:5041:463230815:ERROR:browser_main_loop.cc(155)] GLib-GObject: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
[5041:5041:463230952:ERROR:browser_main_loop.cc(155)] GLib-GObject: instance of invalid non-instantiatable type `(null)'
[5041:5041:463231106:ERROR:browser_main_loop.cc(155)] GLib-GObject: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
[5041:5041:463231180:ERROR:browser_main_loop.cc(155)] GLib-GObject: instance of invalid non-instantiatable type `(null)'
[5041:5041:463231248:ERROR:browser_main_loop.cc(155)] GLib-GObject: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
caused by one of your recent IME changes like