Open lordtao opened 1 month ago
build.gradle
included
ndk {
abiFilters += listOf("armeabi-v7a", "arm64-v8a", "x86", "x86_64")
}
Some discussion on an old Mapbox issue: https://github.com/mapbox/mapbox-gl-native/issues/15331
Not sure how to reproduce this...
Additional information
compileSdk = "34" targetSdk = "34" minSdk = "26" androidBuildTools = "34.0.0"
Ruben from Flitsmeister shared on Slack:
According to our crashlytics this happened to 47 users in the last month, which is like ~0.005% of our monthly android userbase so it doesn't happen often.
Some more devices this is happening with:
We're seeing this issue too. It occurs very rarely, but for the users it affects the issue is permanent. AFAICT the affected devices are either very cheap Android phones or automated testing devices through in Google Play pre-launch reports. So far we ignored the issue because it is so exceedingly rare among our users.
Our assumption so far was that the database behind Google Play's app bundle (.aab
) to APK conversion has incorrect information about the supported ABIs of the devices, i.e. the .so
variant the device actually tries to load is not included in the APK produced by Google Play. Most likely the device supports multiple ABIs (e.g. armeabi-v7a
and arm64-v8a
) but the prioritization is different between the on-device logic and Google Play. Only one .so
variant will be included in the APK (that's kind of the point of the app bundle system) and the device tries to load the other one.
If this assumption is correct, the remaining question is: Why does the device not fall back to loading the other supported ABI? Is this something maplibre can solve or is it a bug in the Android implementation of the device?
With maplibre-android-sdk 11.5.2, I'm getting this error on every launch of an app on an Android 15 emulator. Reverting to 11.5.1 fixes the issue.
It occurs specifically on api 35 16kb page size devices. Starting 11.5.2, libmaplibre.so is not 16 KB ELF aligned anymore (done in #2429) which leads to load failure Maybe a branch or build process issue ?
@bruno-obv Thanks that is a problem indeed! Fix will be released today.
We can keep this issue open for other similar problems...
Firebase crash log
libs.version.toml
To Reproduce Steps to reproduce the behavior:
Platform information
The crash was only seen on this user's devices:
Device Brand: Vivo Model: Y27s Orientation: Portrait RAM free: 3.87 GB Disk free: 189.88 GB
Device Brand: Vivo Model: Y18 Orientation:Portrait RAM free: 2.34 GB Disk free: 81.6 GB
Operating System Version: Android 14 Orientation: Portrait Rooted: No