Leebra android
login register

Trying to recover encrypted timeline data

22 days ago by joseki to c/android

save

share

report

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.

frongt 0 points 22 days ago

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/...

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.

save

path: 0 25928402, hotness: undefined, score: 0, children: 5
joseki 2 points 22 days ago

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.

save

path: 0 25928402 25929502, hotness: undefined, score: 2, children: 4
frongt 1 point 22 days ago

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.

save

path: 0 25928402 25929502 25931066, hotness: undefined, score: 1, children: 3
joseki 1 point 22 days ago

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

save

path: 0 25928402 25929502 25931066 25931540, hotness: undefined, score: 1, children: 2
frongt 0 points 22 days ago

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.

save

path: 0 25928402 25929502 25931066 25931540 25932603, hotness: undefined, score: 0, children: 1
android
android

@lemmy.world

login for more options
34845
2227
1879

DROID DOES

Welcome to the Android community on Lemmy. Here you can participate in amazing discussions and events relating to all things Android.

The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:

Rules

1. All posts must be relevant to Android devices/operating system.

2. Posts cannot be illegal or NSFW material.

3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.

4. Non-whitelisted bots will be banned.

5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.

6. Memes are not allowed to be posts, but are allowed in the comments.

7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.

8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.

Community Resources:

go to feed...