10

I have an application on play store to whom the targetSdkVersion is update to 30 from 29, which is getting rejected again and again by Google Play after an update.

Previously, there was a permission of MANAGE_EXTERNAL_STORAGE in one of the SDK Manifest.

After removing MANAGE_EXTERNAL_STORAGE permission and storage permission (WRITE_EXTERNAL_STORAGE) completely from my app, uploading the app on store, app update gets rejected again.

This is the email received from Google Play for the rejection reason.

Note: I am saving all my media files in app-specific internal storage.

Also, I have the permission of READ_EXTERNAL_STORAGE in my SDK as we have chat feature in our app to get images and videos of device to sent it.

According to Use of All files access (MANAGE_EXTERNAL_STORAGE) permission READ_EXTERNAL_STORAGE permission has not impact.

Attached reference.

Update

I also removed READ_EXTERNAL_STORAGE permission from the app, but still got the rejection with same reason from Google Play.

Is the issue with Storage Policy, or something else?

Muhammad Awais
  • 448
  • 5
  • 17

4 Answers4

10

I had the same error for a month but finally, Google Play Store accepted my uploads.

Briefly, what I did was to create new builds for each track, and -interestingly- it worked!

(Before my countless update trials, our latest version on Production was 2.23.5 (build 1), our active tracks were Internal Testing Track and Production, and I was trying to upload my updates to Internal Testing Track.)

Below are the steps that I've applied:

  1. Created a new build 2.24.1 (build 1) with all necessary changes. (e.g. upgrading targetSdkVersion to 30, removing MANAGE_EXTERNAL_STORAGE permission, etc.)
  2. Activated our inactive tracks (Open, Closed Alpha, and Beta Testing Tracks), uploaded the same build 2.24.1 (build 1) to these tracks, and then paused those tracks. (I've paused them as I won't use them actively, you may not want to pause it)
  3. Created another build 2.24.1 (build 2) which was completely the same as build 1. I've just updated its build number.
  4. Uploaded 2.24.1 (build 2) to the Internal Testing Track.
  5. Created another build 2.24.1 (build 3) which was completely the same as build 3. I've just updated its build number.
  6. Uploaded 2.24.1 (build 3) to the Production Track.
  7. Went to "Publishing Overview" page, activated Managed Publishing in order to manually publish my uploads to Production and other tracks as they got accepted.
  8. Sent these uploads to review at once and voila, Google accepts your uploads!

Sarcasm on.

Hereby, I would like to congratulate Google Play Support as they've shared all these details within their documentation, within their rejection e-mails, and within their super fast response to the appeal.

Sarcasm off.

I've found this solution referencing from this answer https://stackoverflow.com/a/69933431/2833718. I couldn't find any help from Google's official docs. They've always rejected my uploads with the same e-mail which is impossible to decode for a human being. They've never returned to my appeal.

This migration and support process was completely a failure.

Thank you Google Play Support, you are everything but support to developers.

Mehmet Sedat Güngör
  • 919
  • 7
  • 12
  • Do we need to submit all the builds (Internal, Open, Closed) to review or its just upload and save it as draft ? When you pause the track, Google will not take them in to consideration I guess. – Swaminathan V Dec 20 '21 at 07:49
  • @SwaminathanV As mentioned in step 2, I've uploaded the same build v1 for the tracks which I don't actively use, and then I've paused those tracks. So even if the builds were uploaded, they weren't released as I publish because those tracks became inactive after I paused them. – Mehmet Sedat Güngör Dec 20 '21 at 16:31
  • Understood. After you upload to those tracks, you just paused them without submitting to review right ? – Swaminathan V Dec 21 '21 at 04:04
  • No need to upload on tracks which have never been used. – Shatiz Aug 10 '22 at 03:47
3

My Android rejected build is approved finally after 3 weeks of headache.

Basically, Google was checking old APK, if it is available in any of the track (Internal, Open, Closed or Production) with Policy Violation.

So, in this regard you have to roll out the app to 100% in the track which has this Policy violation. Which will deactivate the old build.

I wasn't rolling out the new app to 100%.

Thanks to Google Policy Team.

Muhammad Awais
  • 448
  • 5
  • 17
  • You are welcome. Did you ask them the same question you asked me and if so, what did they say? – anemomylos Nov 30 '21 at 09:28
  • They just send me the way of uploading APK to store, basically they were asking to deactivate the old builds from all tracks. Which can be done by rolling out the app to 100%. – Muhammad Awais Dec 03 '21 at 15:01
  • @MuhammadAwais I'm also facing same issue from few weeks. I have roll out the build to production for 100% user but I still have old policy violation app in open testing , close testing & internal testing. do we have to release the new application with policy violation remove for those category [open, close and internal] as well ? kindly guide us. – Radhika bajaj Sep 14 '22 at 05:53
  • @MuhammadAwais but in my case its rejected because i have given MANAGE_EXTERNAL_STORAGE so can you please help me how to fix this ? – MARSH Apr 25 '23 at 04:05
  • You have to remove this permission (MANAGE_EXTERNAL_STORAGE). There are only some apps which can use this permission. If your app falls in that category apps then you can use this permission. Also, check other tracks(Open, Closed, Internal) on your play console. Your app should be deactivated on those platforms too. – Muhammad Awais May 04 '23 at 08:02
0

I Found a solution for my issue . Actually there was another channel in google play "Internal Testing channel" That has a build with permissions . You need to remove/Update any builds inside any channels to be empty from any Sensitive/ Highly risk permission.

razan barham
  • 1
0

One method for solve your problem, is start one new app. But when you for config your app, put disable the iten that say about file sms and file critical.

Resume, your app is been reject because the uour pre config. And not by your code.

Marcio Luiz Momi
  • 1
  • 1
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community May 19 '22 at 00:30