[notifications][Android] Convert all exported modules to new API (#24499)# Why Converts all exported modules to new API in `expo-notifications`. # Test Plan - bare-expo ✅ - expo go ✅
[android] Remove unnecessary version checks (#24203)# Why This PR is related to #24201, it removes unnecessary version checks # How Remove version check logic for SDK's < 23 # Test Pla
[android] Remove unnecessary version checks (#24203)# Why This PR is related to #24201, it removes unnecessary version checks # How Remove version check logic for SDK's < 23 # Test Plan Tested in Bare Expo in Android 13 simulator
show more ...
[go][android] ScopedContext error (#22869)
[go][android] Fix requestPermissions NullPointerException (#21912)# Why Closes https://github.com/expo/expo/issues/21544 # How When launching the camera through ExpoImagePicker we check fo
[go][android] Fix requestPermissions NullPointerException (#21912)# Why Closes https://github.com/expo/expo/issues/21544 # How When launching the camera through ExpoImagePicker we check for device permissions, but on an Android 13 device the resolution of `Manifest.permission.WRITE_EXTERNAL_STORAGE.takeIf { Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU }` returns `null`. While this isn't a problem for apps using the default `requestPermissions` Activity function, it causes a crash on Expo Go because we have custom logic for permissions using the ScopedPermissionsRequester class. To resolve this issue, we have two options: - Ensure that all `askForPermissions` calls always use `*listOfNotNull` https://github.com/expo/expo/pull/21907) - Update `ScopedPermissionsRequester` `requestPermissions` to ignore `null` values In my opinion, the section option is more robust and ensures that there is no discrepancy between apps running on Expo Go and dev-client/EAS builds # Test Plan Run unversioned Expo Go and test launching the camera using `launchCameraAsync` # Checklist - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin).
[go][Android] Add support for new granular permissions on Android 13 (#20922)# Why Adds support for new granular permissions on Android 13 to the scoped permission code. This is a follow-up to
[go][Android] Add support for new granular permissions on Android 13 (#20922)# Why Adds support for new granular permissions on Android 13 to the scoped permission code. This is a follow-up to 656a42b55a003bdd5da9ea5cb5c07188d8264a5e and 8d01b0f3e9cb5d9f26fa914626738f5b2a0f8f80. # Test Plan - NCL ✅
Use optional JSON access (#20242)
Add manifest key to allow RTL in expo go experiences (#19634)Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Łukasz Kosmaty <[email protected]> Co
Add manifest key to allow RTL in expo go experiences (#19634)Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Łukasz Kosmaty <[email protected]> Co-authored-by: Tomasz Sapeta <[email protected]>
[cellular] Add missing permissions requester (#19633)# Why Fixes: ``` - expo-cellular - `generationName` is “unknown” ``` # How It turns out that the `Manifest.permission.READ_PHON
[cellular] Add missing permissions requester (#19633)# Why Fixes: ``` - expo-cellular - `generationName` is “unknown” ``` # How It turns out that the `Manifest.permission.READ_PHONE_STATE` is danger permission (always has been). So users have to be asked to grant that permission in the runtime to obtain information like network generation. I've added the missing permission getter and requester. Those methods only do something on Android. On other platforms, we can just return the granted response. # Test Plan - expo go with NCL ✅
[android] Fix build errors after #18168 removed packages (#18219)# Why fix android expo go build errors from #18168 removed some packages # How - removed integration code - port `BundleJS
[android] Fix build errors after #18168 removed packages (#18219)# Why fix android expo go build errors from #18168 removed some packages # How - removed integration code - port `BundleJSONConverter` from internal facebook sdk to our code - add necessary 3rd party sdks to versioned sdk dependencies. that is to make sure sdk 44/45 still works # Test Plan - unversioned android expo go + NCL - versioned android expo go + NCL
[android] Fix missing scoped permission (#15658)
[android] Drop SDK40 (#14624)
[android] Use JSONObjectUtils in client code (#14272)
[expo-manifests][android] Move factory into package (#14273)
[expo-manifests] Rename RawManifest -> Manifest (#14194)
[expo-updates] Factor out raw manifests into their own package (#14183)
[android] Kotlinize DI (#14039)
[android] Kotlinize utils (#14003)
[android] Use stable manifest ID where applicable (#12964)
[updates] Finish conversion to an interface for raw manifests (#12509)
[expo-permissions] Fix multiple permissions request crash on Android (#12318)
[expo-media-library][expo-location] Add warnings about Android R changes to old SDKs (#12079)# Why Followup to the https://github.com/expo/fyi/pull/22 # Test Plan - NCL using SDK 40 and
[expo-media-library][expo-location] Add warnings about Android R changes to old SDKs (#12079)# Why Followup to the https://github.com/expo/fyi/pull/22 # Test Plan - NCL using SDK 40 and 39 ✅
[Android][fix] Remove JSONBundleConverter usage for passing manifest from Android to JS (#11678)# Why `Expo Go` is unable to load any project on Android now. Recent change in app manifest shape
[Android][fix] Remove JSONBundleConverter usage for passing manifest from Android to JS (#11678)# Why `Expo Go` is unable to load any project on Android now. Recent change in app manifest shape is responsible for that, namely, new `config plugin system` (for `ncl` project this file: https://github.com/expo/expo/blob/master/apps/native-component-list/app.config.js is adding some array with strings/objects alternately). That is causing https://github.com/expo/expo/blob/fec8b1534e8d27584a685c01a3a12ff432b3fbbd/android/expoview/src/main/java/host/exp/exponent/utils/JSONBundleConverter.java#L72-L81 to throw an error. # How There's no way to convert `JSONArray` with different entries to `Bundle` data type as the latter does not allow arrays/lists containing different data types, only homogenous entries are allowed. I've removed this conversion altogether and replaced all `<someBundle>.putBundle("manifest", JSONBundleConverter.JSONToBundle(manifest))` with `<someBundle>.putString("manifest" manifest.toString())`. I've tried to find any place in the code that would read the `"manifest"` fields from the bundle, but failed to do so �� cc @lukmccall, as there are changes in the `DevMenu` module. From now on, `manifest` field in `initialProps` is replaced by `manifestString` that has to be deserialised upon access. Fortunately this field is not used anywhere in our codebase. # Test Plan - [x] I've succeeded in launching `ncl` and `test-suite` again on Android and observed no regressions. - [x] I've checked that DevMenu shows all the things in the header properly. - [x] I've checked both Android & iOS behaviours.
[android] Remove deprecated overrideUserInterfaceStyle from ExperienceActivityUtils (#11374)# Why - Method used in `HomeActivity` is deprecated and should not be used for experiences running SDK
[android] Remove deprecated overrideUserInterfaceStyle from ExperienceActivityUtils (#11374)# Why - Method used in `HomeActivity` is deprecated and should not be used for experiences running SDK38+. - As far as I know Home is running SDK40+… - …so shouldn't we use the SDK38+ method to override UI style? # How Replaced one method call with another. # Test Plan - [x] Expo Go builds (with some unrelated fixes in place). - [x] Home UI style is taken into account… NOT (see [comment](https://github.com/expo/expo/commit/ad3cdfdbbc1415bf32ef7adbdf4b2e0468452887)).
[android] Migrate installation identifier to non-backed-up storage (#11005)# Why https://github.com/expo/expo/pull/10261#issuecomment-725396140. Also fixes https://github.com/expo/expo/issues/11
[android] Migrate installation identifier to non-backed-up storage (#11005)# Why https://github.com/expo/expo/pull/10261#issuecomment-725396140. Also fixes https://github.com/expo/expo/issues/11008 by making `expo-notifications` use the same installation ID as `expo-constants` and `expoview` (https://github.com/expo/expo/pull/11005/commits/f1ecd07d586094fb9494a5e6584e7d01e419aa48). # 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`](https://developer.android.com/reference/android/content/Context#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](https://github.com/expo/expo/pull/10261/files#diff-d8d19d8e0ef909f84b94eb86534e4dde2f0659b56c72ce5bcde12c5815e8b2fd) 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 https://github.com/expo/expo/pull/10261#issuecomment-725396140 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](https://github.com/TheWizard91/Album_base_source_from_JADX/blob/e1d228fc2ee550ac19eeac700254af8b0f96080a/sources/com/google/firebase/iid/FirebaseInstanceId.java#L227-L231) — 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 `InstallationIdProvider`s, **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 `ConstantsBinding`s 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 `ConstantsBinding`s 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.](https://github.com/expo/expo/issues/11008#issuecomment-728769487) - 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](https://github.com/expo/expo/issues/11008#issuecomment-728769487)). ⚠️ - 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. ✅
Drop SDK 36 (#11033)
123