App removed from Google Play due to policy violation with Branch

For the record, we are using:

  • Standard build (not ejected)
  • SDK 32

We have a privacy policy.

Just following up that the updates to our remaining supported SDK (#s 26-31) version builders was deployed last night.

As @adamjnav mentioned above: once your version builder is updated, you’ll just need to build a new binary via expo build:android and submit it to the play store. Remember you can pass the --no-publish flag to the build command if you do not want to push any JS changes.

If your app is running a version older than that, you will have to update to an officially supported version.

We’ll be back here on this thread when ExpoKit versions are also updated.

Cheers,
Jess

1 Like

Does use of Link.open(url) counts as use of Branch module?

Hey @simb4,

A good rule of thumb is if you have this import { DangerZone } from 'expo'; let { Branch } = DangerZone; in your code, you’re making use of the Branch module.

2 Likes

Hi everyone,

Update on our current state in addressing this:

  • SDK 26-32 (all supported + current) version builders were updated on Monday night.
  • turtle-cli has also been updated
  • ExpoKit on SDKs 30, 31, and 32 has been updated
  • Read our blog post for more background and instructions for turtle-cli and ExpoKit SDK30-32 users.

For ExpoKit on SDK 26-29, we’re still in the process of backporting these changes and releasing ExpoKit patches.

—————————

Question for this thread!

It would help us keep investigating better solutions/workarounds to this if you can tell us what your android.permissions setting is in app.json. [cc @kaivosukeltaja @johnfredadams @fortumappse @angeleah]

Thanks,
Jess

1 Like

@jess do you think it could be because of the InstallListener receiver? I had that in my AndroidManifest.xml

I’m requiring all by default. (I have no setting specifically set.)

1 Like

This is our setting:
“permissions”: [ ]

1 Like

maybe disableTracking for Branch resolve collecting installed packages information?

Hi, I have this problem too but i’m running into issues upgrading to the latest release of Expo for my app.

I built my App with SDK version 18.0.0 and published it a long time ago. Around January I decided to work on it again and have started completely over from scratch. I got the same email as the others in this thread with the delisting of my app.

When I finish copying the code over to the new version of the SDK, and get ready to launch how do I handle the keystore stuff and making sure the stores realize its an overhaul and not a completely new app? What do I need to copy from the app.json in my 18.0.0 version to the new 32.0.0 version? I also elected to have you guys store they keystore and related stuff, and i’m not sure how to tell the CLI to replace everything that it has with the new code i’m writing now, and use the keystore associated with the 18.0.0 version.

Sorry for the wall of text, but am worried about how to update this so i can republish on the marketplaces.

Any help you can provide would be greatly appreciated.

EDIT: Additionally, I never ejected my app so i’m not sure why I got it but i do have a privacy policy in place.
Thanks!

Hey @utahisnotastate, since Branch was bundled in (until our latest fixes), it affected apps built for Android broadly (not just ejected apps, though the issue was reported here early on). You can read more context and detail here.

A good first step would prob be to take a look at the SDK upgrade walkthrough on docs so you can take a look at all the breaking changes, etc.

It only goes back to SDK 21 (December 2017), but upgrade instructions are include in each of our SDK release blog posts (I imagine you’d start with SDK 19).

Hope that gets you off to a good start.

Cheers,
Jess

@jess

Thanks for getting back to me. When I started reworking the code base in january, I decided it was better to just create a brand new project in the CLI, and then rewrite the code to support the latest version of Expo SDK. From your post, are you saying I have to manually go from 18 to 32? I can’t just create a blank project, copy in the code that works, and then change its app.json to be the same as the 18.0.0 version?

Oh! I totally misunderstood. If your current project supports 32 then, no, I don’t believe you should have to go through all those upgrades! I think @adamjnav might be able to take a peek in a bit and make a recommendation.

@jess

Awesome, i’ll wait for adam to confirm, but I’ve rebuilt the app from the ground up with 32.0.0 so that’s a relief.

My other concern was actually building and generating the .apk and .ipa files. I would just copy the

 "android": {
      "package": "my package number",
      "versionCode": 3
    },
    "ios": {
      "bundleIdentifier": "my bundle number",
      "buildNumber": "6",
      "supportsTablet": true
    }

from my 18.0.0 app.json and then move that over to the new project, right ( and update the build numbers as well)? I built and released using xde initially. I’ve moved on to the cli you use now, but when I move the above code into the new app.json the CLI will know to bundle in the old keystore and everything right (assuming i’m logged in)?

Hey @utahisnotastate,

As long as the expo account, slug, bundleIdentifier and package values are all the same there should be no issue fetching Apple credentials and Google Keystores. One piece of advice I would relay to you is to incrementally look at the Breaking Changes section of each SDK release blog post to ensure your app runs smoothly.

Cheers,
Adam

@adamjnav

That’s great to hear. I’ll go ahead and build and resubmit. I’ll post back if I run into any issues.

Thank you so much for taking the time to respond to me, I really appreciate it.

2 Likes

one interesting thing: we rebuild applications without Branch SDK and upload to google play, push release to production but nothing happens, it still was removed. But after deleting all old releases(with included Branch) applications become active.

1 Like

Thanks @hubex_developers! — this jives with what we understand about issues needing to be fixed on all release tracks, not just production. I’ll update our blog post with a little reminder so others aren’t caught off guard.

1 Like

Interesting - mine still hasn’t been approved. Though I did just this