Conversation
| <cloud-backup disableIfNoEncryptionCapabilities="true" /> | ||
| <device-transfer/> | ||
| <cloud-backup disableIfNoEncryptionCapabilities="true"> | ||
| <exclude | ||
| domain="database" | ||
| path="bugle_db" /> | ||
| </cloud-backup> | ||
| <device-transfer> | ||
| <exclude | ||
| domain="database" | ||
| path="bugle_db" /> | ||
| </device-transfer> |
There was a problem hiding this comment.
There are likely other places that use bugle_db specific IDs that are being backed up
e.g. https://github.com/GrapheneOS/Messaging/blob/main/src/com/android/messaging/widget/WidgetConversationPrefs.kt uses the conversations._id autoincrementing key as a string in bugle_widgets.xml shared preferences, so if bugle_db is no longer backed up, the internal autoincrement id wouldn't make sense on new installs
Notification channels in https://github.com/GrapheneOS/Messaging/blob/main/src/com/android/messaging/util/NotificationChannelUtil.kt also use the internal autoincrement id, and Android backs up those notification settings + channels separately from the app backup (https://github.com/GrapheneOS/platform_frameworks_base/blob/17/services/core/java/com/android/server/notification/PreferencesHelper.java#L830)
bugle_dbties each conversation to an SMS thread ID from the phone's SMS database. When SMS are restored, that database gives the threads new IDs, and this causes wrong thread/contact linking.