Release 13 bugfixes - #301
Conversation
79d9e55 to
111312d
Compare
5e17f62 to
b468592
Compare
|
Will fix #304 in a separate PR |
|
|
||
| // Dropping parts took its sqlite_sequence row along, so parts._id restarts at 1. | ||
| // The notification images are named after those ids and outlive the database, so | ||
| // leaving them behind would serve one part's image as the image of whatever part | ||
| // next takes its id | ||
| for (final File image : NotificationImageProvider.listImageFiles()) { | ||
| image.delete(); | ||
| } |
There was a problem hiding this comment.
We should move this cleanup into createDatabase() instead. Messaging supplies a null database error handler, selecting Android's default handler, which attempts to delete the corrupted database: https://github.com/GrapheneOS/platform_frameworks_base/blob/01966176d7184cc5bccb4839876e661a9c03563b/core/java/android/database/DefaultDatabaseErrorHandler.java#L53-L104
If corruption is detected while opening, SQLiteDatabase invokes that handler and retries openInner(). Recovery path: https://github.com/GrapheneOS/platform_frameworks_base/blob/01966176d7184cc5bccb4839876e661a9c03563b/core/java/android/database/sqlite/SQLiteDatabase.java#L1166-L1182
If recreation succeeds, SQLiteOpenHelper sees database version zero and calls onCreate(). Version check: https://github.com/GrapheneOS/platform_frameworks_base/blob/01966176d7184cc5bccb4839876e661a9c03563b/core/java/android/database/sqlite/SQLiteOpenHelper.java#L413-L437).
Messaging’s onCreate() calls createDatabase() directly, bypassing this cleanup in rebuildTables(). Moving the loop covers that recovery path too, preventing surviving cached images from being reused for unrelated parts whose IDs match
| internal fun predictiveBackContentTransform( | ||
| @SwipeEdge swipeEdge: Int, | ||
| ): ContentTransform { | ||
| return EnterTransition.None togetherWith predictiveBackExit(swipeEdge = swipeEdge) | ||
| } |
There was a problem hiding this comment.
It's possible to see a sliding fade animation if the back gesture interrupts the opening animation, making the app appear to have two different back animations
backgesture2anims.mp4
There was a problem hiding this comment.
This comes from AnimatedContent retaining the previous screen’s cached forward-enter transition when predictive back interrupts an opening animation. NavDisplay doesn’t expose a way to replace that cached transition.
I added a workaround: while an entry is still becoming visible, back uses the ordinary pop without a predictive preview. Once settled, predictive shrink-and-push works normally. This removes the mixed slide/fade artifact, but the early-back behavior remains intentionally different. Is that acceptable?
Overlapping passes all saw the same "nothing posted yet" state and repeated each other's attachment decodes, which is what put the SMS_DELIVER broadcast over its deadline.
The file was named with a fresh random id per call, so every pass decoded and re-compressed every image again. Name it after parts._id, which is digits-only and never reused, and drop the cache whenever the database is created, since that restarts those ids.
Wait at most 8s for the import, then finish the broadcast. The import runs in the application scope either way, and the message commits before the notification pass that takes the time.
390f492 to
b978057
Compare
|
Will add few more fixes of the other bugs in this PR later. |
4 participants
Also closes #297, #295, #302, #303, #315, #318