Bump to 4.3.4: Android flet debug stale-code fix (flet #6682)#235
Merged
Conversation
`flet debug android` kept running previously-unpacked, stale app code after a re-run. `prepareApp` copies the app payload out of the APK only when its cache key changes, and the key was `versionName+versionCode`. `flet debug` reinstalls the same-version APK on each iteration (`flutter run` does an update install that preserves app data, including the cache marker), so the key never changed and re-extraction was skipped. `getAppVersion` now appends `PackageManager.lastUpdateTime` to the key, which is bumped on every (re)install but stays stable across plain relaunches — so a debug reinstall re-extracts the new code while ordinary relaunches still hit the cache. `flet build apk` was unaffected.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Fixes flet-dev/flet#6682 — code edits not taking effect under
flet debug android.flet debug androidre-packages the app, rebuilds the APK, andflutter run -d <device>reinstalls it, so the new code is inside the freshly installed APK's assets. But on Android,prepareAppcopies the app payload out of the APK to a writable dir only when a cache key changes, and that key wasversionName+versionCode(e.g.1.0.0+1).flet debugnever bumps the version between iterations, andflutter rundoes an update install that preserves app data — including the.keycache marker and the previously-unpackedapp/dir. So the key never changed → re-extraction was skipped → the app kept running stale code.This is Android-only: iOS/desktop run the app straight from the read-only app bundle, which
flutter runfully replaces each reinstall.flet build apkwas unaffected (fresh/version-bumped install).Fix
getAppVersionnow appendsPackageManager.lastUpdateTimeto the returned version string. It's bumped on every (re)install but stays stable across plain relaunches — so aflet debugreinstall invalidates the extraction cache and unpacks the new code, while ordinary relaunches still hit the cache with no per-launch cost.AndroidPlugin.java— append+ lastUpdateTimeto thegetAppVersionresult.serious_python_android.dart— comment documenting why the cache key depends on that reinstall-sensitive value (the Dart side treats the string as opaque, so no logic change).Release
Bumps all six packages to 4.3.4. No python-build snapshot change — bundled Python (3.12.13 / 3.13.14 / 3.14.6) and
dart_bridge(1.5.0) are unchanged from 4.3.3. CHANGELOG: substantive entry inserious_python_android, cross-referenced summary inserious_python, alignment lines elsewhere.Verification
Not exercised on a device in this change. Suggested end-to-end check:
flet debug android→ confirm app shows → editmain.py→flet debug androidagain → confirm the edit now appears (previously it wouldn't).