App crashes on Android 7 #983
Description
Describe the bug
The app crashes upon opening when using a device that is running Android 7. Was able to test this using a the Samsung Galaxy S8 device from Browserstack App Live.
To Reproduce
- Use device that's on Android 7
- Open app
Expected behavior
Android 7 is the oldest supported Android version that our app can run on, so it shouldn't crash like this upon opening.
Additional context
Stacktrace of the crash:
02-18 21:55:43.511 E/AndroidRuntime(31453): FATAL EXCEPTION: AsyncTask #1
02-18 21:55:43.511 E/AndroidRuntime(31453): Process: com.comapeo.rc, PID: 31453
02-18 21:55:43.511 E/AndroidRuntime(31453): java.lang.NoSuchMethodError: No virtual method toPath()Ljava/nio/file/Path; in class Ljava/io/File; or its super classes (declaration of 'java.io.File' appears in /system/framework/core-oj.jar)
02-18 21:55:43.511 E/AndroidRuntime(31453): at org.apache.commons.io.FileUtils.newOutputStream(FileUtils.java:2552)
02-18 21:55:43.511 E/AndroidRuntime(31453): at org.apache.commons.io.FileUtils.copyToFile(FileUtils.java:1077)
02-18 21:55:43.511 E/AndroidRuntime(31453): at org.apache.commons.io.FileUtils.copyInputStreamToFile(FileUtils.java:986)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.UpdatesUtils.verifySHA256AndWriteToFile(UpdatesUtils.kt:115)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.LoaderFiles.copyContextAssetAndGetHash$expo_updates_release(LoaderFiles.kt:49)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.LoaderFiles.copyAssetAndGetHash(LoaderFiles.kt:33)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.EmbeddedLoader.loadAsset(EmbeddedLoader.kt:84)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.Loader.downloadAllAssets(Loader.kt:242)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.Loader.processUpdate(Loader.kt:207)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.Loader.access$processUpdate(Loader.kt:27)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.Loader$start$1.onSuccess(Loader.kt:115)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.EmbeddedLoader.loadRemoteUpdate(EmbeddedLoader.kt:58)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.Loader.start(Loader.kt:100)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.LoaderTask.launchFallbackUpdateFromDisk$lambda$1(LoaderTask.kt:327)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.LoaderTask.$r8$lambda$iWaynmXs01Iemf5P5q3fr3FdLwE(LoaderTask.kt)
02-18 21:55:43.511 E/AndroidRuntime(31453): at expo.modules.updates.loader.LoaderTask$$ExternalSyntheticLambda2.run(D8$$SyntheticClass:0)
02-18 21:55:43.511 E/AndroidRuntime(31453): at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:243)
02-18 21:55:43.511 E/AndroidRuntime(31453): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
02-18 21:55:43.511 E/AndroidRuntime(31453): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
02-18 21:55:43.511 E/AndroidRuntime(31453): at java.lang.Thread.run(Thread.java:762)Looks like it's an issue with expo-updates, which has most likely been fixed via expo/expo#34638.
We should consider if we want to have expo-updates enabled in the app or not. It's currently enabled but we don't actually use this functionality, nor do we have a concrete short-term plan to. It adds some overhead for the app since it's doing http calls in the background.
otherwise: if we decide not to change anything, we should update expo-updates when a release with the projected fix is out.