feat: Add a single AAR to multiple android apps

[julioamadortejeda]

Description

I'm working on an AAR module that can be used in multiple Android applications (all different). My idea is to create a release of my AAR that is embedded within the android apps but, if I patch my AAR, that patch will work in all the android apps where my AAR is. My problem is that every android app has a VersionName and VersionCode are different from each other, so when I want to install the patch I get the error "updater::c_api: Error downloading update: Invalid state: Hash mismatch. This is most often caused by using the same version number with a different app binary ". I understand the error but I need the patch to be able to be applied regardless of whether the binary or the hashes are different since I am not the owner of the android apps and I cannot create a release for each app.

Requirements

I would like to know if there is a way to create an AAR release without it being tied to a versionname + versioncode?

Additional Context

[felangel]

Hi @julioamadortejeda 👋 Thanks for opening an issue!

I don't think we want to disable the hash check because it would likely lead to patches that are incompatible and result in corrupt subsequent boot-ups.

My problem is that every android app has a VersionName and VersionCode are different from each other, so when I want to install the patch I get the error "updater::c_api: Error downloading update: Invalid state: Hash mismatch. This is most often caused by using the same version number with a different app binary ".

Would it be possible for you to generate a patch for each release that you'd like to patch? This will ensure that the changes in the patch apply cleanly to the underlying app release.

[bryanoltman]

Would it be possible to use flavors to target the different apps? I would need to know more about how you're distributing the AAR to the folks who develop/release the Android app that uses the AAR, but flavors should allow Shorebird to recognize each separate Android app the AAR is embedded in as a separate app.

[bryanoltman]

To address this question specifically:

I would like to know if there is a way to create an AAR release without it being tied to a versionname + versioncode?

Not currently. Version name+code is how Shorebird identifies the version of the app.

[julioamadortejeda]

Hi @julioamadortejeda 👋 Thanks for opening an issue!

I don't think we want to disable the hash check because it would likely lead to patches that are incompatible and result in corrupt subsequent boot-ups.

My problem is that every android app has a VersionName and VersionCode are different from each other, so when I want to install the patch I get the error "updater::c_api: Error downloading update: Invalid state: Hash mismatch. This is most often caused by using the same version number with a different app binary ".

Would it be possible for you to generate a patch for each release that you'd like to patch? This will ensure that the changes in the patch apply cleanly to the underlying app release.

Hello, I think that doing that is not possible either. since i did the following test: create a release for a code version of an android app (say 1.0+5) then create another app with a code version 1.0+8 with the binary that was generated for the first app. The result was that the second app did not detect the new patches and the first app did. I recompiled the first app increasing its code version to 1.0+6 and after that the app stopped detecting the patches. Finally, I created a release of my Flutter app with the version-release of the first app 1.0+6 but without including the new binary in any app (leave the old binary so as not to recompile) the result was that the first app detected the new patches but they cannot be installed since the error appears "updater::c_api: Error downloading update: Invalid state: Hash mismatch. This is most often caused by using the same version number with a different app binary" and the second app continued without detecting patches

[julioamadortejeda]

Would it be possible to use flavors to target the different apps? I would need to know more about how you're distributing the AAR to the folks who develop/release the Android app that uses the AAR, but flavors should allow Shorebird to recognize each separate Android app the AAR is embedded in as a separate app.

Hi @bryanoltman @felangel I would send you the AAR only once and that any future changes can be updated in your android app without relying on sending you a new AAR. This is because android app owners would be forced to ask me for a new AAR even if their app contains changes that have nothing to do with my AAR

[eseidel]

Related to https://github.com/shorebirdtech/shorebird/issues/828

[eseidel]

I think this has to wait until after we've done asset support as that will change our definition of our "base" that we're patching. https://github.com/shorebirdtech/shorebird/issues/318

We want to do something here, but need to learn more about the problem first.

[julioamadortejeda]

I think this has to wait until after we've done asset support as that will change our definition of our "base" that we're patching. #318

We want to do something here, but need to learn more about the problem first.

I understand and thank you very much for considering my request. I will be very attentive Thanks a lot

[mlb5000]

@eseidel I believe our use case will also have this problem, as Framework-embeds get their "version number" from the host app, and not from the build process. It would be amazing if you could update the "whoami" process within Shorebird to support something like an "embedded baseline".

Then we could define the version number when calling shorebird release [aar|ios-framework], and have subsequent patch application derive its baseline from that version number rather than the host app.

[eseidel]

@eseidel I believe our use case will also have this problem, as Framework-embeds get their "version number" from the host app, and not from the build process. It would be amazing if you could update the "whoami" process within Shorebird to support something like an "embedded baseline".

Then we could define the version number when calling shorebird release [aar|ios-framework], and have subsequent patch application derive its baseline from that version number rather than the host app.

Thanks. Yeah, @bryanoltman has a plan I believe, we're just rather busy getting improved iOS support out the door at the moment, so it may be a few months before we look at this more. We have had a lot of interest from "white label" applications and libraries, some of which use AAR as a way to share code between apps and would like something like this.

[julioamadortejeda]

Hi shorebird team,

Do you have any news about this issue? It's about not having the patch number linked to an embedded type application

[bryanoltman]

@julioamadortejeda No progress yet. We've been very busy the past few months getting iOS 1.0 out, but should have time for this soon. Doing this will represent a very large change in how we identify releases, so I think it will be some time before we have a solution ready to go. Will post updates here.

[eseidel]

We were discussing this today. One question we had, is can aars have external dependencies?

e.g. if you use Flutter in an aar, and from within that Flutter aar, you depend on package:crashlytics, which has a "native" firebase dependency (presumably on a firebase.aar?) Is that firebase dependency self-contained within the .aar or can it come from somewhere else in the apk?

I ask this because one of the things Shorebird tries to validate when making a patch is that the native dependencies didn't change in the patch artifact. This is done because we will not (cannot) patch native code changes, so it is possible to end up sending down a dart-only change with Shorebird that could break your app if that dart-only change expects to work with a different native side. We currently validate to prevent this from happening in the whole-app (e.g. apk, ipa, aab) case, but presumably can't do that in the aar case.

If aars end up with externalized native dependencies, how are those versions maintained? e.g. if one subteam in a company is making the flutter aar for inclusion with a larger apk, that depends on crashlytics, how does that team manage a (shared) crashlytics dependency with the reset of the Android app team?