Unity 2020.2 and AssetDelivery: Failed to load 'libmain.so'

[aplusm]

Unity: 2020.2.1f1 play-unity-plugins: 1.3.0

Device: Samsung Galaxy A51 Android 10

I have 3 assets bundles, configured with Asset Delivery, with a delivery mode of Install Time. When using Google > Build and run, the following error messages is displayed on my device:

**Failure to intialize!**

Your hardware does not support this application.

Failed to load 'libmain.so'

java.lang.unsatisfiedLinkError: dlopen failed: library "/data/app/com.XXXX-c-_aXwZP3J_AXFvQqnTxqg==/lib/arm64/libmain.so not found

Press OK to quit

Further information

• Without an AssetBundle folder, or when delivery mode is set to Do not pack, no issue occurs.
• This exact same process was OK with Unity 2019.

[Volcore]

Seeing he same issue. Just building using the normal Unity build pipeline is fine. Was in the process of adding Play Asset Delivery, so switched build tool to Google, and now seeing this issue.

[aplusm]

Were you able to look into this issue ? Do you need more information from my side ?

Thank you.

[Volcore]

Sadly, no. Still waiting on a reply from Google.

We are luckily under 150mb right now so we are just bundling everything, but we will need this fixed in the next few months...

[thanwah]

Hi @aplusm and @Volcore, thank you for filing this issue.

