[android] Migrate installation identifier to non-backed-up storage

[sjchmiela]

Why

#10261 (comment). Also fixes #11008 by making expo-notifications use the same installation ID as expo-constants and expoview (f1ecd07).

How

Found a (in my opinion) nicer way to store a string in a non-backed-up storage (than defining a <full-backup-content> XML file and requiring developers to implement their own BackupAgent in some circumstances, etc.) — using getNoBackupFilesDir to get a directory where we create a simple .txt file. The advantage it provides is not requiring developers to modify any native files to incorporate this feature.

I wrote a class that tries to migrate the UUID from SharedPreferences to noBackupFilesDir on getUUID call. It should handle invalid UUIDs well (by ignoring it). Then I copied it from expoview to expo-constants and expo-notifications in case there are bare projects that use one and not the other (we don't want to depend on migration in -constants in -notifications and vice versa). It follows the implementation outline of #10261 (comment) with the following modifications:

• instead of removing the SharedPreferences/keychain entry "so we recover from corrupt data" I decided to ignore it
• if we didn't read a valid ID and we wouldn't intend to create one if it wasn't present we don't immediately generate a new one. There are still parts of code that do not "get-or-create" the UUID, just "get". For them we need a sensible "just-get" implementation.
• instead of computing the v5 UUID from the Firebase Instance ID (as proposed by the main overview) I've decided to stick with a random v4 UUID since fetching the Firebase Instance ID starts some kind of connection with Firebase servers — it may also require Firebase app configured (but I haven't verified that) and even though installationId is mostly used in expo-notifications, we don't say anywhere that accessing expo-constants.installationId requires Firebase configured.
• instead of using SharedPreferences I decided to save the file in noBackupFilesDir which seems less breakable than using SharedPreferences and configuring full-backup-content.

Another option I was thinking of was to create a new unimodule expo-installations (expo-installation-id) just for this class and depend on the new unimodule in expoview, expo-constants and expo-notifications. Since we intend to deprecate and eventually remove .installationId creating a unimodule just for half a year and deprecating it immediately doesn't seem like the best idea.

Test Plan

I have verified that:

• Constants.installationId from running Expo client on master is the same as .installationId returned when running Expo client on this branch
• expo-notifications's installation ID from running Expo client on master is the same as installationId returned when running Expo client on this branch
• removing and reinstalling Expo client sets a different installationId
• modifying the file so that is does not contain a valid UUID discards its contents and persists a new UUID

Test approach #2

Test scenarios for installation identifiers:

• on an experience running on SDK39 when Expo client upgrades
  • SDK39 ConstantsBinding keeps using mExponentSharedPreferences.getOrCreateUUID. Unversioned ExponentSharedPreferences migrates UUID from unscoped SharedPreferences to unscoped non-backed-up storage. No change. ✅
  • SDK39 InstallationIdProvider keeps using scoped SharedPreferences. Migration isn't being added to versioned InstallationIdProviders, identifier keeps being backed-up but it doesn't change. ⚠️
• when an experience using SDK39 upgrades to SDK40 in Expo client
  • Both SDK39 and SDK40 ConstantsBindings use mExponentSharedPreferences.getOrCreateUUID which uses migrated non-backed-up storage. No change ✅
  • SDK39 InstallationIdProvider used scoped SharedPreferences, SDK40 ScopedInstallationIdProvider uses mExponentSharedPreferences.getOrCreateUUID if there is no existing ID (new project) or migrates legacy UUID from scoped SharedPreferences to scoped no-backup-dir if it exists and keeps using it in the future. All in all there's no change. ✅
• when standalone app using SDK39 upgrades to SDK40
  • Both SDK39 and SDK40 ConstantsBindings use mExponentSharedPreferences.getOrCreateUUID which uses migrated non-backed-up storage. No change ✅
  • SDK39 InstallationIdProvider had ID saved in scoped SharedPreferences, SDK40 InstallationIdProvider migrates that ID to scoped noBackupDir. No change ✅
