TIL ANDROID_ID and who comes up with this malicious shit? does GrapheneOS do anything reasonable to fix it?
Conversation
Replying to
On Android 8+, it's based on a secret generated for each profile and made into an app-specific value based on app signing key. Apps can implement their own ANDROID_ID via app-specific external storage directory unless scoped storage is being used which clears that on uninstall.
2
We cover these things in grapheneos.org/faq#hardware-i and grapheneos.org/faq#non-hardwa.
We've planned to change how it works for a while so that it's instead a per-app id tied to the app install and will be different on reinstall. Not much benefit with low scoped storage adoption though.
Replying to
How would storage persist across uninstall? If it's in shared storage at least it's visible and subject to manual deletion, no?
1
Replying to
You could manually delete the app-specific directory from external (shared) storage. Apps can access their own directory in Android/ without a permission. With scoped storage, this gets cleared on uninstall, so they can't persist data without asking you to choose a place for it.
1
Show replies
Android 10 was originally supposed to introduce scoped storage for everything via emulation. However, there was massive backlash and they limited it to API 29 with an opt-out available. API 30 makes it mandatory with an exception for upgrading existing apps using legacy storage.