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]
@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.)
This is our setting:
“permissions”: [ ]
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.
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.
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.
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
"package": "my package number",
"bundleIdentifier": "my bundle number",
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)?
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.
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.
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.
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.
Interesting - mine still hasn’t been approved. Though I did just this
This is not clear. Does this mean we MUST add the
--no-publish flag in order to get back in the app store or will just re-building be enough?
My last build was April 13th and it is still rejected and removed. I am using “expo”: “^32.0.0”. Is this ok?
how check from js code if we have branch SDK insluded now(in standalone application builded with expo)?
if i check “if (DangerZone.Branch)” i receive
04-17 12:26:55.760 14866-14984/? E/ReactNativeJS: undefined is not an object (evaluating ‘c.STANDARD_EVENT_ADD_TO_CART’)
04-17 12:26:55.768 14866-14984/? E/ReactNativeJS: TypeError: undefined is not an object (evaluating ‘r(d).default’)
looks like any trying to looks into DangerZone will cause errors
You do not need to add the
--no-publish flag. That just simply makes it so you don’t push an OTA update if, for instance, you had some code you didn’t want to push to prod in your local environment yet.
You can just search using your IDE for those keywords.