remove: android.permission.REQUEST_INSTALL_PACKAGES from plugins.xml

[lincolnthree]

Expected Behaviour

Google is now requiring additional verification for the REQUEST_INSTALL_PACKAGES permission, and will start rejecting apps that have not submitted a valid use.

Developers should have control over which permissions are enabled or not.

Actual Behaviour

REQUEST_INSTALL_PACKAGES is forcibly activated in plugins.xml

Reproduce Scenario (including but not limited to)

[richardkshergold]

I just did this (submitted with no APK attached) and it was immediately rejected with exactly the same issue (implying that the rejection is due to previous builds in the same track?)

[fireonmac]

Hi @Sundarvelu-NA I'm not sure what you mean here? Submit an empty dummy release for review (with no apk attached)?

Then what?

Empty release will deactivate problematic APK in previous release. If you have multiple release in various tracks, Do the same thing in all the tracks. Do not send review until you create all the releases in each track and after you create all, submit review. Don't forget you must do that in not only testing track, but also production one.

[fireonmac]

Play console seems like will reject the latest clean build if you contain a build with this permission usage in other tracks (internal, alpha, etc). The REQUEST_INSTALL_PACKAGES detection may be referring to existing builds in other tracks instead of the latest build. The review feedback message is confusing and not helpful.

try these:

1. In Play console (your affected app), click App Content under Policy
2. Look for Sensitive permissions and APIs and click Start.
3. Select APKs and bundles, the list will show you the build and track that contain sensitive permission/API.
4. Navigate to the affected track, create a new release without upload any apk/bundle (or upload a clean build to replace the existing one), give a Release name, and submit it to review.
5. Navigate to Publishing overview and check whether the review is pending to submit, if any, send the review.

You saved my life thx.

[Sundarvelu-NA]

@fireonmac 👍 👍

[richardkshergold]

So in the Production track I would have to create a new release with no apk attached and then submit it for review?

[fireonmac]

So in the Production track I would have to create a new release with no apk attached and then submit it for review?

In the production track, be aware your app will be removed from store with no apk. so I recommend you to attach actual apk which has no permission issue. The testing tracks doesn't matter with no apk.

[richardkshergold]

@fireonmac Can I submit to the Production Track without releasing into the store? (I want this new version of the app to go through the Closed Testing track before we release to production)

[fireonmac]

@fireonmac Can I submit to the Production Track without releasing into the store? (I want this new version of the app to go through the Closed Testing track before we release to production)

If you didn't publish your app yet, you don't need to touch the production track.

[richardkshergold]

My app is already published - what I don't want to do is replace it with my new version (that has the Capacitor plugin instead of the Cordova one) until that has gone through Closed Testing. But it sounds like I can't get it through review on the Closed Testing track until the new version is also uploaded to the Production track - which all seems a bit bizarre, scary and strange

[fireonmac]

My app is already published - what I don't want to do is replace it with my new version (that has the Capacitor plugin instead of the Cordova one) until that has gone through Closed Testing. But it sounds like I can't get it through review on the Closed Testing track until the new version is also uploaded to the Production track - which all seems a bit bizarre, scary and strange

I agree It's bizarre, but we can do nothing against Google's policy. If your previous version used the Cordova one, I suggest not to change to the Capacitor one. Keep the source code same with previous one and then resolve the permission issue by replacing Production track. If you succeed then consider to use the Capacitor one.

[richardkshergold]

Sorry, i'm not following very well (it's been a long day). It's only by replacing the cordova plugin with the capacitor one that has solved the permissions issue for me so i'm not sure what you mean by "and then resolve the permission issue by replacing Production track" ?

[fireonmac]

Sorry, i'm not following very well (it's been a long day). It's only by replacing the cordova plugin with the capacitor one that has solved the permissions issue for me so i'm not sure what you mean by "and then resolve the permission issue by replacing Production track" ?

Above comment, @adammaus's hook which remove the permission from AndroidMenifest file works well. That hook will solve the permission issue without changing your code. It's more safer not to change your codebase when there's no way avoiding you to directly changing the release in Production track.

[richardkshergold]

Ok, so you are basically saving that the only way to get out of this is to directly replace my Production app with a new version?

[fireonmac]

Ok, so you are basically saving that the only way to get out of this is to directly replace my Production app with a new version?

Yes, I spent three weeks to avoid that, but failed.

[richardshergold]

Ok well that gives us a huge problem then because our current app in the Store is based on Capacitor 3 and the one of the reasons we are updating it with this new one (using Capacitor 4) was the new min SDK requirements that came into play on October 1st. So I can’t replace the current version of our app with anything other than this new version.

[richardshergold]

I have emailed Google via the Console Support page but whether they will get back to me soon on this I have no idea. It all seems a bit crazy.

[laurentperez]

@Sundarvelu-NA solution at https://github.com/pwlin/cordova-plugin-file-opener2/issues/329#issuecomment-1286613439 is the best fix.

@richardkshergold just branch and hotfix your current Production version by hotfixing both the permission and the min sdk requirements in the source code you wrote when you published this old production version.

This is what we did and the validation succeeded ; this plus the removal of permission from every other track as Sundarvelu wrote.

[richardshergold]

Hmm. Thanks @laurentperez will give that some thought. This all seems a bit crazy to me. I really don’t see why Google can’t review the new version of the app in the Closed Testing track and then I release it as normal after testing?

