WAI
Status Update
Comments
lb...@gmail.com <lb...@gmail.com> #2
Note that the bug surfaced when I tried our app on android 5
pl...@gmail.com <pl...@gmail.com> #3
I'm also seeing this problem with our library IOCipher (https://github.com/guardianproject/IOCipher ). It all builds and works fine, until I switch the test suite from targeting android-15 to android-21, then running the tests on a android-19 (4.4.4) ROM. The NDK build uses r10d, and the IOCipher NDK build targeting android-7.
I found this workaround, which seems to work:
LOCAL_LDFLAGS += -fuse-ld=bfd
I found this workaround, which seems to work:
LOCAL_LDFLAGS += -fuse-ld=bfd
dn...@google.com <dn...@google.com>
dn...@google.com <dn...@google.com> #4
please reopen if you still see this with r12.
dn...@google.com <dn...@google.com> #5
This is an intended behavior to allow popular apps to keep working until we have an alternative APIs in the platform for these apps to migrate.
lb...@gmail.com <lb...@gmail.com> #6
@5 So apps working on API 1-22 and 24 - no need to request this permission, yet on API 23 (Android M) - do need to request this permission?
How come you didn't update the docs on such an important change?
Not even in the changes list here (nothing there about draw-on-top or the SYSTEM_ALERT_WINDOW permission) :
https://developer.android.com/about/versions/nougat/android-7.0-changes.html
Please, for each change that developers should know about, update the docs and also write about it in the changes list.
I also don't understand why you did it. If the app targets to API 24 or above, it should be like runtime permissions (as the docs say): ask the user . You could even make it look similar in U, instead of showing the full screen confirmation with the switch.
How come you didn't update the docs on such an important change?
Not even in the changes list here (nothing there about draw-on-top or the SYSTEM_ALERT_WINDOW permission) :
Please, for each change that developers should know about, update the docs and also write about it in the changes list.
I also don't understand why you did it. If the app targets to API 24 or above, it should be like runtime permissions (as the docs say): ask the user . You could even make it look similar in U, instead of showing the full screen confirmation with the switch.
[Deleted User] <[Deleted User]> #7
what the meaning of "popular apps"? What is its definition?
wo...@gmail.com <wo...@gmail.com> #8
Facebook Messenger gets the permissions automatically. So it seems to be a popular app. I did not find any documentation which could tell me when an app is being considered popular.
ma...@gmail.com <ma...@gmail.com> #9
my (i.e. unpopular) app used to receive the permission automatically, but this stopped working a few weeks ago. So something changed recently (not my app). The real problem is Android TV where the user cannot grant this permission himself since there is no activity available to handle this request.. :/
ar...@gmail.com <ar...@gmail.com> #10
my (i.e. unpopular) app used to receive the permission automatically, but this stopped working a few weeks ago. So something changed recently (not my app). The real problem is Android TV where the user cannot grant this permission himself since there is no activity available to handle thi
ar...@gmail.com <ar...@gmail.com> #11
Facebook Messenger gets the permissions automatically. So it seems to be a popular app. I did not find any documentation which could tell me when an app is being considered popular
lb...@gmail.com <lb...@gmail.com> #12
Since I've noticed the same behavior now, I decided to make a new request about it:
https://issuetracker.google.com/issues/123686422
Description
Steps:
1. install this app:
2. Notice its targetSdk is 24, which means all permissions should be requested, including draw-on-top, which needs a special full screen UI for it.
3. run the app, and go to the draw-on-top screen of it.
The bug:
This permission is granted by default.
Attached video.