Changes in EXKernelServiceRegistry.m

489c2041 - [ios] Remove legacy notifications module code (#24325)

Fri, 15 Sep 2023 23:18:39 +0000

[ios] Remove legacy notifications module code (#24325) List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

75d03742 - [iOS][Expo Go] Remove legacy screen orientation code (#14649)

Thu, 07 Oct 2021 14:41:40 +0000

[iOS][Expo Go] Remove legacy screen orientation code (#14649) List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

ea3f1d02 - [ios] Merge unimodules core and adapter into expo-modules-core (#13353)

Thu, 24 Jun 2021 10:23:51 +0000

[ios] Merge unimodules core and adapter into expo-modules-core (#13353)# Why Part of Expo modules re-architecture # How - Copied iOS sources from `@unimodules/core` and `@unimodules/react-native-adapter` to `expo-modules-core` - In these copied files replaced `UM` prefix with `EX` - Swift names for classes used by the users (`AppDelegateWrapper`, `ModuleRegistry`, `ModuleRegistryAdapter`, `ModuleRegistryProvider`) won't have any prefix — we would drop these prefixes anyway, in the future when we rewrite them to Swift - Old `UM*` names are still supported and most of them are marked as deprecated, however I couldn't get it to work for Swift (but seems like no one uses it for app delegates?) and protocols - `ExpoModulesCore` provides `EXUnimodulesCompat.h` header that expands old `UM_*` macros to `EX_*` - Previously `ExpoModulesCore` depended upon `UMCore`, now it's the other way around — `UMReactNativeAdapter` and `UMCore` depend on `ExpoModulesCore` to import `EXUnimodulesCompat` header - Fixed `EXTrackingTransparency` to depend on `ExpoModulesCore` directly - _There are no changes in the logic or architecture of unimodules/expo modules, I'll do this separately_ # Test Plan - CI jobs are passing - Tested locally, apps seem to work as before List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

a9a91078 - Revert "[ios] Remove legacy ScreenOrientation code (#11371)" (#12217)

Mon, 15 Mar 2021 17:42:36 +0000

Revert "[ios] Remove legacy ScreenOrientation code (#11371)" (#12217)This reverts commit 454e16d504aee225b3bdc8ee3fedbbdc051c7209. # Why After #11371, `lockAsync` is broken in iOS Expo Go; it causes the current orientation to change but does **not** persist the lock, which causes various issues. Additionally, the app.json `orientation` setting has no effect either. Essentially, all apps are permanently locked to `DEFAULT` orientation. # Test Plan - [x] NCL tests pass - [x] test-suite tests pass - [x] app.json `orientation` setting has an effect List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

454e16d5 - [ios] Remove legacy ScreenOrientation code (#11371)

Wed, 16 Dec 2020 15:42:20 +0000

[ios] Remove legacy ScreenOrientation code (#11371) List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

42300cfb - [ios] Migrate installation identifier to non-backed-up storage (#11019)

Thu, 19 Nov 2020 12:52:49 +0000

[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. ✅ List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

40b2cdcb - [android][ios] add full infrastructure and implementation for UpdatesBinding (#9694)

Fri, 14 Aug 2020 03:26:12 +0000

[android][ios] add full infrastructure and implementation for UpdatesBinding (#9694)# Why This PR adds the complete infrastructure for allowing the new expo-updates exported JS module to work as a scoped module in the managed workflow codebase and communicate with the `Kernel` classes. # How For iOS, I followed the pattern that was used in other scoped modules like Sensors. EXUpdatesBinding is a scoped module that is given access to a pair of kernel services, each of which have access to the AppLoader (and therefore expo-updates state) through the EXKernelAppRecord. All of the properties are just threaded through. For Android, there were fewer steps to thread through but we weren't keeping a reference to the AppLoader anywhere. I added a simple map in the Kernel for this, which the scoped UpdatesBinding has access to through the KernelProvider. Finally, since the `Updates.expo.ts` polyfill is no longer needed for the unversioned managed workflow, I removed this code from expo-updates. # Test Plan Backport these changes to SDK 38 and add a versioned SDK 38 copy of the expo-updates module, and switch EXKernelAppRecord/Kernel to use the new ExpoUpdatesAppLoader so expo-updates is used. I launched a test published app created by installing expo-updates and then manually deleting the `build/Updates.expo.*` files from node_modules. All the exported functions from expo-updates worked and assets were resolved to the copies on disk downloaded by expo-updates �� List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

70103ccd - [android][ios] add support for development loads in expo-updates AppLoader (#9599)

Wed, 12 Aug 2020 03:36:48 +0000

[android][ios] add support for development loads in expo-updates AppLoader (#9599)# Why Follow up to #9461 and #9523 . The development client's `AppLoader` classes are used to load manifests for both development and production bundles, but expo-updates is not intended to be used to load projects in development. We need to bypass expo-updates' caching and database layers for development mode loads. # How Unfortunately we cannot reliably determine before loading a manifest whether it is for a development or production mode project. Instead, I've added/expanded upon the ability of the calling class to abort a `LoaderTask` upon its cached/remote manifest callback being fired. Now, the new ExpoUpdatesAppLoader classes will check for development mode at 3 separate stages -- 1) before starting the load, if the URL is clearly indicative of a project in development, 2) when the cached manifest is returned, and 3) when the remote manifest is loaded. If it determines at any of these three stages that it's trying to load a development mode project, it will abort the `LoaderTask` early and delegate to RN to load the development bundle, similar to how the current, non-expo-updates AppLoader classes in both clients work. # Test Plan Manual tests of loading a development mode project on both platforms, after enabling the ExpoUpdatesAppLoader class in Kernel.java/EXKernelAppRecord.m. Also ensured that loading production experiences did not break. List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

8e23f9f5 - [ios][android] Drop SDK 31 and 32 (#5381)

Tue, 20 Aug 2019 13:50:09 +0000

[ios][android] Drop SDK 31 and 32 (#5381)# Why resolves: https://github.com/expo/expo/issues/5146 # How Using `et rm-sdk` expotools command. # Test Plan Run NCL. List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

b6008592 - [expo-branch] First 3rd party library unimodule wrapper! (#5165)

Tue, 06 Aug 2019 13:17:13 +0000

[expo-branch] First 3rd party library unimodule wrapper! (#5165)We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.com/expo/expo/issues/5132.I added support for React Native-specific unimodules to React Native adapter. Right now it works like this:- unimodule `expo-branch` depends on `react-native`, so it can use its API. It's no longer a uni-platform module, more an optinmodule (I guess the name won't stick)- we copy `react-native-branch` vendored module directly to the unimodule. It will compile, since we added necessary dependencies to the unimodule- `BranchPackage < org.unimodules.Package` implements `ReactPackage` interface too, forwarding all the calls to the vendored `RNBranchPackage`.- when the module registry provider creates a module registry from a list of `Packages`, it can filter out `ReactPackages` — and so it does, putting them into a local internal module (`ReactPackagesProvider`) which only purpose is to carry those to `ModuleRegistryAdapter` which is responsible for creating a list of React Native modules out of a module registry. The adapter grabs the `ReactPackagesProvider` and adds React Native modules to the list.I have confirmed that adding `BranchPackage` to a list of installed unimodules' packages creates `RNBranchModule` and exports to JS. List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

636b55ab - [expo-branch] First 3rd party library unimodule wrapper! (#5165)

Tue, 06 Aug 2019 13:17:13 +0000

[expo-branch] First 3rd party library unimodule wrapper! (#5165)# Why We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.com/expo/expo/issues/5132. # How I added support for React Native-specific unimodules to React Native adapter. Right now it works like this: - unimodule `expo-branch` depends on `react-native`, so it can use its API. It's no longer a uni-platform module, more an optinmodule (I guess the name won't stick) - we copy `react-native-branch` vendored module directly to the unimodule. It will compile, since we added necessary dependencies to the unimodule - `BranchPackage < org.unimodules.Package` implements `ReactPackage` interface too, forwarding all the calls to the vendored `RNBranchPackage`. - when the module registry provider creates a module registry from a list of `Packages`, it can filter out `ReactPackages` — and so it does, putting them into a local internal module (`ReactPackagesProvider`) which only purpose is to carry those to `ModuleRegistryAdapter` which is responsible for creating a list of React Native modules out of a module registry. The adapter grabs the `ReactPackagesProvider` and adds React Native modules to the list. # Test Plan I have confirmed that adding `BranchPackage` to a list of installed unimodules' packages creates `RNBranchModule` and exports to JS. List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

8d441c7e - [packages] Move unimodules foundation to `org.unimodules` scope

Thu, 14 Mar 2019 12:11:47 +0000

[packages] Move unimodules foundation to `org.unimodules` scope List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

f10e66fc - [expo-av] Expo Audio Video universal module (#3187)

Fri, 18 Jan 2019 10:53:02 +0000

[expo-av] Expo Audio Video universal module (#3187)# Why Expo is moving towards a more modular structure. # How - generated `expo-av` from a universal module template - moved code over - replaced all React references with Expo ones # Test Plan - to be tested on playlist, audioloop, etc. List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

54a69152 - [ios] Make EXUserNotificationCenter a kernel service

Sat, 15 Dec 2018 21:14:41 +0000

[ios] Make EXUserNotificationCenter a kernel service List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

7100de8c - [ios] Upgrade notifications framework to User Notifications Framework (#2316)

Mon, 03 Dec 2018 16:36:04 +0000

[ios] Upgrade notifications framework to User Notifications Framework (#2316)* Updated notifications Moved new permissions files to packages fix updated yarn.lock fixes Requested changes fix after rabase Made requested changes Renamed UserNotificationCenterProxy classes Run `pod install` * Post-review fixes * Minor JS fixes * Do not remember pending notifications in Expo Client (behavior matching previous one) * Prevent blocking main queue at all times by EXUserNotificationRequester * Do not scope categories identifiers in ejected applications * Apply review comments * Remove obsolete if condition * Do not store resolver and rejecter in EXUserNotificationRequester * Update Pods * Add support for deleting custom notification categories * Pass notification to a remembered experience when tapped a notification in backgrounded Expo Client * Update jest-expo mocks * Ensure permissions consuming happens on permissions queue in EXRemoteNotificationRequester * Do not scope notification identifiers * Change cancelScheduledNotification into cancelScheduledNotificationAsync returning native Promise * Deny scheduleNotificationAsync with both time and repeat set on iOS * Allow scheduleNotificationAsync with both time and repeat set on iOS using deprecated UILocalNotification * Add more notification testing buttons to NCL * Export EXUserNotificationManager service as kernel service * Add EXNotificationsIdentifiersManager protocol capable of scoping and unscoping identifiers * Require both RemoteNotificationManager and UserNotificationManager in EXNotifications module * Scope and unscope action identifiers by EXUserNotificationManager * Update pods List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

022bf92a - Register singleton modules with a macro (#2914)

Fri, 17 Aug 2018 15:54:55 +0000

Register singleton modules with a macro (#2914)* [ios] Register singleton modules with macro* [ios] Singleton modules fixes:- move EXPermissionsManager to expo-permissions package,- remove sharedInstance from EXSingletonModule- add name argument to EX_REGISTER_SINGLETON_MODULE- add singleton modules to EXHomeAppManager* [ios][expo-core] Remove obsolete variable definition* [ios] Remove EXSingletonModule references from EXModuleRegistry and EXModuleRegistryProvider* [ios] Add EX_EXPO_CLIENT macro definition* [ios] Remove EX_EXPO_CLIENT preprocessor definition in favor of setting SupportsAppMultiplexing in Info.plist* [ios] Suppress warnings about not being able to call -name on EXSingletonModule classes instances* [ios] Update podsfbshipit-source-id: 3cf91c0 List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

a5a9f97f - Universal modules (#2679)

Tue, 19 Jun 2018 20:39:05 +0000

Universal modules (#2679)��fbshipit-source-id: fb0810e List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

3980c593 - make modals play well with expo menu (#2379)

Wed, 09 May 2018 17:26:27 +0000

make modals play well with expo menu (#2379)fbshipit-source-id: 251bdc0 List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

62dd6356 - Permissions per experience (#2161)

Fri, 13 Apr 2018 21:27:58 +0000

Permissions per experience (#2161)* [android] Permissions module - ask for permissions per experience* [android] Do not check/request permissions on the native side; customize the perm dialog* [expo-sdk] Check permissions before invoking native method* Revert "[expo-sdk] Check permissions before invoking native method"This reverts commit f20c90d7622ec00d206a7e116f70f5c63714e1e0.* [android] DO check permissions on the native side but do not request* [ios] Scoped permissions - wip* [ios] Proper perm in dialog; save user defaults correctly* [ios] Check permissions when required* [ios] Review updates* [ios] Multiple kernel services fixes* [android] Permissions per experience for Android < M* [android] Change shape of permissions in metadata; further refactor for older Android APIs* [android] Apply changes to previous SDKs* [ios] Apply changes to previous SDKsfbshipit-source-id: 328961f List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m

38356829 - Add an EXAudioSessionManager kernel service (#2112)

Fri, 16 Mar 2018 23:34:32 +0000

Add an EXAudioSessionManager kernel service (#2112)fbshipit-source-id: 5fa2d8b List of files: /expo/apps/eas-expo-go/ios/Exponent/Kernel/Core/EXKernelServiceRegistry.m