Always use assembly stores when assemblies are to be embedded #9410
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
grendello
force-pushed
the
dev/grendel/stop-packaging-individual-assemblies
branch
3 times, most recently
from
69a8829
to
68bd71a
Compare
grendello
force-pushed
the
dev/grendel/stop-packaging-individual-assemblies
branch
2 times, most recently
from
da5da68
to
1dbe4ff
Compare
All the non-fastdev builds will use assembly stores unconditionally now.
grendello
force-pushed
the
dev/grendel/stop-packaging-individual-assemblies
branch
from
1dbe4ff
to
b6cf84c
Compare
jonpryor
pushed a commit
that referenced
this pull request
Nov 22, 2024
Fixes: #9532 Context: #9410 Context: 86260ed Context: c927026 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`: * Assembly Stores (c927026), which is a "single" (-ish) file that contains multiple assemblies, enabled by setting `$(AndroidUseAssemblyStore)`=true. This is the default behavior for Release configuration builds. * One file per assembly (86260ed). This is the default behavior for Debug configuration builds when `$(EmbedAssembliesIntoApk)`=true. Aside: #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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All the non-fastdev builds will use assembly stores unconditionally now.