| Post Reply | RetroFed Forums Forum Index » Android |
| Author | Message | ||
|---|---|---|---|
|
joseki lemmy.zip joseki@lemmy.zip Joined: 2026-09-12 |
I’m trying to recover many years of Google Maps Timeline history and have gotten far enough into the problem that I’m hoping someone familiar with Android Keystore, Google Play Services/Folsom security domains, or Maps Timeline’s encrypted-backup implementation might recognize what is happening. The short version is: Google confirms that encrypted Timeline backups for my account still exist on its servers, but every device I try says “Your encrypted data isn’t unlocked yet.” On the S23 that was probably involved in the Timeline migration, an Android bugreport shows Google Play Services actually attempting key recovery and failing with: LocationHistory: [BackupRunner] Failed to get encryption key for backup LocationHistory: bmas: 38502: Domain is not retrievable The recovery flow also invokes: com.google.android.gms.auth.folsom.StartKeyRetrieval and references: on_device_location_history How I think I got here I have used Google Maps Timeline/Location History for many years. For most of that time my primary Google account on Android devices was one account, while the account I actually used inside Google Maps for Timeline was a different secondary Google account. That worked normally for years. My main phone during the transition from Google's old server-based Timeline system to the newer device-local/encrypted-backup system was a Samsung Galaxy S23 Ultra, SM-S918U1. At some point I had to repair/reflash the S23 firmware. I believe I used firmware that was compatible with the hardware but may not initially have been the exact correct region/CSC variant. The phone continued working afterward. I cannot prove that this caused the Timeline problem. It is simply the most suspicious event in the history because Android Keystore/device trust material may have changed during that process. Later I noticed that older Timeline history was gone from the normal Maps UI. What Google Takeout shows I requested a Google Takeout specifically for Timeline. The plaintext Timeline export only contains relatively recent device-local history. However, Takeout also produced an Encrypted Backups file that explicitly states that I have encrypted Timeline backups stored on Google servers. So as far as I can determine: Old Timeline data
encrypted backup still exists at Google
decryption/recovery state is unavailable
Maps cannot restore it Importantly, the Takeout file is not the encrypted backup itself. It just confirms that encrypted backups exist. What Maps does On the S23, my new Galaxy Fold, and several old Android devices, Maps shows: Your encrypted data isn’t unlocked yet If I tap the Timeline cloud/backup icon: A spinner appears. It waits for a while. The spinner disappears. No backup list appears. I never receive a PIN/password/key-recovery prompt. I never get a usable “Fix now” flow. I have tested: Galaxy S23 Ultra Galaxy Z Fold8 Ultra Galaxy Note8 Galaxy Tab A The older devices were preserved and had not necessarily been wiped, but signing the Timeline Google account into them does not change the behavior. This suggests that simply having an old device is not enough. The specific device-side recovery/security-domain state apparently matters. What I found on the S23 I kept the S23 intact after moving to the Fold and captured an Android bugreport while reproducing the Timeline failure. The critical log entries are: LocationHistory: [BackupRunner] Failed to get encryption key for backup LocationHistory: bmas: 38502: Domain is not retrievable The bugreport also shows the Google Play Services key-recovery path actually launching: com.google.android.gms.auth.folsom.StartKeyRetrieval The recovery request is associated with the correct Google account and: on_device_location_history There are also Google Play Services/Keystore references such as: com.google.android.gms.auth.folsom com.google.android.gms.backup/folsom security_domain_member_key security_domain_member_key_encrypted_locally and activity involving operations with names along the lines of: ListSecurityDomainMembersOperation GetKeyMaterialOperation MarkLocalKeysAsStaleOperation INVALIDATE_LOCAL_KEYS I am not interpreting those names as proof that Google deleted the keys. They are simply what appears in the recovery sequence. Current S23 state The phone currently reports: Model: SM-S918U1 Android: 16 Bootloader: locked Verified Boot: green Warranty bit: 0 Security patch: 2026-08-05 Sales code: XAA So there is no obvious current unlocked-bootloader/failed-Verified-Boot situation. The Keystore is also clearly functioning in general. Google Play Services can create/use hardware-backed operations. The unresolved question is whether the specific historical Timeline/security-domain key material is gone, stale, inaccessible, or simply failing to be retrieved from Google's recovery infrastructure. Things I have deliberately NOT done I have not: deleted the encrypted Timeline backups selected Google's “delete encrypted data and start over” option factory-reset the S23 during this investigation cleared Google Play Services storage cleared Maps storage unlocked the bootloader removed the affected Google account reflashed the phone again I want to preserve every remaining recovery possibility. Things I've already tried Tested the original/current S23 Tested a new Fold Tested old Note8 and Tab A devices Verified the correct Google account is being used Verified normal Google authentication works Confirmed the encrypted backups exist via Takeout Captured ADB/logcat/Android bugreport during failure Submitted the exact error through Google Maps feedback Posted to the official Google Maps support community The normal Google support documentation basically says to recover encrypted Timeline data using the original device, or delete the encrypted backup and start over if recovery is impossible. The problem is that I still have the likely original device, and its recovery process is actively running but failing internally. What I'm trying to figure out Does anyone recognize: 38502: Domain is not retrievable from Google Play Services, Folsom, security-domain recovery, Android backup encryption, or Maps Timeline? In particular, I’m trying to determine whether this means: The historical device-bound encryption key was permanently lost during the earlier firmware event. The local Google security-domain membership/key wrapping state is damaged but potentially repairable. Google still has enough recovery metadata server-side, but the security domain is in a broken/stale state. This is a Google Play Services/Maps bug rather than true key loss. There is some supported or unsupported way to re-enroll the device into the existing security domain without deleting the encrypted backups. I am comfortable with ADB, Android debugging, Linux, Docker, firmware tooling, and doing forensic-style diagnostics on the S23 now that it is no longer my daily phone. I am not looking to bypass someone else's encryption or account security. These are my own Google account, phone, and Timeline backups. I’m mainly trying to avoid destroying the one server-side copy that apparently still exists. If anyone has dealt with Google Play Services auth.folsom, Android security domains, or Timeline's newer end-to-end encrypted backup implementation, I would especially appreciate pointers about what 38502 / Domain is not retrievable actually signifies and what additional state I should preserve before experimenting further. |
||
| 18 Original | |||
|
frongt lemmy.zip frongt@lemmy.zip Joined: 2025-07-31 |
Does the S23 have a full copy of the data? If it does, you can probably do an export on the device https://dawarich.app/docs/getting-started/import-existing-data/ If it doesn't, it might be that the server-side backup is corrupt. Or maybe just the backup/restore process is broken; I've had that happen and I just had to try again a few weeks later. |
||
| 2 | |||
|
joseki lemmy.zip joseki@lemmy.zip Joined: 2026-09-12 |
Does the S23 have a full copy of the data? If it does, you can probably do an export on the device https://dawarich.app/docs/getting-started/import-existing-data/ If it doesn't, it might be that the server-side backup is corrupt. Or maybe just the backup/restore process is broken; I've had that happen and I just had to try again a few weeks later.
Unfortunately I only get the encrypted txt manifest not the data itself from takeout - the phone was flashed trying to fix a problem with the file picker and that's what started this problem, I can't export the data using takeout and the phone image doesn't match the cryptographic hash - I just need to log into maps using a phone that is recognized as the originator of the data at the time the new encryption method rolled out. I have the phone but it was flashed so it's not recognized as the device that has permission to decrypt my location history. Very frustrating. |
||
| 2 | |||
|
frongt lemmy.zip frongt@lemmy.zip Joined: 2025-07-31 |
Unfortunately I only get the encrypted txt manifest not the data itself from takeout - the phone was flashed trying to fix a problem with the file picker and that's what started this problem, I can't export the data using takeout and the phone image doesn't match the cryptographic hash - I just need to log into maps using a phone that is recognized as the originator of the data at the time the ...
Hmm. If you don't have a local copy, and the encrypted copy is corrupt, you might be SOL. I doubt Google is going to provide any support. |
||
| 1 | |||
|
joseki lemmy.zip joseki@lemmy.zip Joined: 2026-09-12 |
Hmm. If you don't have a local copy, and the encrypted copy is corrupt, you might be SOL. I doubt Google is going to provide any support.
There's no encrypted copy, just a manifest showing the encrypted copy is on Google's servers, but the device that has the hash to decrypt it was flashed...I'm tantalizingly close |
||
| 1 | |||
|
frongt lemmy.zip frongt@lemmy.zip Joined: 2025-07-31 |
There's no encrypted copy, just a manifest showing the encrypted copy is on Google's servers, but the device that has the hash to decrypt it was flashed...I'm tantalizingly close
If that key is gone, the encrypted data is as good as random garbage data. I suppose if you had a copy of the encrypted data and a decryptor, you could try to brute force it. |
||
| 0 | |||
|
joseki lemmy.zip joseki@lemmy.zip Joined: 2026-09-12 |
If that key is gone, the encrypted data is as good as random garbage data. I suppose if you had a copy of the encrypted data and a decryptor, you could try to brute force it.
From the data I pulled from ADB though it's not clear that the hash is actually gone that's what I'm trying to figure out |
||
| 1 | |||
| Post Reply |
Back to top |