search

google / play-unity-plugins

The Google Play Plugins for Unity provide C# APIs for accessing various Play services
Other
435 stars 110 forks source link

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

Closed aplusm closed 3 years ago

aplusm commented 3 years ago

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

Volcore commented 3 years ago

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 commented 3 years ago

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

Thank you.

Volcore commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Thank you for the explanation @thanwah .

Volcore commented 3 years ago

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 commented 3 years ago

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

Working great on:

Same issue on:

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 commented 3 years ago

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 commented 3 years ago

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

Workaround:

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

binouze commented 3 years ago

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

traggett commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

FlynnMacfarlane92 commented 3 years ago

@aplusm have you tested 2020.2.5f1?

nmfisher commented 3 years ago

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 commented 3 years ago

@nmfisher Thanks! Works for 2020.3.0f1.

ahmetardal commented 3 years ago

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 commented 3 years ago

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

ellukitas-123 commented 3 years ago

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 commented 3 years ago

According to issue 1314472 this is fixed in

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

ellukitas-123 commented 3 years ago

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 commented 3 years ago

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

thanwah commented 3 years ago

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 commented 2 years ago

Jump botton

singIebit commented 1 year ago

The same problem in version 2021.3.5f1.

singIebit commented 1 year ago

The same problem in version 2021.3.15f1 too.

FahimKamal commented 9 months ago

The same problem is still present in version 2022.3.5f1.

FahimKamal commented 9 months ago

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.