Dear Google’s Permissions Declaration Form, Can We Break Up?
Get rid of Google’s Permissions Declaration Form from your Play Console even after you’ve removed SMS & Call permissions from your app.
If you’ve been releasing apps via the Google Play Console in the last few months and if your app requires sensitive permissions, it’s quite evident that you’ve had to deal with the scary Permissions Declaration Form by Google Play.
It’s scary because your app has a very high chance of getting rejected if you violate any of their policies.
During recent times, what has been more scary is when developers remove the sensitive permissions from their app and yet have to fill the Permissions Declaration Form.
This doesn’t really make sense, because if your app doesn’t ask for any sensitive permissions, you shouldn’t be required to face the Permissions Declaration Form, right?
But nope, it still shows up anyway.
Let’s explore this in detail, why this happens and how to get around this problem.
The Problem
The issue lies with how the Permissions Declaration Form works on the Google Play Console.
It’s a UX issue.
The form isn’t supposed to show up once we upload a new build to Production that doesn’t have any sensitive permissions (SMS or Call). But the form is persistent because there are some old artifacts (a.k.a. old builds) that lie archived in the Play Console. These artifacts need to be deactivated first.
Note: This is not a solution and isn’t something that is normally supposed to be done, but this is a workaround to get the app back on the Play Store until Google Play fixes this UX issue.
If you’re using multiple release tracks (Internal Testing, Alpha, Beta), you will find that you have some artifacts in the Artifact library section from the Play Console that are still activated. The form shows up because these artifacts are still activated.
You can find the **Artifact library **as the last option in this screenshot from your Play Console:
The Solution
To solve the issue at hand, you need to get rid of all the old artifacts and replace them with your new build in all the release tracks (Internal Testing, Alpha, Beta, Production), even if you won’t end up using these release tracks.
First, it’s important to know where these release tracks can be accessed from. Click on the 2nd option in this screenshot:
Once you click on that, scroll down a bit and you should see the following screenshot:
The critical part of the solution lies in you uploading the new builds with updated version codes in all the release tracks that are in use.
FAQ: How do I know if a release track (Internal Testing, Alpha, Beta, Production) is being used or not?
Answer: If you see any version code in any respective track in the above screenshot, then that track is being used. If you don’t see any version code, then that means that the release track isn’t being used. So do not upload any new build for a release track that isn’t being used!
Now, getting to how to upload the builds for the release tracks that are in use:
-
Note down your current build version code. Let’s say it’s 30 and it’s in the Production track. And let’s say, you’re only using Internal Testing and Alpha release tracks, and not using Beta.
-
Create a new build with version code **31 **and upload it to Internal Testing. This will deactivate any old artifacts in Internal Testing.
-
Create a new build with version code **32 **and upload it to Alpha. This will deactivate any old artifacts in Alpha.
-
Open **Artifact library **again and see if there are any artifacts in the **Archived artifacts **section. You should see a delete button (looks like a recycle bin) next to each artifact in this section. Delete all the artifacts in the **Archived artifacts **section; you don’t need them any more and they aren’t being used anyway if they’re archived. Make sure that you don’t have any old artifacts, or else you’ll have to deal with Permissions Declaration Form will show up again!
-
Finally, create and upload a new build with version code **33 **to Production. This will deactivate any old artifacts in Production.
When you do this, **if your new build doesn’t have any sensitive permissions included in it, **you shouldn’t see the Permissions Declaration Form at all.
This means that you should be able to upload the new build without filling the form at all. Upload the build with version code **33 **to Production and that’s it!
You should see your app back up on the Play Store in a few hours!
Find me and all my socials here: