The 11 branch is the only active development branch for GrapheneOS
- development. Older branches are no longer maintained. It is currently used for all
- officially supported devices and should be used for the basis of ports to other
- devices. Occasionally, some devices may be supported through device support branches
- to avoid impacting other devices with changes needed to support them.
The 11 branch is the only active development branch for GrapheneOS
+ development. Older branches are no longer maintained. It is currently used for all
+ officially supported devices and should be used for the basis of ports to other
+ devices. Occasionally, some devices may be supported through device support branches
+ to avoid impacting other devices with changes needed to support them.
mkdir grapheneos-11 +mkdir grapheneos-11 cd grapheneos-11 repo init -u https://github.com/GrapheneOS/platform_manifest.git -b 11 repo sync -j32-If your network is unreliable and
+repo syncfails, you can run the -repo synccommand again to continue from where it was interrupted. It - handles connection failures robustly and you shouldn't start over from scratch.If your network is unreliable and
+repo syncfails, you can run the +repo synccommand again to continue from where it was interrupted. It + handles connection failures robustly and you shouldn't start over from scratch.
Pick a specific release for a device from the releases page - and download the source tree. Note that some devices use different Android Open Source - Project branches so they can end up with different tags. Make sure to use the correct - tag for a device. For devices without official support, use the latest tag marked as - being appropriate for generic / other devices in the release notes.
+Pick a specific release for a device from the releases page + and download the source tree. Note that some devices use different Android Open Source + Project branches so they can end up with different tags. Make sure to use the correct + tag for a device. For devices without official support, use the latest tag marked as + being appropriate for generic / other devices in the release notes.
-mkdir grapheneos-TAG_NAME +mkdir grapheneos-TAG_NAME cd grapheneos-TAG_NAME repo init -u https://github.com/GrapheneOS/platform_manifest.git -b refs/tags/TAG_NAME-Verify the manifest:
+Verify the manifest:
-gpg --recv-keys 65EEFE022108E2B708CBFCF7F9E712E59AF5F22A +gpg --recv-keys 65EEFE022108E2B708CBFCF7F9E712E59AF5F22A cd .repo/manifests git verify-tag $(git describe) cd ../..-Complete the source tree download:
+Complete the source tree download:
-repo sync -j32+repo sync -j32-The manifest for the latest stable release refers to the revisions in other - repositories via commit hashes rather than tag names. This avoids the need to use a - script to verify tag signatures across all the repositories, since they simply point - to the same commits with the same hashes.
+The manifest for the latest stable release refers to the revisions in other + repositories via commit hashes rather than tag names. This avoids the need to use a + script to verify tag signatures across all the repositories, since they simply point + to the same commits with the same hashes.
-Note that the repo command itself takes care of updating itself and uses gpg to - verify by default.
+Note that the repo command itself takes care of updating itself and uses gpg to + verify by default.
+
Incremental updates shipping only the changes between two versions can be generated
- as a much more efficient way of shipping updates than a full update package containing
- the entire operating system. The GrapheneOS Updater app will automatically use a delta
- update if one exists for going directly from the currently installed version to the
- latest release. In order to generate a delta update, the original signed target files
- package for both the source version and target version are needed. The
- script/generate_delta.sh script provides a wrapper script for generating
- delta updates by passing the device, source version build number and target version
- build number. For example:
Incremental updates shipping only the changes between two versions can be generated
+ as a much more efficient way of shipping updates than a full update package containing
+ the entire operating system. The GrapheneOS Updater app will automatically use a delta
+ update if one exists for going directly from the currently installed version to the
+ latest release. In order to generate a delta update, the original signed target files
+ package for both the source version and target version are needed. The
+ script/generate_delta.sh script provides a wrapper script for generating
+ delta updates by passing the device, source version build number and target version
+ build number. For example:
script/generate_delta.sh crosshatch 2019.09.25.00 2019.10.07.21+
script/generate_delta.sh crosshatch 2019.09.25.00 2019.10.07.21-
The script assumes that the releases are organized in the following directory - structure:
+The script assumes that the releases are organized in the following directory + structure:
-releases +-releases ├── 2019.09.25.00 │ └── release-crosshatch-2019.09.25.00 │ ├── crosshatch-factory-2019.09.25.00.zip @@ -698,10 +697,11 @@ cd ../..├── crosshatch-target_files-2019.10.07.21.zip └── crosshatch-testing
Incremental updates are uploaded alongside the update packages and update metadata - on the static web server used as an update server. The update client will - automatically check for an incremental update and use it if available. No additional - metadata is needed to make incremental updates work.
+Incremental updates are uploaded alongside the update packages and update metadata + on the static web server used as an update server. The update client will + automatically check for an incremental update and use it if available. No additional + metadata is needed to make incremental updates work.
+Testing with the Compatibility Test Suite (CTS) can be done by either building the - test suite from source or using the official releases.
-Official releases of the CTS can be downloaded from - the Compatibility - Suite Downloads page. You should download the CTS for the relevant release - (Android 11) and architecture (ARM). There's a separate zip for the main CTS, the - manual portion (CTS Verifier) and the CTS for Instant Apps. The latest release of the - CTS Media Files also needs to be downloaded from that section.
+Testing with the Compatibility Test Suite (CTS) can be done by either building the + test suite from source or using the official releases.
+Official releases of the CTS can be downloaded from + the Compatibility + Suite Downloads page. You should download the CTS for the relevant release + (Android 11) and architecture (ARM). There's a separate zip for the main CTS, the + manual portion (CTS Verifier) and the CTS for Instant Apps. The latest release of the + CTS Media Files also needs to be downloaded from that section.
-mkdir -p ~/android/cts/{arm,x86}
+ mkdir -p ~/android/cts/{arm,x86}
cd ~/android/cts/arm
curl -O https://dl.google.com/dl/android/cts/android-cts-11_r1-linux_x86-arm.zip
unzip android-cts-11_r1-linux_x86-arm.zip
@@ -996,66 +995,67 @@ cd ~/android/cts
curl -O https://dl.google.com/dl/android/cts/android-cts-media-1.5.zip
unzip android-cts-media-1.5.zip
rm android-cts-media-1.5.zip
+ You'll need a device attached to your computer with ADB enabled along with the - Android SDK installed. The build-tools and platform-tools packages need to be - installed and the binaries need to be added to your PATH. See the - standalone SDK installation instructions above.
+You'll need a device attached to your computer with ADB enabled along with the + Android SDK installed. The build-tools and platform-tools packages need to be + installed and the binaries need to be added to your PATH. See the + standalone SDK installation instructions above.
-Copy media onto the device:
-cd android-cts-media-1.5 +Copy media onto the device:
+cd android-cts-media-1.5 ./copy_images.sh ./copy_media.sh-You also need to do some basic setup for the device. It's possible for changes from - a baseline install to cause interference, so it can be a good idea to factory reset - the device if assorted changes have been made. The device needs to be running a user - build for the security model to be fully intact in order to pass all the security - tests. A userdebug build is expected to fail some of the tests. GrapheneOS also makes - various changes intentionally deviating from the requirements expected by the CTS, so - there will always be some expected failures. A few of the tests are also known to be - quite flaky or broken even with the stock OS and/or AOSP. These will be documented - here at some point.
+You also need to do some basic setup for the device. It's possible for changes from + a baseline install to cause interference, so it can be a good idea to factory reset + the device if assorted changes have been made. The device needs to be running a user + build for the security model to be fully intact in order to pass all the security + tests. A userdebug build is expected to fail some of the tests. GrapheneOS also makes + various changes intentionally deviating from the requirements expected by the CTS, so + there will always be some expected failures. A few of the tests are also known to be + quite flaky or broken even with the stock OS and/or AOSP. These will be documented + here at some point.
-
Run the test harness:
-./android-cts/tools/cts-tradefed-
Note that _JAVA_OPTIONS being set will break the version detection.
To obtain a list of CTS modules:
-list modules-
To run a specific module and avoid wasting time capturing device information:
-run cts --skip-device-info --module CtsModuleName-
To speed up initialization after running some initial tests:
-run cts --skip-device-info --skip-preconditions --module CtsModuleName-
It's possible to run the whole standard CTS plan with a single command, but running - specific modules is recommended, especially if you don't have everything set up for - the entire test suite.
+Run the test harness:
+./android-cts/tools/cts-tradefed+
Note that _JAVA_OPTIONS being set will break the version detection.
To obtain a list of CTS modules:
+list modules+
To run a specific module and avoid wasting time capturing device information:
+run cts --skip-device-info --module CtsModuleName+
To speed up initialization after running some initial tests:
+run cts --skip-device-info --skip-preconditions --module CtsModuleName+
It's possible to run the whole standard CTS plan with a single command, but running + specific modules is recommended, especially if you don't have everything set up for + the entire test suite.
+