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

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

[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-

[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

show more ...

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

This reverts commit 454e16d504aee225b3bdc8ee3fedbbdc051c7209.

# Why

After #11371, `lockAsync` is broken in iOS Expo Go; it

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

show more ...

[ios] Remove legacy ScreenOrientation code (#11371)

[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 ...

[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

[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 ��

show more ...

[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

[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.

show more ...

[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.

[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.co

[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.

show more ...

[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://

[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.

show more ...

[packages] Move unimodules foundation to `org.unimodules` scope

[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
-

[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.

show more ...

[ios] Make EXUserNotificationCenter a kernel service

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

* Updated notifications

Moved new permissions files to packages

fix

updated yarn.lock

fixes

Requested cha

[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

show more ...

Register singleton modules with a macro (#2914)

* [ios] Register singleton modules with macro

* [ios] Singleton modules fixes:

- move EXPermissionsManager to expo-permissions package,
- remove sha

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 pods

fbshipit-source-id: 3cf91c0

show more ...

Universal modules (#2679)

��

fbshipit-source-id: fb0810e

make modals play well with expo menu (#2379)

fbshipit-source-id: 251bdc0

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

*

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 SDKs

fbshipit-source-id: 328961f

show more ...

Add an EXAudioSessionManager kernel service (#2112)

fbshipit-source-id: 5fa2d8b

Updates module (#2203)

fbshipit-source-id: 477c902

restores full menu functionality except QR button

fbshipit-source-id: 8370f90

OTA Updates improvements (#1925)

* [android] fetch updated manifest on launch and allow specified amount of time to do this before populating experienceactivity

* [android] only consume response on

OTA Updates improvements (#1925)

* [android] fetch updated manifest on launch and allow specified amount of time to do this before populating experienceactivity

* [android] only consume response once in onCachedResponse

* [android] removed CountDownTimer in favor of Handler.postDelayed

* [WIP][android] moved all new manifest loading code to new methods with AtomicBundleListener rather than ManifestListener

* [android] moved JS bundle loading to before populating experienceactivity

* [android] refactored most of the new logic into its own AtomicBundleListener class per conversation with Jesse

* [ios][wip] beginning ios changes

* [ios] WIP

* [ios] more wip, have full manifest-fetching logic in AtomicBundleManager

* [ios] reverted changes to bridgeRecord in favor of creating new AppRegistry and AppRecord classes; will eventually refactor everything to use these rather than BridgeRegistry; getManifestAsync now uses AtomicBundleManager for fetching manifest

* [ios] wip, start on bundle loading

* [ios] wip wip wip. not sure how much of the logic to be moving from EXFrameReactAppManager to new class - maybe should keep _jsResource logic in original

* [ios] bundle loading now working from atomic bundle manager

* [ios] renamed new class to AtomicBundleLoader to avoid using word Manager

* [ios] trying to get reloading to work again; there is some weird issue with objc/js communication but going to save it for later

* [ios] wip with adding js bundle loading into timeout - currently just setting a timeout directly on the request

* [ios] bundle loading part of timeout

* [ios] renaming methods to use underscore prefix

* [ios] fully replace EXKernelBridgeRegistry and BridgeRecord with AppRegistry and AppRecord

* [ios] refactor request bundle method to use FrameReactAppManager as delegate

* [ios] renamed AtomicBundleLoader to AppLoader per Ben's suggestion

* [ios] step 1 in resolving reloading issue

* [ios] fix reloading on ios -- now using a UUID to identify record rather than manifestUrl, and we enforce uniqueness after the entire manifest/bundle is loaded to give time for the other record to be removed. Also, changed _appRegistry to an NSMutableDictionary, since NSMapTable was no longer needed and NSMutableDictionary is easier to copy -- safer since we're mixing mutations & enumeration more.

* [ios] a couple more fixes to make sure we're handling possible duplicate AppRecords properly

* [ios] better handling of various cases with possible inconsistencies/network errors

* [ios] add loadedFromCache key to manifest

* [ios] separated resolveWithCachedManifest and resolveWithCachedBundle to avoid situation where resolveWithCachedManifest is called with an error after manifest _finished == YES and therefore bundle never gets fetched

* [android] added loadedFromCache key to manifest, not sure why it's always false...

* [android] loadedFromCache manifest key working now

* [android] prevent onManifestCompleted from being called twice

* [ios] EXKernelAppLoader - control downloading bundle entirely, and don't resolve with manifest until after bundle has been downloaded successfully

* [ios] removed now obsolete EXKernelBundleLoaderDelegate methods

* [home] first step in loading progress fix - move manifest and bundleUrl fetching to a separate flux action, and allow a BrowserScreen to be mounted to show loading progress before manifest is fetched

* [ios][home] bundle loading progress now showing; need to show assets/icon properly, and resolve occasional crash when bundle download reaches 100%

* [home] fixed missing icons and name in project history

* [ios][home] send new manifest optimistically to JS as soon as we receive it so that JS can show the correct icon and background color on loading screen

* [home] moved some logic from BrowserActions to Browser to try and keep actions more pure

* [ios] fix for opening client from a notification - previously an EXKernelAppRecord was never created in this case. Might want to think about only ever creating AppRecords when the manifest is requested

* [home] improve safety/handling of optimisticManifest

* [home] fix for standalone apps where props.task is initially null

* [ios] pass recordId into frame so it can use this to unregister itself safely instead of trying to iterate through all of the records to find a potentially non-unique experienceId. Also, register AppRecords when manifest is requested as there is no reason for them to exist before this

* [ios] add new EXCachedResourceBehavior to never read from the cache but make sure we are always writing to it

* [android] don't send manifest or bundle until we have either downloaded a new bundle or timed out

* [android] only write the manifest that we are actually using to shared preferences

* [android] correct loadedFromCache value (again)

* [android] fix loading icon and progress for dev mode - don't try and download the bundle in exponent code

* [android] send optimistic manifest to ExperienceActivity as soon as we download it so that the activity can display the proper loading screen/icon/task info

* [android] use AtomicBundleListener for detached and shell apps as well

* [android] make sure that AtomicBundleListener is the only thing that is calling loadJSBundle (for non-kernel bundles)

* [android] fix opening detached apps after the first run

* [android] improve handling of failures

* [home] stop accidentally swallowing errors wfrom fetching manifest on iOS

* [ios] clean up stopTimer usage, as anytime we call _resolve we don't want to call it again

* [ios] simplify timeout on JS bundle fetching - since the NSTimer will take care of resolving anyway, we don't need to set the timeout on the JS bundle request based on the timer

* [android] renamed AtomicBundleListener to AppLoader as this is a better description of what it does

* [server] updated unversioned schema with new app.json fields

* [ios][android] make sure to only fetch remote manifest if the shouldCheckForUpdate is true

* [android] if in dev mode, skip the cached manifest + set timer step and just go fetch the remote manifest every time

* [ios][android] stop making bad assumptions -- if a cached manifest exists, it is possible that the corresponding bundle does not exist for some reason, and in this case we should download rather than failing to user

* [ios] resolved first cycle of ben's comments

* [ios][home] resolved some of ben's 2nd round of comments

* [ios] resolved most of ben's 3rd round of comments'

* [ios][server] resolved a few more comments

* [ios] added status enum property to EXKernelAppRecord & so that kernel services can skip over any AppRecords which are partially loaded

* [ios] add todo to get rid of lazy copy workaround

* [android] resolve jesse's comments

* [android] store loading errors in ExponentSharedPreferences, and make sure that we always try to load a new manifest + bundle if this is set to true when loading experience

* [ios] resolved last of Ben's comments, including adding a way for AppRecord to be notified when bridge has successfully loaded JS

* [schema] mark loadJSInBackgroundExperimental as deprecated

* [android] fix loading apps for the first time in dev mode

fbshipit-source-id: 4d763d0

show more ...

Improve assets bundle runtime implementation, support most asset types (#1691)

fbshipit-source-id: d3045f7

Bundle image assets for standalone apps (#1357)

* [iOS][android] Support bundled assets for images

* Remove <projectRoot> tag

fbshipit-source-id: 7ba9069