Silent discard of corrupted entries during Android Auto Backup restore

When an app relies on Android Auto Backup, the restore path offers no guarantee that every backed-up item was written correctly. The onRestoreCompleted callback in BackupManager reports only that the restore operation finished; it does not indicate whether individual files or database rows were corrupted or omitted. Because Auto Backup does not attach a checksum or hash to each backed-up file, and because the backup service may silently discard entries it detects as corrupt, an app can finish restoration with missing or damaged data and receive no error signal.

Current documentation does not describe a built-in integrity verification mechanism, and no public API lets an app compare restored data against the original backup. Custom BackupTransport implementations could add checksums or signatures, but that approach is deprecated in newer Android releases and is not part of the standard backup flow. Because behavior around silent discard and integrity checks is version sensitive and may vary across OS versions and OEM implementations, any assumptions should be treated as indicative and verified on target devices.

Given these constraints, what is the supported way to detect that restored data is incomplete or corrupted? Are there any documented callbacks or result codes that expose per-item restore failures? How should apps handle integrity verification when custom transports are deprecated?