Here is a well-known Q/A about draw overlay permission issue. I observed same behavior on my previous apps also, i.e. it was automatically granted when the app is installed from Play Store.
In my recent app, however, I observed that that permission is not granted even if it is installed from Play Store. At first, I thought that this might be a specific problem for our test devices. However, I wanted to be sure about it by tracking the number of such lack-of-permission situations in the wild through my favorite analytics tool.
We published the version that notifies about this incident yesterday, and the analytics say that we had to manually request for this permission at 80 users, in just 1 day. Ouch!!!
The analytics say that this problem occurs in almost all Android versions, from 6.0 to 9. So it is not the case for just a few versions.
Is there any change about this permission recently? Or, does Play Store have some kind of a whitelist (e.g. Facebook takes it automatically) to grant this permission?
Yes, there is a change since beginning of January 2019. For my app I got a first report on 9th January. Only fresh installs of an app are affected.
There are several apps affected, but the selection of apps that still receive the permission automatically seems random. This is a known problem and has been reported to Google, but of course: zero response. See following bug reports for more info:
https://issuetracker.google.com/issues/127690549
https://issuetracker.google.com/issues/37125806
https://issuetracker.google.com/issues/37119304
https://issuetracker.google.com/issues/123686422
You might argue that one has to provide a permission check flow anyway, but bear in mind that not all roms provide a UI for granting overlay permission. I don't know of any Android TV rom which provides such interface. Hence this is particularly annoying for TV apps that don't work without this permission.
Related
For months I've been trying to publish an app with READ_CALL_LOG permission to no avail.
App is a contact management app including scheduled meetings, calendar and other events.
I only need to be able to get incoming call number, but since it's not allowed, I've implemented full InCallService that launches activity to display calling window with common answer/hang up buttons and few that redirect to our main app.
I've updated "App content" section "Sensitive app permissions" with checked "Default phone handler", provided instructions for review.
Latest version of the app is deployed in internal track. But I also have older rejected versions in beta, alpha and production tracks
App itself on first launch asks permissions to become a default Call App, otherwise won't even start.
And yet, no matter how much I try, I keep getting "App rejected" in Play store "Policy status" section. Going to see further details I get:
Issue: Violation of Permissions policy After reviewing your app, we
found that it doesn’t qualify to use the requested permissions for the
following reason(s): Requested permissions do not match core
functionality of the app You declared Default Phone handler (and any
other core functionality usage while default handler) as the core
functionality of your app. However, after review, we found that your
app does not match the declared use case(s). Learn more about
permitted uses and exceptions. Please either: • Make changes to your
app so that it meets the requirements of the declared core
functionality or, • Select a use case that matches your app’s
functionality
With "Eligibility issue" below:
Sensitive permission Your app does not qualify for use of the
requested permissions. Permission requests should make sense to users.
You may only request permissions that are necessary to implement
critical current features or services in your application. You may not
use permissions that give access to user or device data for
undisclosed, unimplemented, or disallowed features or purposes.
To my understanding if I declare the intent of using app as a default phone call handler and make that explicitly clear to the user I should be able to publish this app? Being able to detect call number is a core functionality for the app.
I've tried reaching out to support multiple times, but they just write, that they'll contact me via email to never be heard from again.
Any suggestions on what could be improved?
I have built 5 app with different sign key and they are not on googleplay market.
And user downloads and installs my apps from little banner ad click ,which I put in my apps(Internal downloader and then install app AND NOT market link!).
I use "REQUEST_INSTALL_PACKAGES" to get install permission and android targetsdk is 28 .Is this permission dangerous to use? And would "googleplay protect" detects it as a dangerous app and show warning protection dialog when user installs it?
Any help will be appreciated.
Please take a look at my answer I posted below:
Why HMS PushKit needs android.permission.REQUEST_INSTALL_PACKAGES
I've given allot of detail into why not to use this permission, and how it poses a security risk for google, (so much to the point that they will reject the app, if any dependency has this permission on its manifest).
I'm working on a project based on cloud backup which saves and restore user's call log. It was working fine for the previous version but now getting following warning. I added a description before taking permission from the user but still getting the warning.
Your app is requesting the following permission which is used by less
than 1% of functionally similar apps: WRITE_CALL_LOG
Users prefer apps that request fewer permissions and requesting
unnecessary permissions can affect your app's visibility on the Play
Store. If these permissions aren't necessary, you may be able to use
alternative methods in your app and request fewer permissions. If they
are, we recommend providing an explanation to users of why you need
the permissions. Learn more
Note: This guidance is based on a comparison with functionally similar
apps, which change over time as new apps get published and existing
apps change behavior. Therefore the warning may change even if you
don't change your permission usage.
Its a warning. If you need that permission (and it seems your app does), then you're fine. If you didn't really need it, you should remove it. Google isn't going to scan your description to see if you explain it, that level of AI isn't really possible yet. So you'll continue to get the warning.
About half a year ago we released a huge update to the app, and with this introduced new permissions to the app (GPS / Bluetooth related, etc)
Half a year is plenty of time for users to update, however in Google dev console we still shows a large percentage, about 30% of the user base still using the old version.
I'm assuming this is due to
New Permissions require Manual updates, users must to hit 'Accept' before installing the
update, and new update is being bypassed by Auto-Update
Some users have disabled Auto-Update and never update at all
Probably some percentage of old / abandoned devices
We're looking to address #1 as we experienced that making changes to app's permissions creates fragmentation pockets within the user base.
A potential solution would be to show a periodic "in-app" notification prompting users to update. But the problem is how to release an app update only reaching those old version users without impacting current users, as we cannot remove new permissions.
A hypothetical approach would be an in-between update, but the dev console does not allow lower app versions.
Are there any solutions available for reaching stuck users on old versions, or any work arounds that could be recommended?
New Permissions require Manual updates, users must to hit 'Accept'
before installing the update, and new update is being bypassed by
Auto-Update
I don't think you can bypass the prompt for the manual acknowledgment.
My best practices for using adding new permissions are:
Always adding creative release notes to explain why I need these permissions, so the user will download the update.
Luckily with Android M your users won't experience this
Are there any solutions available for reaching stuck users on old
versions, or any work arounds that could be recommended? Thanks!
Once a user is lost, it is very hard to get them back.
You can use your analytics to determine which popular devices are using your old app version.
Depending on the time/resources you have, multiple apks and segmentation based on devices can help you in this situation.
http://developer.android.com/google/play/publishing/multiple-apks.html
A potential solution would be to show a periodic "in-app" notification
prompting users to update.
This logic can live client side and if done right users running your current version do not see that.
Hope this helps or leads you in the you are hoping for.
In the past I managed this sort of situation by having the app periodically check-in with my backend server to report the app version number. The server would check the app version number against what the server supports and if an upgrade was required the server would return a message that the app would then prompt to the user asking them to update. Obviously that doesn't help you with your existing 30% of users but it might help in the future.
I would also think it would help to release an update that targets Marshmallow and then you could use the newer permission model and prompt users for what permissions you need. I would think that would then allow the 30% on the older version of your app to auto-update or update without having to confirm permission changes in the play store. Those users would then be prompted in the app for whatever permissions you require.
In other words - when I search for other apps on android market, I usually see an option for enabling "auto-update" for that specific app. However, when I look at my own app, I don't see such option - why?
Given details provided in a linked conversation from Dimitris's Answer the fact that you can't check it off is probably due to permissions changes. You'll either need to re-download the app or do a manual update and accept the new permissions.
From what I gather on the searches I've performed, there's nothing in the app itself that defines whether it's update-able (word?) it's just a feature the market offers to version check (and update) for you.