• when an SDK39 project ejects to bare
  • SDK39 ConstantsBinding was using mExponentSharedPreferences.getOrCreateUUID which persisted ID in unscoped SharedPreferences. Upon ejection we start using ConstantsService with unscoped Context which results in using the same SharedPreferences. No change ✅
  • SDK39 InstallationIdProvider uses scoped SharedPreferences to persist installation ID. Upon ejection we start using unscoped SharedPreferences, ID changes to one equal to Constants.installationId. ⚠️ We can live with that.
• when an SDK40 project ejects to bare
  • SDK40 ConstantsBinding was using mExponentSharedPreferences which persisted ID in unscoped non-backed-up storage. ConstantsService uses the same storage location, ID doesn't change. ✅
  • SDK40 ScopedInstallationProvider was using either mExponentSharedPreferences which persisted ID in unscoped non-backed-up storage (in this case bare InstallationIdProvider uses unscoped common installation ID and there are no changes. ✅) or used ID migrated from scoped SharedPreferences to scoped noBackupDir in which case the ID changes, but we can live with that). ⚠️
• when a bare project upgrades expo-notifications or expo-constants
  • Previous installation ID providers used unscoped SharedPreferences. Upon upgrade, the ID gets migrated to the same location by either expo-notifications or expo-constants. ID stays the same. ✅

[github-actions]

Native Component List for this branch is ready

[ide]

Could you help comment / describe what code can be deleted when:

• we remove legacy Notifications?
• we remove Constants.installationId?

[sjchmiela]

What can we remove when:

• once we remove legacy Notifications — we will be able to remove ExponentNotificationIntentService (not mentioned in this PR), but I think we would still keep ExponentSharedPreferences and its migrator as it provides installation ID for scoped expo-constants and expo-notifications
• once we remove legacy Notifications and Constants.installationId — we would be able to remove ExponentSharedPreferences' getOrCreateUUID in favor of moving the unscoped UUID code "closer" to expo-notifications (as this would be the only remaining piece of code using it). ScopedInstallationIdProvider could be initialized with ScopedContext (it already is) and it could try to fetch installation ID from either scoped storage or from unscoped storage (as it already does

  expo/android/expoview/src/main/java/versioned/host/exp/exponent/modules/universal/notifications/ScopedInstallationIdProvider.java

  Lines 22 to 45 in 319d8f1

  	@Override
  	public void getInstallationIdAsync(Promise promise) {
  	// If there is an existing installation ID, so if:
  	// - we're in Expo client and running an experience
  	// which has previously been run on an older SDK
  	// (where it persisted an installation ID in
  	// the legacy storage) or
  	// - we're in a standalone app after update
  	// from SDK where installation ID has been
  	// persisted in legacy storage
  	// we let the migration do its job of moving
  	// expo-notifications-specific installation ID
  	// from scoped SharedPreferences to scoped noBackupDir
  	// and use it from now on.
  	String legacyUuid = mInstallationId.getUUID();
  	if (legacyUuid != null) {
  	promise.resolve(legacyUuid);
  	} else {
  	// Otherwise we can use the "common" installation ID
  	// that has the benefit of being used if the project
  	// is ejected to bare.
  	promise.resolve(mExponentSharedPreferences.getOrCreateUUID());
  	}
  	}

  ), but it wouldn't need ExponentSharedPreferences to do so.

[brentvatne]

@sjchmiela - i cherry-picked the ios companion to this into sdk-40, shall we land this and cherry-pick it there as well? cc @byCedric to time versioning android around this

[sjchmiela]

Thanks, sorry for not letting you know — I planned to cherry-pick both of the "companion pull request" at once once this got 100% approved as well. Thank you for taking care of that!

As one can see, I merged this and cherry-picked the commit to sdk-40. 🙂