This also moves key derivation via HKDF into the core.

We still support downloading in v1 format for some time.

We still support restoring in v1 format for some time.

while maintaining support for v0 and v1

while maintaining support for v0 and v1

We'll probably keep metadata around for internal information about backup state

as it isn't needed anymore with v2 since we don't do duplicate restore sets anymore

The token used to be very important, because it was our restore set folder name. Now it is just a number in a snapshot, so things get a bit simpler.

This class is responsible for caching blobs during a backup run,
so we can know that a blob for the given chunk ID already exists
and does not need to be uploaded again.

It builds up its cache from snapshots available on the backend
and from the persistent cache that includes blobs that could not be added to a snapshot,
because the backup was aborted.

which manages interactions with snapshots, such as loading, saving and removing them.
It also keeps a reference to the latestSnapshot that holds important re-usable data.

Historically, metadata was uploaded to the backend after each app update and contained all essential data that is now in snapshots. We still support reading metadata for legacy backups and use the metadata classes as a common wrapper for snapshots. However, there is no need anymore to write out complete historic metadata and maintain duplicated unused information there. This got removed. THe information we do still save and write out is only for UI representation of backup state.

The time of last backup is now managed by SettingsManager.

as they all relate to interacting with the backup repository

This happens regularly after each successful backup.

There is no easy way to re-initialize all data based on the old key, so to prevent usage of the old key we need to exit our process. When the app is started again, only the new key will be used.

The most common restore scenario is assumed to be moving from one device to another, like when the old one was lost or stolen. Most users probably don't continue to use the old device themselves still.
Since they just restored this backup on their phone, most data is already in this backup. Deduplication allows re-using that, so it doesn't need to be saved again.

we set a hard limit for 1 GiB per app for now, but leave code in to make it configurable in the future

Since this is for Android 15 and the new v2 format, this is a good time for upgrading, because we need to test the app extensively anyway.

All snapshots we wrote out should be cached locally. Auto-restore is holding up app installs, so we should be as fast as possible.

We don't get notified about the start nor the end of such a backup run, so we need hacks to do initialization and finalization.

Instead of showing 'Waiting to be backed up...'

otherwise all LoggingFactory ClassLoader lookups that cause disk reads are logged when koin initializes classes

Even though we use d2d, backup is only forced for user apps.

We need to account for IME insets when applying padding to the window.

Now, we don't do partial backups anymore. A snapshot is only done at the end and no information can make it to the backup before. Hence the old error notification with number of apps backed up didn't make sense anymore.

when user is asked to choose a backup to restore

When switching to new storage that doesn't yet have any snapshots, we would otherwise keep the old latest snapshot around.

* activity now can be launched from notification
* better logging
* app data restore continues even after activity died

The fake package manager package is essential for the backup, but when its data doesn't change and we request a normal incremental backup, it doesn't get included, because our transport doesn't even get called for it. Only the BackupMonitor gets a hint that it had no (new?) data via LOG_EVENT_ID_NO_DATA_TO_SEND.
This behavior started with Android 15 that fixed a bug that caused @pm@ to always backup. However, other K/V apps were probably affected before.

The system doesn't allow us to backup forced stopped apps, but if we had data for them once, we can at least carry it along.

This caused black squares around icons.

a sha256sum mismatch for example can happen, so the exception should get caught e.g. in RestoreCoordinatorState and should not necessarily be fatal

before a corrupted snapshot would DoS pruning

this can happens when it tells us that restore has finished overall