| #
42300cfb |
| 19-Nov-2020 |
Stanisław Chmiela <[email protected]> |
[ios] Migrate installation identifier to non-backed-up storage (#11019)
# Why
- iOS companion for https://github.com/expo/expo/pull/11005.
- https://github.com/expo/expo/pull/11019/commits/1e22e
[ios] Migrate installation identifier to non-backed-up storage (#11019)
# Why
- iOS companion for https://github.com/expo/expo/pull/11005.
- https://github.com/expo/expo/pull/11019/commits/1e22e08195b1b4c49650f8243eeb89b5f938b9a5 fixes https://github.com/expo/expo/issues/11008#issuecomment-726370187 ensuring future versioned `EXInstallationIdProvider`s use the common installation ID
# How
Implemented https://github.com/expo/expo/pull/10261#issuecomment-725396140.
- As in https://github.com/expo/expo/pull/11005, the migration code is present in ~3~2 places:
- ~in `ExpoKit` for managed apps relying on legacy notifications~
- in `expo-constants` for bare workflow apps and for managed workflow apps (`EXKernel` now uses `expo-constants` directly to fetch installation ID)
- in `expo-notifications` for bare workflow apps that for some reason do not get UUID migrated by `expo-constants` (eg. because they do not have `expo-constants` installed or have installed in older version).
- To expose common, migrated `deviceInstallUUID` to versioned `expo-constants` code I've added a simple kernel service plugged into already versioned `EXConstantsBinding`s.
# Test Plan
I have verified (previously) 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 **does not** generate a different installationId (as we know keychain isn't removed!)
- if we fetch an invalid UUID from the Keychain, new UUID is generated
- I experienced an app freeze once on `__ulock_wait`, when waiting for return from `SecItemCopyMatching` which isn't a common issue and were only a few reports online of
# Test approach #2
Test scenarios for installation identifiers:
- **on an experience running on SDK39 when Expo client upgrades**
- SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey` which is now cleared by migration. Patched `EXConstantsService` uses `EXDeviceInstallUUIDManager` kernel service which provides it with the "common" ID, migrated from the `NSUserDefaults.EXDeviceInstallUUIDKey`, so the value doesn't change. ✅
- SDK39 `EXInstallationIdProvider` used `NSUserDefaults.ABI39_0_0EXDeviceInstallUUIDKey` which is not cleared by any migration. **Identifier keeps being backed-up** but it doesn't change. ⚠️
- **when an experience using SDK39 upgrades to SDK40 in Expo client**
- SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey` which got migrated to keychain. SDK40 `EXConstantsService` uses the same keychain entry as the migrator, so they're using the same value. ✅
- SDK39 `EXInstallationIdProvider` used `NSUserDefaults.ABI39_0_0EXDeviceInstallUUIDKey` while SDK40 uses common device UUID the sources are obviously different. Token changes. ❌ This is a bug introduced with `expo-notifications` Expo client integration, we can't do anything about it apart from fixing it in SDK40, IDs for old SDKs are already created and will be used in corresponding SDKs and if we didn't do anything about it in SDK40, the ID per experience would change nonetheless, so let's change it this time for the last time.
- when standalone app using SDK39 upgrades to SDK40
- Unversioned SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey` which gets migrated to keychain, unversioned SDK40 `EXConstantsService` uses the same keychain entry as common UUID, no changes. ✅
- Unversioned SDK39 `EXInstallationIdProvider` used `NSUserDefaults.EXDeviceInstallUUIDKey` which gets migrated to keychain, unversioned SDK40 `EXInstallationIdProvider` uses the same keychain entry as common UUID, no changes. ✅
- when an SDK39 project ejects to bare
- SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey`, the same which is used in bare, ✅
- SDK39 `EXInstallationIdProvider` used `NSUserDefaults.EXDeviceInstallUUIDKey` in standalone apps, but `NSUserDefaults.ABI39_0_0EXDeviceInstallUUIDKey` in Expo client. Token changes on developers' devices. ⚠️
- when an SDK40 project ejects to bare
- SDK40 `EXConstantsService` used `EXDeviceInstallUUIDKey` keychain entry, the same which is used in bare, ✅
- SDK40 `EXInstallationIdProvider` used `EXDeviceInstallUUIDKey` keychain entry, the same which is used in bare (`EXDeviceInstallUUIDKey`), ✅
- when a bare project upgrades `expo-notifications` or `expo-constants`
- both projects have migrators that move `EXDeviceInstallUUIDKey` value from `NSUserDefaults` to keychain, token doesn't change. ✅
show more ...
|