Compress a patched DLL back to assemblies.blob

[timea-techgirl]

Android application type

Classic Xamarin.Android (MonoAndroid12.0, etc.)

Affected platform version

.NET 6.0

Description

Hello, I found tools to decompress and view the assemblies.blob file.
I can't seem to find a simple way to compress the DLLs back to assemblies.blob.

Steps to Reproduce

Unable to pack the DLLs back to assemblies.blob

Did you find any workaround?

https://stackoverflow.com/questions/72689284/compress-xamarin-android-apk-assemblies

Relevant log output

No response

[grendello]

@timea-techgirl Hi! Indeed, there's no utility to put an assembly back into a blob from the command line. While an interesting idea, I'm not sure about the general usefulness of it. Even if it were possible to put the assembly back in the blob, then one would have to put it back in the apk/aab which means the need to re-align and then re-sign the modified package, both of which require a few non-trivial steps. Regardless, I'm marking the issue as feature request and we'll see about implementation :)

Until then, if you absolutely need to modify an assembly after packaging and put it back, I'd suggest you turn off assembly blobs (by setting the MSBuild property AndroidUseAssemblyStore to False) which will allow you to replace the modified assembly in the apk/aab archive.

[jonpryor]

There are two separate requests here:

1. Provide an entry point in the build system to allow assemblies to be manipulated before they are added to the .apk. This could be used to support obfuscation, a'la New MSBuild packaging/linking changes breaks Public Obfuscation #5220, or any other assembly modification.
2. Provide tooling to support editing the assemblies*.blob files, allowing assemblies to be modified after the build, and then the .apk updated with the new assemblies*.blob1 files.

I consider (2) to be a "workaround" for the lack of (1). Is there another use case for (2)?

I think it would be better for us to support (1). (2) will be very brittle, and I'm not sure how it would interact with .aab files or other future packaging formats.

[lukewis]

I have an additional use case for (2).

We have a "core" android app that supports "extensions" to customize the behavior on a per-customer basis. We'd like to support a flow where we build (and test) the core app only once, but then crack open the apk and insert the extension dlls, then re-assemble the apk to create the customer-specific apk. These extension dlls are loaded dynamically by the core app based on the configuration.