pazos
commented
6 months ago Thank you for your triage, @projectgus!
Perhaps a fix would be to add an additional file in the app's storage directory that writes versionCode, versionName from the packageInfo, and maybe even os.arch, and check this in isNewBundle() as well?
I guess is enough to create a new file with the arch in the 7z and check between that and what's included in the APK, like we do now with version.txt.
Since the file doesn't exist actually on current installations handle it the same way we do for version (extract assets if version doesn't match or version doesn't exist).
I don't have a android-luajit-launcher development environment set up, but I'm happy to take a crack at this if it's potentially useful (unless someone else is keen.)
It would be very welcome, indeed.
I think some Koreader F-Droid users encountered this recently: https://github.com/koreader/koreader/issues/11399 (in particular comment https://github.com/koreader/koreader/issues/11399#issuecomment-1920314796).
If a device updates from (for example) an armv7eabi build of an android-luajit-launcher app to an armv8a build of the same app, built from the same git revision, then the asset management code doesn't detect a new bundle and doesn't know to re-extract the assets. This means the install will break if it contained any shared libraries, as they're now 32-bit in a 64-bit runtime.
Perhaps a fix would be to add an additional file in the app's storage directory that writes versionCode, versionName from the packageInfo, and maybe even
os.arch, and check this inisNewBundle()as well?I don't have a android-luajit-launcher development environment set up, but I'm happy to take a crack at this if it's potentially useful (unless someone else is keen.)