Apps can generate their own 128-bit or larger random value and use that as an + identifier for the app installation. Apps can create data in their app-specific + external storage directory by default without needing permission, and in the legacy + storage model before API 29 that data persists after the app is uninstalled, so it can + be used to store an ID that persists through the app being uninstalled and + reinstalled. However, external storage is under control of the user and the user can + delete this data at any time, including after uninstalling the app. In the modern + storage model, this data is automatically removed when the app is uninstalled. + GrapheneOS includes Seedvault as an OS backup service which must be explicitly + enabled, and it has the option to automatically restore app data when an app is + reinstalled, which would avoid wiping this kind of data so the app wouldn't lose track + of it being the same profile.
+ +The ANDROID_ID string is a 64-bit random number represented as a hex
+ encoded string, unique to each combination of profile and app signing key. The 64-bit
+ limitation means it isn't particularly useful due to the possibility of collisions.
+ It's tied to the lifetime of profiles and does not persist through profile deletion or
+ a factory reset. This is comparable to an app storing a 64-bit random value in the
+ app-specific external storage directory. In the future, GrapheneOS will likely change
+ this to be tied to the lifetime of app installations rather than profiles.
The advertising ID is a Google Play services feature not included in the baseline
+ Android API, so it isn't an API included in GrapheneOS. The advertising ID is unique
+ to each profile. It isn't unique to each app signing key like ANDROID_ID,
+ but that makes little difference since apps within the same profile can communicate
+ with each other with mutual consent. It's comparable to ANDROID_ID but
+ provides an 128-bit value so it provides a strong cryptographic guarantee against
+ collisions, although a device messing with apps could set it to the same value used in
+ another profile. The advertising ID is exposed via the Settings app and can be reset
+ to a new random value, unlike ANDROID_ID which remains the same for the
+ lifetime of the profile.
Apps do not have access to user data by default and cannot ever access the data of
+ other apps without those apps going out of the way to share it with them. If apps are
+ granted read access to user data like media or contacts, they could use it to identify
+ the profile. If apps are granted write access to user data, they could tag it to keep
+ track of the profile. Apps previously had little reason to do things like this because
+ they were able to persist data through an uninstall and reinstallation by default. The
+ modern storage model means they need to request access to user data to do this. The
+ existence of ANDROID_ID means they don't yet need to bother with that but
+ that will change on GrapheneOS and will likely change for baseline Android too.