I was able to reproduce the problem on a test device running Android 11 (it didn't seem to affect some older Android versions). I will try to figure out the underlying cause and create a fix.

[thanwah]

On modern versions of Android, it's possible to load native libraries directly from an APK (e.g. split_config.armeabi_v7a.apk) if the libraries are stored uncompressed. This worked on Unity 2020.1 and prior versions, but seems not to work on 2020.2.

Next I'll check to see if this has something to do with the versions of Android Gradle Plugin or bundletool that are used by Unity's built-in AAB export vs this plugin's AAB export that supports asset packs.

[aplusm]

Thank you for the explanation @thanwah .

[Volcore]

In my investigations I noticed that with the Google build system, the binary folders were incorrectly named. I think it was /lib/armv8a-64 vs /lib/armv8a or something like that. I would guess that's why it can't find the binaries. Maybe this changed in Unity 2020.2?

[Mercandj]

Hello, thks for your issue, that help me a lot. I confirme:

Working great on:

• 2020.1.17f1 (C# 7.3)

Same issue on:

• 2020.2.3f1 (C# 8)
• 2020.2.1f1 (C# 8)

I'm using Unity as a library (via project export and :unityLibrary gradle module generation as .aar).

Error reproduced only via app bundle: working great with apk. Tested app bundles generated via the PlayStore and bundletool.

The app trying to load /lib/arm64/libmain.so and fail. Tested with IL2CPP, the aab contains only arm64-v8a, armeabi-v7a folders (no arm64).

---

Related issues here and here

[thanwah]

OK, I've narrowed this down. The issue has nothing to do with Play Asset Delivery specifically, but rather Android's extractNativeLibs feature. This is configured in bundletool as uncompressNativeLibraries.

When this feature is enabled and working on a modern Android device, you should not to see any .so files inside of /data/app/<package-name-etc>/lib/<abi/ since these files are loaded dynamically from the APK, e.g. split_config.armeabi_v7a.apk. This feature speeds up app download time from Play (we use compression that is better than ZIP's DEFLATE), improves installation time (don't need to extract the .so), and reduces disk space used by the app (don't need to store a DEFLATED + uncompressed .so).

I tested both Unity 2020.1 and 2020.2 with both the "Export Project" feature followed by building an AAB, and Unity's built-in AAB build. This is 4 possible cases.

Note: I installed each test app via:

java -jar ~/Downloads/bundletool-all-1.4.0.jar build-apks --bundle test.aab --output test.apks
java -jar ~/Downloads/bundletool-all-1.4.0.jar install-apks --apks=test.apks

Case 1: Unity 2020.1 + build AAB within Unity:

java -jar ~/Downloads/bundletool-all-1.4.0.jar dump config --bundle test.aab | grep uncompressNativeLibraries -A 2
    "uncompressNativeLibraries": {
    }
  },

Result: .so files were extracted within /data/app 👎, and app runs fine 👍

Case 2: Unity 2020.1 + Export Project + ./gradlew launcher:bundleDebug:

java -jar ~/Downloads/bundletool-all-1.4.0.jar dump config --bundle launcher/build/outputs/bundle/debug/launcher-debug.aab | grep uncompressNativeLibraries -A 2
    "uncompressNativeLibraries": {
      "enabled": true
    }

Result: .so files were NOT extracted within /data/app 👍, and app runs fine 👍

Case 3: Unity 2020.2 + build AAB within Unity:

java -jar ~/Downloads/bundletool-all-1.4.0.jar dump config --bundle test.aab | grep uncompressNativeLibraries -A 2
    "uncompressNativeLibraries": {
    }
  },

Result: .so files were extracted within /data/app 👎, and app runs fine 👍

Case 4: Unity 2020.2 + Export Project + ./gradlew launcher:bundleDebug:

java -jar ~/Downloads/bundletool-all-1.4.0.jar dump config --bundle launcher/build/outputs/bundle/debug/launcher-debug.aab | grep uncompressNativeLibraries -A 2
    "uncompressNativeLibraries": {
      "enabled": true
    }

Result: .so files were NOT extracted within /data/app 👍, and app crashes 👎

To be clear the above testing was done without any plugins in this GitHub project. These were just empty Unity projects and then we either built the AAB within Unity or ran "Export Project" and then build the AAB from the command line with gradle.

Collectively, this implies that Unity 2020.2 stopped supporting Android's uncompressNativeLibraries feature. Given the several aforementioned latency and disk usage benefits of this feature, my suspicion is that this was an accidental regression. I'll see if I can follow-up with Unity about a fix.

Note: as a workaround for someone who urgently needs to use Play Asset Delivery with Unity 2020.2, they could modify this plugin's code to always set config.optimizations.uncompressNativeLibraries.enabled=false. I don't really recommend this however, and will check to see if Unity can fix the issue on their end.

[nick-dodonov]

Reproduced in pure empty project in Unity 2020.2.3f1. Reported as (Case 1314472).

Workaround:

• Use custom gradle properties template
• Add to its end: android.bundle.enableUncompressedNativeLibs=false

(It's the only difference between Exported Project and the project located in Temp when building from GUI)

[binouze]

Any news from Unity about this ? I don't find any bug with this case number.

[traggett]

I'm also waiting to hear more on this - is there a bug open with Unity's issue tracker we can upvote? Have they got back to you at all?

[aplusm]

I reported this issue to Unity as Case 1312344 on February 5. No feedback since then.

I just asked QA to tag this case as public so you'll be able to upvote it.

[aplusm]

The official issue on the IssueTracker: https://issuetracker.unity3d.com/product/unity/issues/guid/1314472

[FlynnMacfarlane92]

@aplusm have you tested 2020.2.5f1?

[nmfisher]

Repeating what I said here, in case it's useful for some people:

This is still an issue with 2020.3.0f1 (also the gradle.properties workaround is not working in my Flutter project either).

EDIT:

Actually adding android:extractNativeLibs="true" to the element in AndroidManifest.xml as a temporary workaround does work with 2020.3.0f1. This might be specific to my version of Gradle (per | Android Developers, this is set to false by default in Android Gradle plugin 3.6.0).

This isn't a long-term solution as Unity should be able to handle loading native libraries without extracting to the filesystem first.

I also confirm this is still present in 2021.1.0b11

[ahmetardal]

@nmfisher Thanks! Works for 2020.3.0f1.

[ahmetardal]

Reproduced in pure empty project in Unity 2020.2.3f1. Reported as (Case 1314472).

Workaround:

• Use custom gradle properties template
• Add to its end: android.bundle.enableUncompressedNativeLibs=false

(It's the only difference between Exported Project and the project located in Temp when building from GUI)

This works for Android bundles. Thanks @nick-dodonov

[binouze]

Hi, Anyone tried with version 2021.1.1 ? This version seems to fixe the issue as noted on release notes.

[ellukitas-123]

Hi, Anyone tried with version 2021.1.1 ? This version seems to fixe the issue as noted on release notes.

When you update the project there is an error

[thanwah]

According to issue 1314472 this is fixed in

• 2021.2.0a11
• 2021.1.2f1
• 2020.3.3f1

Note that some of these versions aren't yet live in Unity Hub.

[ellukitas-123]

According to issue 1314472 this is fixed in

• 2021.2.0a11
• 2021.1.2f1
• 2020.3.3f1

Note that some of these versions aren't yet live in Unity Hub.

In 2021.2.0a11: You need to change all package scripts with te minimal android api level from 21 to 22

[thanwah]

I just tested Export Gradle Project, build AAB, and install APKs on two versions of 2020.3:

• 2020.3.2f1 - crashed
• 2020.3.3f1 - worked

[thanwah]

Added a check for versions of Unity that will crash. Better that developers know of this issue at build time than encounter a potentially mysterious crash at runtime.

[Shahnawazalam01799]

Jump botton

[lucaselblanc]

The same problem in version 2021.3.5f1.

[lucaselblanc]

The same problem in version 2021.3.15f1 too.

[FahimKamal]

The same problem is still present in version 2022.3.5f1.

[FahimKamal]

Reproduced in pure empty project in Unity 2020.2.3f1. Reported as (Case 1314472).

Workaround:

• Use custom gradle properties template
• Add to its end: android.bundle.enableUncompressedNativeLibs=false

(It's the only difference between Exported Project and the project located in Temp when building from GUI)

@nick-dodonov Thanks. Your solution worked for me.