You'll need to complete a declaration soon for apps using REQUEST_INSTALL_PACKAGES

Please provide the following:

  1. SDK Version: 40
  2. Platforms(Android/iOS/web/all): all
  3. Add the appropriate “Tag” based on what Expo library you have a question on.

I just got the below message in the Google Play Console today. I am using the managed workflow with the classic build and I am unaware of what REQUEST_INSTALL_PACKAGES does and it’s not listed under the android.permissions node in my app.json file.

Is anyone aware what this could mean?


Title: You’ll need to complete a declaration soon for apps using REQUEST_INSTALL_PACKAGES

Subject: We found that your manifest file contains the REQUEST_INSTALL_PACKAGES permission.

Starting September 29, 2022, apps that use this permission will not be able to submit updates for review until they have completed a new sensitive permission declaration.

This declaration will be available in Play Console on August 31, 2022. You’ll need to declare which permitted functionality your app provides, tell us about a core feature in your app that uses the permission, and provide a video showing its use.

You must remove this sensitive permission from your manifest if your app does not use the permitted functionalities, or if you no longer use this permission. To learn more, watch this PolicyBytes video.

Hi @apps.genie

According to the following issue, this permission is automatically added by expo-device:

Are you using expo-device? Are you building with EAS Build or expo build?

If you’re building with EAS Build and using expo-device, but do not need Device.isSideLoadingEnabledAsync(), then try blocking the android.permission.REQUEST_INSTALL_PACKAGES permission like this:

{
  "expo" : {
    ...
    "android": {
      "blockedPermissions": [
        "android.permission.REQUEST_INSTALL_PACKAGES"
      ]
    }
  }
}

I am on managed workflow and not using EAS, still using the classic build. And yes I use expo-device but for some basic consts out of it and not even calling any methods, so not using isSideLoadingEnabledAsync(). What would you suggest?
Are the latest Expo SDKs somehow not requiring REQUEST_INSTALL_PACKAGES as part of expo-device anymore?
Does blockedPermissions not work for managed flow?

and looks like my package.json has this:
"expo-device": "~3.3.0"
maybe I can just upgrade it in my existing SDK 40…

That is my understanding, yes. I see you’re on SDK 40, so you might need to upgrade.

Yes, it does… as long as you’re using EAS Build :slight_smile:
It is not applicable to the Bare workflow, and it will not work with the classic build system.

Unfortunately you can’t upgrade arbitrarily. You have to stick to a version that’s compatible with the version of the Expo SDK that you’re using. And that looks like version 2.4.x

So it seems to me that you will have to either eject to the Bare workflow and manually add the tools:node="remove" stuff to the AndroidManifest.xml or upgrade to a later version of the Expo SDK with a fixed version of expo-device.

Also bear in mind that the classic build system is going away around the end of the year, so you might want to upgrade and switch to EAS Build soonish.

thank you so much. yes very useful information and I am planning to upgrade to EAS this year since classic build is going away. My only issue so far with going the EAS route is that it seems like I will not be able to easily do OTA updates (for free). At this time I am not even sure if paid will help. TBH I don’t understand the OTA updates part here with EAS and how it works. I really like the expo publish and it’s honestly one of the main reasons for using Expo. Fixing a bug is super fast! So if I can do that with EAS as easily, I would switch faster.

Meanwhile, definitely not wanting to eject, so will try upgrading the Expo SDK in the existing managed flow for now. If say, I am not ready to jump to the latest SDK version, and I have to pick a lower SDK version, would there be an easy way for me to verify if it has this REQUEST_INSTALL_PACKAGES in there?

The EAS Update service is currently a paid service. There will be a “free tier” like their other services “later this year”.

First 1,000 Monthly Active Users (MAU) will be included with the Free tier later this year
Then, $5 per 1,000 MAU

However, the specifications are published, so you could implement this yourself with a bit of effort. Of course, then you would have to pay Amazon or Google or someone if you’re running the service on AWS or GCP etc.

The old expo publish updates should still work as before. Not sure if/when that service will be shut down.

My understanding of updates with EAS Build is that it’s basically the same as apps built with the classic build system, except that there’s no longer a well defined SDK version that you can rely on to decide which updates to apply and which to ignore. This is an unfortunate consequence of the power of EAS. i.e. the fact that EAS Build allows you to include arbitrary dependencies that include native code, and also, EAS Build only includes the dependencies you have specified in your package.json, which means that the app is smaller than a corresponding app built with the classic build service.

