feat(Android): find & delete corrupt asset backups

[fyfrey]

Many asset backups on Android are corrupt because the app did not have permission to access media file location (GPS EXIF data). This results in checksum being different after this permission is granted leading to sync issues.

This PR adds a method to find and delete such assets on the server. For my production instance, I've deleted 2750 corrupt backups :-)

How does the automatic detection of corrupted asset backups work:

1. Find assets that are according to checksum sync only on device
2. Find those assets by filename in the remote-only assets
3. Compare the matching pairs by various other metadata such as filesize, creation date
4. Do a byte-wise comparison (ignore the first few KBs of each file for header (EXIF) data)
5. Any assets that pass step 3+4 are deleted on the server after the user taps "Delete"

Below are the added UI parts:

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
immich	⬜️ Ignored (Inspect)			Jun 27, 2023 10:08am

[alextran1502]

Having this option on the backup page would confuse non-technical people. Is there a way we should have this resolved automatically?

[fyfrey]

Having this option on the backup page would confuse non-technical people. Is there a way we should have this resolved automatically?

I've automated it as far as I would go. It's still deleting assets so we can't without the user's consent.

Also, the process takes really long, uses lots of data and the app needs to stay open while doing so (just like the foreground backup).

If you got ideas how to make it more easily accessible while working within these constraints that we'd be good.

We could integrate it into the normal backup (run it after backup is done), not sure how to ask the user for consent to delete, though (especially when run in background).

[alextran1502]

I think we can change the scope for the PR to add in the requirement for location permission during run time. I think with that set. There shouldn't be any more issues in the future, correct?

[fyfrey]

I think we can change the scope for the PR to add in the requirement for location permission during run time. I think with that set. There shouldn't be any more issues in the future, correct?

The requirement for media location permission is already added in this PR. That should prevent such issues in the future.

[alextran1502]

I think we can change the scope for the PR to add in the requirement for location permission during run time. I think with that set. There shouldn't be any more issues in the future, correct?

The requirement for media location permission is already added in this PR. That should prevent such issues in the future.

Then I would like to cherry-pick that in this PR and exclude the process of handling corrupted files since it won't be relevant for new users - or when the app is in stable release mode 😄

[fyfrey]

Then I would like to cherry-pick that in this PR and exclude the process of handling corrupted files since it won't be relevant for new users - or when the app is in stable release mode smile

Alright, I'll do another PR with only those changes.

[fyfrey]

made #2965 with the permission checks

[fyfrey]

@alextran1502: rebased the PR. The functionality is now hidden behind the advanced troubleshooting setting