Hi there! It looks like your issue requires a minimal reproducible example, but it is invalid or absent. Please prepare such an example and share it in a new issue.

The best way to get attention to your issue is to provide a clean and easy way for a developer to reproduce the issue on their own machine. Please do not provide your entire project, or a project with more code than is necessary to reproduce the issue.

A side benefit of going through the process of narrowing down the minimal amount of code needed to reproduce the issue is that you may get lucky and discover that the bug is due to a mistake in your application code that you can quickly fix on your own.

Resources

• "How to create a Minimal, Reproducible Example"
• "How to narrow down the source of an error"

Common concerns

"I've only been able to reproduce it in private, proprietary code"

You may not have spent enough time narrowing down the root cause of the issue. Try out the techniques discussed in this manual debugging guide to learn how to isolate the problem from the rest of your codebase.

"I didn't have time to create one"

That's understandable, it can take some time to prepare. We ask that you hold off on filing an issue until you are able to fully complete the required fields in the issue template.

"You can reproduce it by yourself by creating a project and following these steps"

This is useful knowledge, but it's still valuable to have the resulting project that is produced from running the steps, where you have verified you can reproduce the issue.

hi there! it's hard for us to help with the issue which we cannot reproduce. could you please create a minimal reproducible project and upload it to some git repositories? i'm happy to reopen and help then.

btw, google play console should have an ANR report to show the stacktrace which causing the ANR. you could try to dig and share more information from it.

i could understand it's hard to create an example or investigate issues that you cannot reproduce, and so do we.

please share the ANR report details with us. the ANR report on google play should indicate the stacktrace of each thread. that's something we could further take a look. let's see if you we find something in the reports together.

Unfortunately there is no ANR report download anymore. The original ANR messages are in the original bug report.

My guess is it is actually not expo notifications but expo updates

"main" tid=1 Native

  #00  pc 0x000000000004b38c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
  #01  pc 0x00000000001af92c  /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+148)
  #02  pc 0x000000000066b4b4  /apex/com.android.art/lib64/libart.so (art::GoToRunnable(art::Thread*)+460)
  #03  pc 0x000000000066b2a4  /apex/com.android.art/lib64/libart.so (art::JniMethodEnd(unsigned int, art::Thread*)+28)
  at android.database.sqlite.SQLiteConnection.nativeBindLong (Native method)
  at android.database.sqlite.SQLiteConnection.bindArguments (SQLiteConnection.java:1154)
  at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId (SQLiteConnection.java:934)
  at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId (SQLiteSession.java:790)
  at android.database.sqlite.SQLiteStatement.executeInsert (SQLiteStatement.java:88)
  at androidx.sqlite.db.framework.FrameworkSQLiteStatement.executeInsert (FrameworkSQLiteStatement.java:51)
  at androidx.room.EntityInsertionAdapter.insert (EntityInsertionAdapter.java:64)
  at expo.modules.updates.db.dao.AssetDao_Impl._insertUpdateAsset (AssetDao_Impl.java:269)
  at expo.modules.updates.db.dao.AssetDao.addExistingAssetToUpdate (AssetDao.kt:128)
  at expo.modules.updates.db.dao.AssetDao_Impl.access$101 (AssetDao_Impl.java:33)
  at expo.modules.updates.db.dao.AssetDao_Impl.addExistingAssetToUpdate (AssetDao_Impl.java:304)
  at expo.modules.updates.loader.Loader.handleAssetDownloadCompleted (Loader.kt:269)
  at expo.modules.updates.loader.Loader.downloadAllAssets (Loader.kt:222)
  at expo.modules.updates.loader.Loader.processUpdateManifest (Loader.kt:189)
  at expo.modules.updates.loader.Loader.access$processUpdateManifest (Loader.kt:18)
  at expo.modules.updates.loader.Loader$start$1.onSuccess (Loader.kt:101)
  at expo.modules.updates.loader.EmbeddedLoader.loadManifest (EmbeddedLoader.kt:58)
  at expo.modules.updates.loader.Loader.start (Loader.kt:91)
  at expo.modules.updates.loader.LoaderTask.launchFallbackUpdateFromDisk (LoaderTask.kt:242)
  at expo.modules.updates.loader.LoaderTask.start (LoaderTask.kt:99)
  at expo.modules.updates.UpdatesController.start (UpdatesController.kt:290)
  at expo.modules.updates.UpdatesController$Companion.initialize (UpdatesController.kt:464)
  at expo.modules.updates.UpdatesPackage$createReactNativeHostHandlers$handler$1.onWillCreateReactInstanceManager (UpdatesPackage.kt:41)
  at expo.modules.ReactNativeHostWrapperBase.createReactInstanceManager (ReactNativeHostWrapperBase.kt:27)
  at com.facebook.react.ReactNativeHost.getReactInstanceManager (ReactNativeHost.java:42)
  at com.pokebattler.raidParty.MainApplication.onCreate (MainApplication.java:76)
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1192)
  at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6808)
  at android.app.ActivityThread.access$1400 (ActivityThread.java:250)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1973)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loop (Looper.java:250)
  at android.app.ActivityThread.main (ActivityThread.java:7766)
  at java.lang.reflect.Method.invoke (Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:604)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:958)