[richardshergold]

@laurentperez I’m not sure I can just branch off my Production version and simply change the SDK level - because it uses Capacitor 3 and I think (well I thought!) the only way of getting round the October 1st change was to upgrade to Capacitor 4?

[fabichacon]

@laurentperez I’m not sure I can just branch off my Production version and simply change the SDK level - because it uses Capacitor 3 and I think (well I thought!) the only way of getting round the October 1st change was to upgrade to Capacitor 4?

@richardkshergold don't worry. I use Capacitor 3. I just removed the permission and modified the SDK level as @laurentperez comments and it worked fine.

[richardshergold]

@fabichacon and others. Ok, that makes me feel a bit better. Thanks for your help and input. It’s evening here so I’m giving up for the weekend now. Will be back on this on Monday morning I expect.

[richardshergold]

@fabichacon when you say you just removed the permission do you mean you used the script (above) to remove it or did you remove the file opener plugin and replace it with the capacitor one?

[fabichacon]

@richardkshergold I follow @louisfelix temporary fix. Fork the plugin, remove permission and re-package. But the script should work too.

[richardshergold]

My thinking right now is that because this new version of the app is 99% tested maybe it would be easier to replace our Production one with the new one anyway rather than hot fix the existing one.

[laurentperez]

I really don’t see why Google can’t review the new version of the app in the Closed Testing track and then I release it as normal after testing?

Because every company has different release plans.

You're not expected to always promote to production, nor open testing for the matter, from a closed testing track. Of course you want to, but others might not. You could wait months in closed testing before pushing to production.

The multiple tracks permission coverage of google makes sense - yep we found it bizarre too, but it's about the broader picture

IMHO it's a technique they use to get rid of this evil permission in production tracks too. It's the right thing (c)

I'm no google employee ;)

[richardkshergold]

Hey @laurentperez and @fabichacon thanks for your assistance last week with this - I have one more question! In the situation we are currently in when we replace our current app in Production with the new app will we still be able to do a staged release like we normally do or will this need to go to 100% of users immediately?

[mread1208]

As mentioned several times above, the Cordova Hook actually DID remove the permission from my Android Manifest.xml file. However, Google was still rejecting my app for the permissions issue. Turns out the issue wasn't due to the new app I was uploading... but rather, it was because I had really old testing tracks that we created several years ago that were still "open". Once I went in and Closed / Archived those testing tracks that had super old builds attached to them, I was able to resubmit and everything went through successfully!

It was a very frustrating 3 weeks, and had I not submitted an appeal I never would have been able to figure it out. Thankfully Google finally reached back out to me and told me what the real problem was. Google definitely needs to be more clear about the issue rather than rejecting the actual app I was uploading.

[laurentperez]

In the situation we are currently in when we replace our current app in Production with the new app will we still be able to do a staged release like we normally do or will this need to go to 100% of users immediately?

if you enable Managed Publishing in Google console you can control the date and rollout percentage.

[arnotixe]

@mread1208 thanks a lot - this part got me on the right track. I filed a bug with Google Play Store over this.

Turns out the issue wasn't due to the new app I was uploading... but rather, it was because I had really old testing tracks that we created several years ago that were still "open". Once I went in and Closed / Archived those testing tracks that had super old builds attached to them, I was able to resubmit and everything went through successfully!

In my case, it was actually the production track (6 months old release or something) that had an apk specifying REQUEST_INSTALL_PACKAGES.

But it was my new beta submission that got flagged with Rejected (even if the new beta did not use the permission). The production one had no such flag:

What I did was to promote the (Rejected :smile: ) apk from Open testing to Production and click Review. Following the same logic you found there, the Production one was superseded and it passed review overnight. Although I'm not so happy with pushing a beta to Production, I had no choice here… :roll_eyes:

and… yes, my new beta was built with the fork: https://github.com/capacitor-community/file-opener

[ziaurrehmanjutt]

My App rejected on playstore due to this issue. Please update this plugin

[sawilliams0313]

The problem plugin for me was cordova-plugin-file-opener2. The way I found that out was by looking at the plugin.xml file for each cordova plugin and searching for REQUEST_INSTALL_PACKAGES.

In order to remove this permission from the plugin, I used patch-package https://www.npmjs.com/package/patch-package after being referred by my super awesome coworker David. My submission was approved by Android!

Hope this helps someone.

[shaileshpendams]

this is work for me. https://www.youtube.com/watch?v=XQ3r5-Az41c&ab_channel=shaileshpendam

[GavinJohnsen-E20567]

With a Capacitor project and @brospars commit you can resolve this issue pretty easily by referencing his commit directly, since I doubt his PR will be accepted by the author.

In package.json update your dependency to be:

"cordova-plugin-file-opener2": "github:pwlin/cordova-plugin-file-opener2#0b15d93b4f0c5a70206fe276f7aa956f754c3ca3",

Then npm install to update packages

Then the next time you run npx cap sync the REQUEST_INSTALL_PACKAGES permission should be gone from \android\capacitor-cordova-android-plugins\src\main\AndroidManifest.xml

[mattsputnikdigital]

This now works on iOS and Android

Tested with PDF files.

https://github.com/capacitor-community/file-opener#fileopeneroptions

[shnist]

this should now be fixed in the latest version