Fix unmangling of satellite assembly names by grendello · Pull Request #9533 · dotnet/android (original) (raw)

Fixes: https://github.com/dotnet/android/issues/9532

Context: https://github.com/dotnet/android/pull/9410 Context: 86260ed36dfe1a90c8ed6a2bb1cd0607d637f403 Context: c92702619f5fabcff0ed88e09160baf9edd70f41

In Debug configuration builds, $(EmbedAssembliesIntoApk)=false by default. This enables Fast Deployment in commercial/non-OSS builds.

When $(EmbedAssembliesIntoApk)=true, there are two separate ways to embed assemblies into the .apk:

Aside: dotnet/android#9410 is an attempt to remove support for the "one file per assembly" packaging strategy, which will not be applied to release/9.0.1xx.

When using the "one file per assembly" strategy, 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 encoding for / from - to _, so that the 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.