The most likely culprit looking into this is my very large number of icons. My assets folder has 9,844 files in it, the vast majority being pngs with 2x and 3x versions. (64x64 128x128 192x192)

@Kudo Ive looked through the code base in details and have a summary of what the issues are. If there is someone who works on expo-updates who I could speak with on Discord or via email that would be great,

The core issue is the startup time for expo updates has a large number of synchronous calls that must complete before the app is loaded. If these calls take too long, this causes an ANR. I see most of the ANRs are on low end devices and also in background processing which makes sense.

There exists a checkOnLaunch option, it does not avoid enough of the synchronous calls to avoid the ANRs.

The first ANR is the above stack trace with the EmbeddedLoader.loadManifest when there is an update to be downloaded. Part of this is local and part of this can be skipped using checkOnLaunch flag.

The second ANR is the alternative branch that uses DatabaseLoader.initialize lines 86-96 which is used when initializing from the local disk This is a loop of file system calls on application start that causes an ANR with the number of assets I have.
Looking at the diff from sdk-46 to sdk-47 there is an additional continue that skips the expensive check

patch-package expo-updates+0.14.5.patch:

diff --git a/node_modules/expo-updates/android/src/main/java/expo/modules/updates/launcher/DatabaseLauncher.kt b/node_modules/expo-updates/android/src/main/java/expo/modules/updates/launcher/DatabaseLauncher.kt
index 9c62461..91756e1 100644
--- a/node_modules/expo-updates/android/src/main/java/expo/modules/updates/launcher/DatabaseLauncher.kt
+++ b/node_modules/expo-updates/android/src/main/java/expo/modules/updates/launcher/DatabaseLauncher.kt
@@ -85,6 +85,11 @@ class DatabaseLauncher(

     localAssetFiles = mutableMapOf<AssetEntity, String>().apply {
       for (asset in assetEntities) {
+        //patch from sdk-47
+        if (asset.id == launchAsset.id) {
+          // we took care of this one above
+          continue
+        }
         val filename = asset.relativePath
         if (filename != null) {
           val assetFile = ensureAssetExists(asset, database, context)

So my action item for now is

1. patch in the continue block
2. add in checkOnLaunch = NEVER
3. use Updates.checkForUpdateAsync and Updates.fetchUpdateAsync to do updates.

Improving expo-updates to improve performance when using checkOnLaunch=NEVER or maybe even making this check always async to improve performance for all users is something I might be willing to contribute if there is interest. I realize my 10,000 pngs case is not the norm but its a good test case

hi @celandro thanks for further investigating the diff. i can confirm the problem exist and i would like to reopen this issue and follow up with team.

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

Tracked in ENG-7652