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)

[ipopa]

Hello, we had the same problem, you must to fork the plugin, remove the permission and delete the possibility to install/uninstall an apk with this plugin.

[lincolnthree]

Yeah, and I think there is more code that needs to be removed in the class, too. Don't forget the other functions, and imports.

[arnotixe]

+1 it seems possible to "just remove the setting from the plugin's config.xml and rebuild" but I think this feature is quite optional so it should be … optional somehow

[ryaa]

Here is the capacitor version of this plugin - see https://github.com/capacitor-community/file-opener
Note that this is for Android only at this moment.

[ryaa]

The support for iOS has been added. Can anyone, who uses capacitor, install from the github using the below command to give it a try
npm install capacitor-community/file-opener#chore/latest-version-with-dist-directory

[NGizdov]

Guys, do we expect this PR to be accepted and merged, because it is crucial for us, as the end date is quite close

[louisfelix]

As a temporary fix, until this PR is accepted, here is what we did to mitigate the emergency:

1. Fork the plugin and remove the REQUEST_INSTALL_PACKAGES permission (you can use our fork here)
2. In our project's package.json dev dependencies, replace "cordova-plugin-file-opener2": "^3.0.5" by "cordova-plugin-file-opener2": "git+https://github.com/CitadelApp/cordova-plugin-file-opener2.git"
3. Re-package everything and send to Google Play review: it has been accepted and the issue has been removed in Google Play Console -> Policy -> App concent

[benazir46]

@louisfelix it didn't work for me. I simply removed the permissions manually in vscode and it worked!

[xtoussaint-estel]

In my config.xml

<edit-config file="app/src/main/AndroidManifest.xml" target="/manifest" mode="remove">
<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
</edit-config>

😋

Edit : I don't know why but my solution doesn't work anymore. The requested change is applied BEFORE the uses-permission is inserted in the AndroidManifest so it is still there 😕 I use the @adammaus script which works every time in my case.

[adammaus]

@xtoussaint-estel That didn't work for me but your answer led me to a script and hook in config.xml. Thank you!

I adapted a few stack overflow answers for the JS file below. Definitely test these out beforehand!

config.xml

<platform name="android">
    <hook src="scripts/remove-android-permissions.js" type="after_prepare" />

scripts/remove-android-permissions.js

#!/usr/bin/env node
//
// This hook removes specific permissions from the AndroidManifest.xml
// The AndroidManifest is re-generated during the prepare stage,
// so this must be run on the "after_prepare" hook.
//


// Configure the permissions to be forcefully removed.
// NOTE: These permissions will be removed regardless of how many plugins
//       require the permission. You can check the permission is only required
//       by the plugin you *think* needs it, by looking at the "count" shown in
//       your /plugins/android.json file.
//       If the count is more than 1, you should search through
//       the /plugins/<plugin-name>/plugin.xml files for <uses-permission> tags.

var permissionsToRemove = [ "REQUEST_INSTALL_PACKAGES" ];

var fs = require('fs');
var path = require('path');
var rootdir = process.argv[2];
var manifestFile = "platforms/android/app/src/main/AndroidManifest.xml";

fs.readFile( manifestFile, "utf8", function( err, data )
{
    if (err)
        return console.log( err );

    var result = data;
    for (var i=0; i<permissionsToRemove.length; i++)
        result = result.replace( "<uses-permission android:name=\"android.permission." + permissionsToRemove[i] + "\" />", "" );

    fs.writeFile( manifestFile, result, "utf8", function( err )
    {
        if (err)
            return console.log( err );
    } );
} );

For the bulk of the script
https://stackoverflow.com/a/42182147

For the manifestFile path:
https://stackoverflow.com/a/55563097

[zawmn]

Is there any update on this issue? Or is there any alternative plugin like this?

[zdayar]

Guys, do we expect this PR to be accepted and merged, because it is crucial for us, as the end date is quite close

Have you found a solution yet? Having the same issue. Thx!

[lincolnthree]

Just pull from the new repository/branch with the updated code directly in your package.json:

"cordova-plugin-file-opener2": "repo/cordova-plugin-file-opener2#branchName"

[ccerrillo]

In my config.xml <edit-config file="app/src/main/AndroidManifest.xml" target="/manifest" mode="remove"> <uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" /> </edit-config> 😋

this solved the issue thanks!!!

[mread1208]

@ccerrillo what version of cordova are you using? I'm on Cordova 11.0.0 and this does not appear to be removing this setting from our AndroidManifest.xml file. I don't see mode="remove" listed as an option in the Cordova docs: https://cordova.apache.org/docs/en/latest/plugin_ref/spec.html#edit-config

[mread1208]

@xtoussaint-estel That didn't work for me but your answer led me to a script and hook in config.xml. Thank you!

I adapted a few stack overflow answers for the JS file below. Definitely test these out beforehand!

config.xml

<platform name="android">
    <hook src="scripts/remove-android-permissions.js" type="after_prepare" />

scripts/remove-android-permissions.js

#!/usr/bin/env node
//
// This hook removes specific permissions from the AndroidManifest.xml
// The AndroidManifest is re-generated during the prepare stage,
// so this must be run on the "after_prepare" hook.
//


// Configure the permissions to be forcefully removed.
// NOTE: These permissions will be removed regardless of how many plugins
//       require the permission. You can check the permission is only required
//       by the plugin you *think* needs it, by looking at the "count" shown in
//       your /plugins/android.json file.
//       If the count is more than 1, you should search through
//       the /plugins/<plugin-name>/plugin.xml files for <uses-permission> tags.

var permissionsToRemove = [ "REQUEST_INSTALL_PACKAGES" ];

var fs = require('fs');
var path = require('path');
var rootdir = process.argv[2];
var manifestFile = "platforms/android/app/src/main/AndroidManifest.xml";

fs.readFile( manifestFile, "utf8", function( err, data )
{
    if (err)
        return console.log( err );

    var result = data;
    for (var i=0; i<permissionsToRemove.length; i++)
        result = result.replace( "<uses-permission android:name=\"android.permission." + permissionsToRemove[i] + "\" />", "" );

    fs.writeFile( manifestFile, result, "utf8", function( err )
    {
        if (err)
            return console.log( err );
    } );
} );

For the bulk of the script https://stackoverflow.com/a/42182147

For the manifestFile path: https://stackoverflow.com/a/55563097

@adammaus the remove permissions hook you referred to worked for me! Thanks!

[ccerrillo]

Hi, Sorry I'm using Capacitor El jue., 6 oct. 2022 21:34, Michael Read ***@***.***> escribió:

…

@ccerrillo <https://github.com/ccerrillo> what version of cordova are you using? I'm on Cordova 11.0.0 and this does not appear to be removing this setting from our AndroidManifest.xml file. I don't see mode="remove" listed as an option in the Cordova docs: https://cordova.apache.org/docs/en/latest/plugin_ref/spec.html#edit-config — Reply to this email directly, view it on GitHub <#329 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACU66Q42WHOGI74HVKPU2DWB4STNANCNFSM54LYJKYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[adrenaline15]

For the capacitor-users, which are using this plugin and can not alter the config.xml:

Can you try to add the following line above the <application>-tag in your apps AndroidManifest.xml:

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" tools:node="remove"/>

[pmcquay]

another affected by this issue, would really like to use this without hacks to adjust it.

[patrikkelemen1]

In my config.xml <edit-config file="app/src/main/AndroidManifest.xml" target="/manifest" mode="remove"> <uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" /> </edit-config> 😋

thank you! the best solution for now is to update config.xml :)

[fabichacon]

Has anyone tried to complete the declaration in the Google Play console? Our app is already in production with the REQUEST_INSTALL_PACKAGES permission. I'm afraid of being penalized until I can publish a new version.

[ccerrillo]

Yes, and the request was denied, i compiled a new version without that permission El mié., 12 oct. 2022 17:26, Fabian Chacon ***@***.***> escribió:

…

Has anyone tried to complete the declaration in the Google Play console? Our app is already in production with the REQUEST_INSTALL_PACKAGES permission. I'm afraid of being penalized until I can publish a new version. — Reply to this email directly, view it on GitHub <#329 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACU66XMZ5D3CJQXSODCO6LWC3KDXANCNFSM54LYJKYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fabichacon]

Yes, and the request was denied, i compiled a new version without that permission El mié., 12 oct. 2022 17:26, Fabian Chacon @.> escribió:
…
Has anyone tried to complete the declaration in the Google Play console? Our app is already in production with the REQUEST_INSTALL_PACKAGES permission. I'm afraid of being penalized until I can publish a new version. — Reply to this email directly, view it on GitHub <#329 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACU66XMZ5D3CJQXSODCO6LWC3KDXANCNFSM54LYJKYQ . You are receiving this because you were mentioned.Message ID: @.>

@ccerrillo Thanks for the feedback! So, I will compile a new version without that permission and try again.

[dmitrikarpov]

The support for iOS has been added. Can anyone, who uses capacitor, install from the github using the below command to give it a try npm install capacitor-community/file-opener#chore/latest-version-with-dist-directory

Tried on iOS and got this error:
[log] - {"code":"UNIMPLEMENTED"}

[nathantaal]

@ccerrillo @fabichacon I compiled a new version but I cant submit it as it gets rejected immediately. Should I know just fill in the form to request the permission with the goal of getting rejected just so I can actually submit a new version..?

[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 #329 (comment) 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 😄 ) 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… 🙄

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