dlopen failed: cannot locate symbol "__emutls_get_address" referenced by "/lib/arm64/libfolly_runtime.so"

dlopen failed: cannot locate symbol "__emutls_get_address" referenced by "/data/app/xadfadsfas==/xxxxxxx==/lib/arm64/libfolly_runtime.so"

https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/jni/third-party/folly/CMakeLists.txt

target_compile_options(folly_runtime PUBLIC ${folly_FLAGS})

target_include_directories(folly_runtime PUBLIC .)

Where, In the app. we need to check runtime libraries, 

Which will be residing under jniLibs folder.

If your application includes multiple shared libraries, you should use libc++_shared.so.

On Android, the libc++ used by the NDK is not the same as the one that's part of the OS. This gives NDK users access to the latest libc++ features and bug fixes even when targeting old versions of Android. The trade-off is that if you use libc++_shared.so, you must include it in your app. If you're building your application with Gradle this is handled automatically.

Old versions of Android had bugs in PackageManager and the dynamic linker that caused installation, update, and loading of native libraries to be unreliable. In particular, if your app targets a version of Android earlier than Android 4.3 (Android API level 18), and you use libc++_shared.so, you must load the shared library before any other library that depends on it.

libc++ is not a system library. If you use libc++_shared.so, it must be included in your app. If you're building your application with Gradle this is handled automatically.

run the command nm -gD libc++_shared.so

Where __emutls_get_address method is missing in the libc++_shared.so, Update the latest libc++_shared.so, the problem will be solved

Android INSTALL_FAILED_INVALID_APK base.apk is missing

Issue was caused by testCoverageEnabled true in build.gradle, Latest gradle versions above 7.3 have the issue with jacoco

Google Maps No Longer Requires STORAGE Permission!

For a long time, Google Maps Android SDK requires us to have WRITE_EXTERNAL_STORAGE permission. It was not the case when they first released the SDK.

I didn’t want to have that storage permission first, because In app permission “The permission description says that the application can access files on the devices such as images, videos or audio”. 

I had lots of 1, 2, 3 stars in app ratings because of this. Users say that “Why do you request access for my photos and videos?”. They are right! They are always right. I don’t want to access your photos and I won’t. I am forced to have that permission.

Android Marshmallow brought us run-time permissions. They are great! Users do not see permissions when they install or update the app. Users have more control over the app’s functionality.

for example, a user could choose to give a camera app access to the camera but not to the device location.

But imagine you have an app with Google Maps integration, and imagine you have to request WRITE_EXTERNAL_STORAGE on runtime to show the map. How would you explain that to users? Runtime permissions that are not obvious and require explanation are the worse. This is one of them.

Fortunately, they fixed the issue and removed storage permission. But not for all, just for Android Marshmallow.

If you use Google Maps and you want to target Android Marshmallow, this is what you need to do:

• First you need to use Google Play Services 8.1.0
• Second, you need to add maxSdkVersion property in your permissions as shown below:

They also say in the documentation that they will remove it completely in the next release.

From the next release of the Google Play services SDK, the requirement for the WRITE_EXTERNAL_STORAGE permission will be completely dropped from the Google Maps Android API.

Note: Please do the described changes in your application if you have Google Maps and want to target Android M!

Thanks for reading :) 

Whether this post is helpful?

Have something to add to this post? If you have any other quick thoughts/hints that you think people will find useful? Share it in the comments. feedback are welcome...