fix: updater::updater: Update failed

[yilugesanghua]

    updater::updater: Update failed: This app reports version 1.2.2+1116, 
    but the binary is different from the version 1.2.2+1116 that was submitted to Shorebird.

    Caused by:Update rejected: hash mismatch. Update was downloaded but contents did 
    not match the expected hash. This is most often caused by using the same version 
    number with a different app binary.Path:"/data/user/0/com.jd.hospital.weicai/code_cache
    /shorebird_updater/downloads/1.full",expected:a6ab3d160ae0221541a13c037e110c82f00d3b28e4f6806901c665a5bbaf06e4,
     got: 4689be8277b8bce5416472adb6f8a6175609ab5db0dbccca124174d55691ad2a

[yilugesanghua]

and my appId: eb2b8dcf-c32f-4391-8e34-cb94fd575ec8

[bryanoltman]

Can you share more information about the steps you've taken and what you're trying to do? The error message alone is not especially helpful here.

[bryanoltman]

What the error message is telling us: Shorebird downloaded a patch targeting version 1.2.2+1116, but the patch can't cleanly apply to the app on your device. We'll need more information (what commands you ran, what steps you took, etc.) to understand where things went wrong.

[yilugesanghua]

@bryanoltman i have one flutter module and native app

1. shorebird login ,in flutter module shorebird init, then run common shorebird release aar --flutter-version=3.13.9 --release-version 1.2.2+1116 .copy release fold to native app.
2. add maven url and api ("com.jd.dh.wc.jdf_jdh_wc_module:flutter_release:1.0") in native app lib module
3. edit flutter module and run common shorebird patch --platforms=aar --release-version=1.2.2+1116
4. install app and restart
5. 

[yilugesanghua]

and native app root build.gradle

 maven {  url '../jdf_jdh_wc_module/release'}
 maven {  url 'https://download.shorebird.dev/download.flutter.io'}

[bryanoltman]

It looks like your setup is correct (presuming ../jdf_jdh_wc_module/release exists and contains com/jd/dh/wc/jdf/..., which I think it has to, since you're seeing patch check requests). I would maybe try cleaning, deleting the aar release directory, and the module's build directory, and trying the steps again.

Unfortunately, this is really easy to do with aars. Usually, a hash mismatch comes from using the wrong build of the flutter module, most often the build that was produced by the patch command. The bug https://github.com/shorebirdtech/shorebird/issues/793 is tracking some work that would make this error much harder to hit.

[yilugesanghua]

What I am thinking now is that the error is either a problem with the local release package or a problem with the patch package. Firstly, I can eliminate the possibility of the local release package because I directly reference the product packaged by the command, not copied So the problem may occur in the downloaded patch package, but in the console, I can only see the patch serial number, but I cannot see patch related information, such as hash value. so, how should I check the hash of the patch and the hash of the base package to try to identify the problem

[bryanoltman]

It might be helpful to explain a bit more how patching works under the hood. Assuming a release exists, when you run the patch command:

1. Your app is compiled using flutter build. We record the hash of the compiled libapp.so (the file that contains your app's compiled Dart code).
2. We download the compiled release from our servers (this was created and uploaded when you ran shorebird release)
3. We create a binary diff of the patch and the release, so the patch file that is uploaded to our servers is just the bits of your app that have changed.
4. When the patch is applied, we're applying the diff to the libapp.so file in your release app. We call this "inflating" the diff.
5. We check that the "inflated" libapp.so that will be used for the patch has the same hash that we recorded in step 1. This is an integrity check that makes sure the diff could be cleanly applied and that the patch is bit-for-bit the same as what was built in step 1.

When you see a hash mismatch, that means that the patch file used a different release libapp.so than what is in the app. That is, the diff of the patch build's libapp.so against the release build's libapp.so was created using a different release libapp.so than what is on the device, and so the "inflated" libapp.so has a different hash than we expect, and we refuse to run it because it is almost certainly not a runnable file.

It looks like you've done everything correctly. The usual ways for the incorrect aar to end up in an Android app (some of these won't apply to you, but worth spelling them all out):

1. settings.gradle is pointing to a subdirectory of build instead of release. build contains the results of the last flutter build, which changes the next time you run a patch, release, or build command. I don't think this is the case for you, as it looks like you're pointing at the build directory.
2. A release has been deleted in the shorebird console and recreated, and the android app is running the old release build.
3. The contents of the release directory have been altered.

The steps I would try:

1. Create a new release version using shorebird release aar --release-version 1.2.3+4 (you can use whatever release version you'd like, this is just for debugging)
2. Update your app's build.gradle so that your app's version is 1.2.3+4.
3. Run in Android Studio. You should see logs that shorebird is checking for a patch for release 1.2.3+4 and that none are found
4. Run shorebird patch aar --release-version 1.2.3+4
5. On the emulator/device, not in Android Studio, kill and restart the app. logcat should show that shorebird is checking for patches to 1.2.3+4, find the patch you just created, and apply it.

If this works, I would start investigating the steps that were taken between running shorebird release and loading the aar onto the device/emulator, as whatever went wrong almost certainly happened there.

[yilugesanghua]

@bryanoltman
I'm sorry, it's probably my fault. I tried again as you suggested, but this time I didn't package it locally, but used remote packaging. I found no problem. I guess there may be a cache problem somewhere.

[bryanoltman]

@yilugesanghua Yeah, like I mentioned, it's unfortunately really easy to do this right now with aar/ios-framework targets. One of the many things we're working on :) It's not quite at the top of our list, but https://github.com/shorebirdtech/shorebird/issues/793 tracks the work that should make this go away.