[expo-updates][android] Bare update manifest non-nullability parity (#23166)
[expo-updates] add docblocks to most classes (#19491)
[expo-updates] Add log lines for the error scenarios we want to track (#18810)
[ios][android][expo-updates] Change asset hash verification encoding to base64url (#16174)
[expo-updates][android] Add code signing (#15514)
[expo-updates][android] Add support for multipart manifest responses (#15401)
[expo-updates] add DEFAULT 0 to new error recovery DB columns (#15360)
[expo-updates][android] add database fields for error recovery (#15218)
[expo-updates][android] Kotlinize expo-updates (#14818)
[expo-updates][android][sqlite] make assets.type nullable (#14499)
[expo-manifests] Rename RawManifest -> Manifest (#14194)
[expo-updates] Factor out raw manifests into their own package (#14183)
[expo-updates] rename Update.metadata -> Update.manifest (#12818)
[expo-updates] add last_accessed column to updates table (destructive migration) (#12768)
[updates] Finish conversion to an interface for raw manifests (#12509)
[expo-updates] add SQLite migrations to make `assets.key` nullable (#12110)
Revert "[expo-updates] add SQLite migrations to make `assets.key` nullable (#12084)"This reverts commit 11e7ce8e496ee5676718ec7f68684db422c63643.
[expo-updates] add SQLite migrations to make `assets.key` nullable (#12084)
[expo-updates][database] add json_data table (#11049)# Why In order to support the new EAS update manifest format and particularly the `serverDefinedHeaders` and `manifestFilters` fields, we nee
[expo-updates][database] add json_data table (#11049)# Why In order to support the new EAS update manifest format and particularly the `serverDefinedHeaders` and `manifestFilters` fields, we need to be able to store some general JSON data from the server on disk (and then use it when requesting/launching future updates). It makes the most sense to use the SQLite database for this since we already use this to persist all other updates-related metadata. # How This PR adds a `json_data` table for storing arbitrary JSON blobs keyed by a string (like `manifestFilters`) and a scopeKey. Critically, this PR also bumps the updates SQLite database version number; this currently causes a destructive migration and requires that it be released in a major SDK release. A future PR will use this table in the implementation of the `serverDefinedHeaders` and `manifestFilters` from the RFC. # Test Plan Built Expo client on both platforms and viewed the updates SQLite database in a desktop SQLite browser to ensure the table was created properly.
show more ...
[expo-updates] add scopeKey field to configuration and use when interacting with database (#9217)# Why Allow updates for multiple projects to be stored in the same database. # How We previ
[expo-updates] add scopeKey field to configuration and use when interacting with database (#9217)# Why Allow updates for multiple projects to be stored in the same database. # How We previously added the project_identifier field in the database for this purpose -- it is meant to be a unique ID for a project that can be used to filter stored updates by project. This commit adds a migration to turn that field into `scope_key`, adds a corresponding `scopeKey` field to the updates configuration object, and uses this `config.scopeKey` field both when inserting and selecting updates from the database. If no `scopeKey` is specified, it defaults to the manifest (update) URL origin. # Test Plan No behavior changes are expected, this just adds functionality that will be utilized when integrating the module into the App Store clients. Added some unit tests for the URL origin normalization logic.
[expo-updates] copy assets from embedded bare bundle (#8007)
[expo-updates] add asset packagerKey field and make url nullable
[expo-updates] add Android implementation