Because of the above, an app built with EAS Build will usually not include all of the native code that would be included in an app built with the classic build system. So e.g. if you create a build without the camera/barcode scanner and you later want to add barcode scanning to your app, you can’t rely on the fact that the app is still build with the same version of the Expo SDK. The original build does not have the native code required for camera/barcode scanning support. So if you push an OTA update and the app loads it, it will crash when it tries to access the camera.

To avoid this, you should specify the Runtime Version of the build and update that every time you make a new build. (Technically you only need to update it if your new build has incompatible native code, but it might not always be easy to tell that for sure.)

I haven’t actually looked into this fully myself, but here are some docs that talk about this:

You can use the aapt command for this. It should come as part of the Android SDK:

aapt d permissions /path/to/com.your.package.apk

my hope is to move to EAS Build when EAS Update becomes free (however, I am still trying to understand that free tier … first 1000 updates only or first users just opening the app first time?)

I did not know I could implement EAS Update myself… Not sure I will have the recourses to do that, but is that basically like a place to host the the JS bundles myself that the app checks against each time it loads?

and what is the point to have EAS Update if expo publish will still work… I guess I am confused how one is different than the other… Since I thought that if I move to EAS I have to be on the new OTA updates logic all part of EAS ecosystem…

and yes I can see the benefit of EAS to only include packages that I need, but is the danger that I could get mixed up version in relation to the expo SDK version (or in relation to themselves)? or as long as it builds/runs locally I am good…

also totally understand that the OTA updates are non-native code which is totally fine, adding a whole new feature (like the camera barcode scanner) makes sense to be a new build and go thru the full app store publish process. I even do that today, even though I could implement a feature using native code that is ‘dormant’ on client devices.

I need to look more into runtimeVersion, kinda sounds ok to only update that version OTA but also means I have to keep track of all that more now… wonder what runtimeVersion does now for me on classic build…

on top of this… the other thread with the com.segment.analytics.android issue is also present so I have to fix both com.segment.analytics.android and REQUEST_INSTALL_PACKAGES in one shot somehow… I hope just upgrading to the expo SDK fixes both and I could check the versions via aapt like you mentioned… I don’t think I have the android SDK though :thinking:

lot to learn / try out … :smile:

I’m not entirely sure of the details myself :sweat_smile:

Yes. @ide links to the spec in this tweet.

The spec is here:

https://docs.expo.dev/technical-specs/expo-updates-0/

I haven’t had a proper look at it, but as far as I understand it it’s basically a web service.

Btw., I’ve just tried expo publish on an Expo SDK 44 app built with EAS Build. (JS engine is JSC. I haven’t tried it with a Hermes app yet.) The update worked as expected.

For the reasons, see:

I assume they intend to get rid of the classic update system at some point.

Yes, there is a danger that you might install a new dependency (e.g. react-native-svg) that you did not have installed when you built the app. If you publish an update that makes use of the new dependency and the old app installs the update, then it will crash. So you can no longer depend on the SDK version for compatibility. You’ll need to have a runtimeVersion that you update if you install new dependencies. See the links in my previous comment.

OK, then it seems like you might not really have to change your processes/procedures much :slight_smile:

runtimeVersion is not relevant to the classic build system.

I think upgrading to Expo SDK 45 should fix them. Not sure if earlier SDK versions will fix both of them.

You can get it from here, although the instructions are not as simple as one might like:

Oh, and it’s aapt2. I forgot it has a 2 on the end :slight_smile:

Indeed. Good luck :slight_smile:

As far as JavaScriptCore vs Hermes, not too familiar with the difference, but I dont have an expo.jsEngine setting in my app.json, so this means I am on JSC now on classic build? will converting my existing managed flow app to EAS be in JSC or Hermes? I hope its JSC as it seems that you said expo publish works still (that’s good news for me)!

oh and I am on expo SDK 42 (not sure why I had 40 here), but yea looks like gotta upgrade to latest to hopefully fix all the issues (assuming that goes smooth).

and thanks for all the education so far!

The classic build is always JSC. With EAS Build you have an option, but if you don’t specify it’s JSC.

I am not saying expo publish will break with Hermes, but I have not tried it.

Got it. Will try it out :slight_smile:

Here’s some more clarification on implementing EAS Updates yourself:

Oh nice. thank you. I will have to check as the current pricing of $5 per 1,000 updaters is quite high :frowning:. Just for 10k users to push out and update would cost me $50… and sometimes I just want little updates here and there (like even spellings or colors). And now would have to think about it wisely…

I really liked the old option of $30/month and now seems like it’s getting expensive to use Expo…

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.