add next layer of explicit sections to build guide

This commit is contained in:
Daniel Micay 2020-12-06 13:23:32 -05:00
parent b67a21664a
commit f4083f40df

View File

@ -124,9 +124,8 @@
<section id="building-grapheneos"> <section id="building-grapheneos">
<h2><a href="#building-grapheneos">Building GrapheneOS</a></h2> <h2><a href="#building-grapheneos">Building GrapheneOS</a></h2>
<h3 id="build-targets"> <section id="build-targets">
<a href="#build-targets">Build targets</a> <h3><a href="#build-targets">Build targets</a></h3>
</h3>
<p>Smartphone targets:</p> <p>Smartphone targets:</p>
@ -191,10 +190,10 @@
<p>These are extended versions of the generic targets with extra components for the <p>These are extended versions of the generic targets with extra components for the
SDK. These targets don't receive full monthly security updates, don't provide all of SDK. These targets don't receive full monthly security updates, don't provide all of
the baseline security features and are intended for development usage.</p> the baseline security features and are intended for development usage.</p>
</section>
<h3 id="build-dependencies"> <section id="build-dependencies">
<a href="#build-dependencies">Build dependencies</a> <h3><a href="#build-dependencies">Build dependencies</a></h3>
</h3>
<p>Arch Linux, Debian buster and Ubuntu 20.04 LTS are the officially supported <p>Arch Linux, Debian buster and Ubuntu 20.04 LTS are the officially supported
operating systems for building GrapheneOS.</p> operating systems for building GrapheneOS.</p>
@ -276,10 +275,10 @@
<p>The <code>signify</code> tool (with the proper naming) is also required for signing <p>The <code>signify</code> tool (with the proper naming) is also required for signing
factory images zips.</p> factory images zips.</p>
</section>
<h3 id="downloading-source-code"> <section id="downloading-source-code">
<a href="#downloading-source-code">Downloading source code</a> <h3><a href="#downloading-source-code">Downloading source code</a></h3>
</h3>
<p>Since this is syncing the sources for the entire operating system and application <p>Since this is syncing the sources for the entire operating system and application
layer, it will use a lot of bandwidth and storage space.</p> layer, it will use a lot of bandwidth and storage space.</p>
@ -339,10 +338,10 @@ cd ../..</pre>
<p>Note that the repo command itself takes care of updating itself and uses gpg to <p>Note that the repo command itself takes care of updating itself and uses gpg to
verify by default.</p> verify by default.</p>
</section>
<h3 id="updating-and-switching-branches-or-tags"> <section id="updating-and-switching-branches-or-tags">
<a href="#updating-and-switching-branches-or-tags">Updating and switching branches or tags</a> <h3><a href="#updating-and-switching-branches-or-tags">Updating and switching branches or tags</a></h3>
</h3>
<p>To update the source tree, run the <code>repo init</code> command again to select <p>To update the source tree, run the <code>repo init</code> command again to select
the branch or tag and then run <code>repo sync -j32</code> again. You may need to add the branch or tag and then run <code>repo sync -j32</code> again. You may need to add
@ -351,10 +350,10 @@ cd ../..</pre>
You don't need to start over to switch between different branches or tags. You may You don't need to start over to switch between different branches or tags. You may
need to run <code>repo init</code> again to continue down the same branch since need to run <code>repo init</code> again to continue down the same branch since
GrapheneOS only provides a stable history via tags.</p> GrapheneOS only provides a stable history via tags.</p>
</section>
<h3 id="kernel"> <section id="kernel">
<a href="#kernel">Kernel</a> <h3><a href="#kernel">Kernel</a></h3>
</h3>
<p>The kernel needs to be built in advance, since it uses a separate build system.</p> <p>The kernel needs to be built in advance, since it uses a separate build system.</p>
@ -401,10 +400,10 @@ cd ../..</pre>
git submodule sync git submodule sync
git submodule update --init --recursive git submodule update --init --recursive
./build.sh blueline</pre> ./build.sh blueline</pre>
</section>
<h3 id="setting-up-the-os-build-environment"> <section id="setting-up-the-os-build-environment">
<a href="#setting-up-the-os-build-environment">Setting up the OS build environment</a> <h3><a href="#setting-up-the-os-build-environment">Setting up the OS build environment</a></h3>
</h3>
<p>The build has to be done from bash as envsetup.sh is not compatible with other <p>The build has to be done from bash as envsetup.sh is not compatible with other
shells like zsh.</p> shells like zsh.</p>
@ -432,10 +431,10 @@ git submodule update --init --recursive
over and over again since it will never be signed with your key.</p> over and over again since it will never be signed with your key.</p>
<pre>export OFFICIAL_BUILD=true</pre> <pre>export OFFICIAL_BUILD=true</pre>
</section>
<h3 id="reproducible-builds"> <section id="reproducible-builds">
<a href="#reproducible-builds">Reproducible builds</a> <h3><a href="#reproducible-builds">Reproducible builds</a></h3>
</h3>
<p>To reproduce a past build, you need to export <code>BUILD_DATETIME</code> and <p>To reproduce a past build, you need to export <code>BUILD_DATETIME</code> and
<code>BUILD_NUMBER</code> to the values set for the past build. These can be obtained <code>BUILD_NUMBER</code> to the values set for the past build. These can be obtained
@ -455,10 +454,10 @@ git submodule update --init --recursive
domain, you <strong>must</strong> disable the Updater app before connecting the device domain, you <strong>must</strong> disable the Updater app before connecting the device
to the internet, or you will be performing a denial of service attack on our official to the internet, or you will be performing a denial of service attack on our official
update server.</p> update server.</p>
</section>
<h3 id="extracting-vendor-files-for-pixel-devices"> <section id="extracting-vendor-files-for-pixel-devices">
<a href="#extracting-vendor-files-for-pixel-devices">Extracting vendor files for Pixel devices</a> <h3><a href="#extracting-vendor-files-for-pixel-devices">Extracting vendor files for Pixel devices</a></h3>
</h3>
<p>This section is specific to Pixel devices. The emulator and generic targets don't <p>This section is specific to Pixel devices. The emulator and generic targets don't
require extra vendor files.</p> require extra vendor files.</p>
@ -480,10 +479,10 @@ mv vendor/android-prepare-vendor/DEVICE/BUILD_ID/vendor/google_devices/* vendor/
<p>Note that android-prepare-vendor is non-deterministic unless a timestamp parameter is <p>Note that android-prepare-vendor is non-deterministic unless a timestamp parameter is
passed with <code>--timestamp</code> (seconds since Epoch).</p> passed with <code>--timestamp</code> (seconds since Epoch).</p>
</section>
<h3 id="building"> <section id="building">
<a href="#building">Building</a> <h3><a href="#building">Building</a></h3>
</h3>
<p>Incremental builds (i.e. starting from the old build) usually work for development <p>Incremental builds (i.e. starting from the old build) usually work for development
and are the normal way to develop changes. However, there are cases where changes are and are the normal way to develop changes. However, there are cases where changes are
@ -503,10 +502,10 @@ mv vendor/android-prepare-vendor/DEVICE/BUILD_ID/vendor/google_devices/* vendor/
number of available logical CPUs.</p> number of available logical CPUs.</p>
<p><strong>For an emulator build, always use the development build approach below.</strong></p> <p><strong>For an emulator build, always use the development build approach below.</strong></p>
</section>
<h3 id="faster-builds-for-development-use-only"> <section id="faster-builds-for-development-use-only">
<a href="#faster-builds-for-development-use-only">Faster builds for development use only</a> <h3><a href="#faster-builds-for-development-use-only">Faster builds for development use only</a></h3>
</h3>
<p>The normal production build process involves building a target files package to be <p>The normal production build process involves building a target files package to be
resigned with secure release keys and then converted into factory images and/or an resigned with secure release keys and then converted into factory images and/or an
@ -527,10 +526,10 @@ mv vendor/android-prepare-vendor/DEVICE/BUILD_ID/vendor/google_devices/* vendor/
signing the build with release keys would be testing that functionality and it makes a signing the build with release keys would be testing that functionality and it makes a
lot more sense to test it with proper signing keys rather than the default public test lot more sense to test it with proper signing keys rather than the default public test
keys.</p> keys.</p>
</section>
<h3 id="generating-release-signing-keys"> <section id="generating-release-signing-keys">
<a href="#generating-release-signing-keys">Generating release signing keys</a> <h3><a href="#generating-release-signing-keys">Generating release signing keys</a></h3>
</h3>
<p>Keys need to be generated for resigning completed builds from the publicly <p>Keys need to be generated for resigning completed builds from the publicly
available test keys. The keys must then be reused for subsequent builds and cannot be available test keys. The keys must then be reused for subsequent builds and cannot be
@ -618,10 +617,10 @@ cd ../..</pre>
<p>For now, consult the upstream documentation on generating these keys. It will be <p>For now, consult the upstream documentation on generating these keys. It will be
covered here in the future.</p> covered here in the future.</p>
</section>
<h3 id="generating-signed-factory-images-and-full-update-packages"> <section id="generating-signed-factory-images-and-full-update-packages">
<a href="#generating-signed-factory-images-and-full-update-packages">Generating signed factory images and full update packages</a> <h3><a href="#generating-signed-factory-images-and-full-update-packages">Generating signed factory images and full update packages</a></h3>
</h3>
<p>Build and package up the tools needed to generate over-the-air update packages:</p> <p>Build and package up the tools needed to generate over-the-air update packages:</p>
@ -704,6 +703,7 @@ cd ../..</pre>
automatically check for an incremental update and use it if available. No additional automatically check for an incremental update and use it if available. No additional
metadata is needed to make incremental updates work.</p> metadata is needed to make incremental updates work.</p>
</section> </section>
</section>
<section id="prebuilt-code"> <section id="prebuilt-code">
<h2><a href="#prebuilt-code">Prebuilt code</a></h2> <h2><a href="#prebuilt-code">Prebuilt code</a></h2>
@ -712,9 +712,8 @@ cd ../..</pre>
separately and then bundled into the source tree as binaries. This section will be separately and then bundled into the source tree as binaries. This section will be
gradually expanded to cover building all of it.</p> gradually expanded to cover building all of it.</p>
<h3 id="browser-and-webview"> <section id="browser-and-webview">
<a href="#browser-and-webview">Browser and WebView</a> <h3><a href="#browser-and-webview">Browser and WebView</a></h3>
</h3>
<p>Vanadium is a hardened fork of Chromium developed by GrapheneOS and used to provide <p>Vanadium is a hardened fork of Chromium developed by GrapheneOS and used to provide
the WebView and <em>optionally</em> the standalone browser app. It tracks the Chromium the WebView and <em>optionally</em> the standalone browser app. It tracks the Chromium
@ -788,10 +787,10 @@ gclient sync -D --with_branch_heads --with_tags --jobs 32</pre>
<p>WebView provider apps need to be whitelisted in <p>WebView provider apps need to be whitelisted in
<code>frameworks/base/core/res/res/xml/config_webview_packages</code>. By default, <code>frameworks/base/core/res/res/xml/config_webview_packages</code>. By default,
only the Vanadium WebView is whitelisted.</p> only the Vanadium WebView is whitelisted.</p>
</section>
<h3 id="prebuilt-apps"> <section id="prebuilt-apps">
<a href="#prebuilt-apps">Prebuilt apps</a> <h3><a href="#prebuilt-apps">Prebuilt apps</a></h3>
</h3>
<p>The official releases of the Auditor and PdfViewer apps are bundled as an apk into <p>The official releases of the Auditor and PdfViewer apps are bundled as an apk into
external/ repositories. There are no modifications to these for GrapheneOS. These are external/ repositories. There are no modifications to these for GrapheneOS. These are
@ -801,6 +800,7 @@ gclient sync -D --with_branch_heads --with_tags --jobs 32</pre>
<p>A build of Seedvault is bundled as an apk into an external/ repository. There are <p>A build of Seedvault is bundled as an apk into an external/ repository. There are
no modifications made to it.</p> no modifications made to it.</p>
</section> </section>
</section>
<section id="update-server"> <section id="update-server">
<h2><a href="#update-server">Update server</a></h2> <h2><a href="#update-server">Update server</a></h2>
@ -953,17 +953,16 @@ mv android-studio studio</pre>
rather than only the current very minimal coverage of the Compatibility Test Suite rather than only the current very minimal coverage of the Compatibility Test Suite
(CTS).</p> (CTS).</p>
<h3 id="emulator"> <section id="emulator">
<a href="#emulator">Emulator</a> <h3><a href="#emulator">Emulator</a></h3>
</h3>
<p>To test a build for the emulator, run <code>emulator</code> within the build <p>To test a build for the emulator, run <code>emulator</code> within the build
environment. The emulator will use CPU hardware acceleration via KVM along with environment. The emulator will use CPU hardware acceleration via KVM along with
optional graphics acceleration via the host GPU if these are available.</p> optional graphics acceleration via the host GPU if these are available.</p>
</section>
<h3 id="compatibility-test-suite"> <section id="compatibility-test-suite">
<a href="#compatibility-test-suite">Compatibility Test Suite</a> <h3><a href="#compatibility-test-suite">Compatibility Test Suite</a></h3>
</h3>
<h4 id="compatibility-test-suite-download"> <h4 id="compatibility-test-suite-download">
<a href="#compatibility-test-suite-download">Download</a> <a href="#compatibility-test-suite-download">Download</a>
@ -1058,6 +1057,7 @@ rm android-cts-media-1.5.zip</pre>
specific modules is recommended, especially if you don't have everything set up for specific modules is recommended, especially if you don't have everything set up for
the entire test suite.</p> the entire test suite.</p>
</section> </section>
</section>
<section id="obtaining-upstream-manifests"> <section id="obtaining-upstream-manifests">
<h2><a href="#obtaining-upstream-manifests">Obtaining upstream manifests</a></h2> <h2><a href="#obtaining-upstream-manifests">Obtaining upstream manifests</a></h2>
@ -1098,9 +1098,8 @@ rm android-cts-media-1.5.zip</pre>
<section id="development-guidelines"> <section id="development-guidelines">
<h2><a href="#development-guidelines">Development guidelines</a></h2> <h2><a href="#development-guidelines">Development guidelines</a></h2>
<h3 id="programming-languages"> <section id="programming-languages">
<a href="#programming-languages">Programming languages</a> <h3><a href="#programming-languages">Programming languages</a></h3>
</h3>
<p>The following programming languages are acceptable for <strong>completely <p>The following programming languages are acceptable for <strong>completely
new</strong> GrapheneOS projects:</p> new</strong> GrapheneOS projects:</p>
@ -1134,10 +1133,10 @@ rm android-cts-media-1.5.zip</pre>
could be used without causing a substantial maintenance burden. The following could be used without causing a substantial maintenance burden. The following
languages are typical from most to least common: Java, C++, C, JavaScript, arm64 languages are typical from most to least common: Java, C++, C, JavaScript, arm64
assembly, POSIX shell, Bash.</p> assembly, POSIX shell, Bash.</p>
</section>
<h3 id="code-style"> <section id="code-style">
<a href="#code-style">Code style</a> <h3><a href="#code-style">Code style</a></h3>
</h3>
<p>For existing projects, use the official upstream code style. Avoid using legacy <p>For existing projects, use the official upstream code style. Avoid using legacy
conventions that they're moving away from themselves. Follow the code style they use conventions that they're moving away from themselves. Follow the code style they use
@ -1246,10 +1245,10 @@ rm android-cts-media-1.5.zip</pre>
invariant is true based on the code elsewhere (consider a runtime check to make sure invariant is true based on the code elsewhere (consider a runtime check to make sure
it's true, or an assertion if performance would be an issue). Docstrings at the top of it's true, or an assertion if performance would be an issue). Docstrings at the top of
top-level functions, modules, etc. are a different story and shouldn't be avoided.</p> top-level functions, modules, etc. are a different story and shouldn't be avoided.</p>
</section>
<h3 id="library-usage"> <section id="library-usage">
<a href="#library-usage">Library usage</a> <h3><a href="#library-usage">Library usage</a></h3>
</h3>
<p>Make extensive usage of well designed standard library modules. For apps, treat <p>Make extensive usage of well designed standard library modules. For apps, treat
Jetpack (androidx) as part of the standard library and make good use of it. For Java, Jetpack (androidx) as part of the standard library and make good use of it. For Java,
@ -1269,6 +1268,7 @@ rm android-cts-media-1.5.zip</pre>
actually makes sense to use, otherwise just stick to the old fashioned way if the actually makes sense to use, otherwise just stick to the old fashioned way if the
fancy alternatives aren't genuinely better.</p> fancy alternatives aren't genuinely better.</p>
</section> </section>
</section>
</main> </main>
<footer> <footer>
<a href="/"><img src="/logo.png" width="512" height="512" alt=""/>GrapheneOS</a> <a href="/"><img src="/logo.png" width="512" height="512" alt=""/>GrapheneOS</a>