Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Satellite assemblies for other locales than the default are not deployed when EmbedAssembliesIntoApk = true #9532

Open
Cheesebaron opened this issue Nov 20, 2024 · 2 comments · May be fixed by #9533
Assignees
Labels
Area: App Runtime Issues in `libmonodroid.so`.

Comments

@Cheesebaron
Copy link

Android framework version

net9.0-android

Affected platform version

.NET 9.0.100

Description

When I debug an application where csproj contains <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk> for the configuration I am running it appears like satellite assemblies for other languages than the neutral one are not deployed with the App.

This means that at runtime when switching languages using something like:

CultureInfo.DefaultThreadCurrentCulture = newCultureInfo;
CultureInfo.DefaultThreadCurrentUICulture = newCultureInfo;

Then grabbing strings from the Resx files we use, always yield the strings from the neutral language.

Looking at the output from the App at runtime you will see:

11-20 10:37:05.346 W/monodroid-assembly( 7723): open_from_bundles: failed to load bundled assembly de-DE/TrackMan.Api.Measures.resources.dll
11-20 10:37:05.346 W/monodroid-assembly( 7723): open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
11-20 10:37:05.346 W/monodroid-assembly( 7723): open_from_bundles: failed to load bundled assembly de-DE/TrackMan.Api.Measures.resources.dll
11-20 10:37:05.346 W/monodroid-assembly( 7723): open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
11-20 10:37:05.347 W/monodroid-assembly( 7723): open_from_bundles: failed to load bundled assembly de/TrackMan.Api.Measures.resources.dll
11-20 10:37:05.347 W/monodroid-assembly( 7723): open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
11-20 10:37:05.347 W/monodroid-assembly( 7723): open_from_bundles: failed to load bundled assembly de/TrackMan.Api.Measures.resources.dll
11-20 10:37:05.347 W/monodroid-assembly( 7723): open_from_bundles: the assembly might have been uploaded to the device with FastDev instead

Steps to Reproduce

Repro repository can be found here: https://github.com/Cheesebaron/EmbedAssembliesIntoApkRepro

Did you find any workaround?

Setting EmbedAssembliesIntoApk to false seems to alleviate this issue.

Relevant log output

@Cheesebaron Cheesebaron added Area: App Runtime Issues in `libmonodroid.so`. needs-triage Issues that need to be assigned. labels Nov 20, 2024
@dellis1972 dellis1972 added Area: App+Library Build Issues when building Library projects or Application projects. and removed Area: App Runtime Issues in `libmonodroid.so`. needs-triage Issues that need to be assigned. labels Nov 20, 2024
@dellis1972
Copy link
Contributor

So I managed to repo the issue with the sample provided.

Oddly lib/arm64-v8a/lib-de-DE-Shared.resources.dll.so and lib/x86_64/lib-de-DE-Shared.resources.dll.so are both present in the apk! So this means something else is going on.

@dellis1972 dellis1972 added Area: App Runtime Issues in `libmonodroid.so`. and removed Area: App+Library Build Issues when building Library projects or Application projects. labels Nov 20, 2024
@dellis1972
Copy link
Contributor

Relevant adb log output

11-20 11:09:11.240  7854  7854 W monodroid-assembly: open_from_bundles: failed to load bundled assembly de-DE/Shared.resources.dll
11-20 11:09:11.240  7854  7854 W monodroid-assembly: open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
11-20 11:09:11.240  7854  7854 W monodroid-assembly: open_from_bundles: failed to load bundled assembly de-DE/Shared.resources.dll
11-20 11:09:11.240  7854  7854 W monodroid-assembly: open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
11-20 11:09:11.292  7854  7854 W monodroid-assembly: open_from_bundles: failed to load bundled assembly de/Shared.resources.dll
11-20 11:09:11.292  7854  7854 W monodroid-assembly: open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
11-20 11:09:11.292  7854  7854 W monodroid-assembly: open_from_bundles: failed to load bundled assembly de/Shared.resources.dll
11-20 11:09:11.292  7854  7854 W monodroid-assembly: open_from_bundles: the assembly might have been uploaded to the device with FastDev instead
--------- beginning of kernel

grendello added a commit that referenced this issue Nov 20, 2024
Fixes: #9532
Context: 86260ed

All the assemblies are wrapped in a valid ELF shared library image and
placed in the `lib/{ABI}` directories inside the APK/AAB archive.  Since
those directories don't support subdirectories, we need to encode
satellite assembly culture in a way that doesn't use the `/` directory
separator char.  This encoding, as originally implemented, unfortunately
used the `-` character which made it ambiguous with culture names that
consist of two parts (e.g. `de-DE`), since the unmangling process would
look for the first occurrence of `-` to replace it with `/`, which would
form invalid assembly names such as `de/DE-MyAssembly.resources.dll`
instead of the correct `de-DE/MyAssembly.resources.dll`.  This would,
eventually, lead to a mismatch when looking for satellite assembly for
that specific culture.

Fix it by changing the `-` character to `_` so that mangled assembly
name looks like `lib_de-DE_MyAssembly.resources.dll.so` and we can
unambiguously decode it to the correct `de-DE/MyAssembly.resources.dll`
name.
@grendello grendello linked a pull request Nov 20, 2024 that will close this issue
@jpobst jpobst added this to the .NET 9 Servicing milestone Nov 20, 2024
grendello added a commit that referenced this issue Nov 21, 2024
Fixes: #9532
Context: 86260ed

All the assemblies are wrapped in a valid ELF shared library image and
placed in the `lib/{ABI}` directories inside the APK/AAB archive.  Since
those directories don't support subdirectories, we need to encode
satellite assembly culture in a way that doesn't use the `/` directory
separator char.  This encoding, as originally implemented, unfortunately
used the `-` character which made it ambiguous with culture names that
consist of two parts (e.g. `de-DE`), since the unmangling process would
look for the first occurrence of `-` to replace it with `/`, which would
form invalid assembly names such as `de/DE-MyAssembly.resources.dll`
instead of the correct `de-DE/MyAssembly.resources.dll`.  This would,
eventually, lead to a mismatch when looking for satellite assembly for
that specific culture.

Fix it by changing the `-` character to `_` so that mangled assembly
name looks like `lib_de-DE_MyAssembly.resources.dll.so` and we can
unambiguously decode it to the correct `de-DE/MyAssembly.resources.dll`
name.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: App Runtime Issues in `libmonodroid.so`.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants