finish adding explicit sections to build guide

This commit is contained in:
Daniel Micay 2020-12-06 13:30:13 -05:00
parent f4083f40df
commit 983a1871f1

View File

@ -287,9 +287,8 @@
for developing a feature. It's easier to port between stable tags that are known to
work properly than dealing with a moving target.</p>
<h4 id="development-branch">
<a href="#development-branch">Development branch</a>
</h4>
<section id="development-branch">
<h4><a href="#development-branch">Development branch</a></h4>
<p>The <code>11</code> branch is the only active development branch for GrapheneOS
development. Older branches are no longer maintained. It is currently used for all
@ -305,10 +304,10 @@ repo sync -j32</pre>
<p>If your network is unreliable and <code>repo sync</code> fails, you can run the
<code>repo sync</code> command again to continue from where it was interrupted. It
handles connection failures robustly and you shouldn't start over from scratch.</p>
</section>
<h4 id="stable-release">
<a href="#stable-release">Stable release</a>
</h4>
<section id="stable-release">
<h4><a href="#stable-release">Stable release</a></h4>
<p>Pick a specific release for a device from the <a href="/releases">releases page</a>
and download the source tree. Note that some devices use different Android Open Source
@ -339,6 +338,7 @@ cd ../..</pre>
<p>Note that the repo command itself takes care of updating itself and uses gpg to
verify by default.</p>
</section>
</section>
<section id="updating-and-switching-branches-or-tags">
<h3><a href="#updating-and-switching-branches-or-tags">Updating and switching branches or tags</a></h3>
@ -580,9 +580,8 @@ cd ../..</pre>
same scripts along with the expectation of it using the same passphrase as the other
keys.</p>
<h4 id="encrypting-keys">
<a href="#encrypting-keys">Encrypting keys</a>
</h4>
<section id="encrypting-keys">
<h4><a href="#encrypting-keys">Encrypting keys</a></h4>
<p>You can (re-)encrypt your signing keys using the <code>encrypt_keys</code> script,
which will prompt for the old passphrase (if any) and new passphrase:</p>
@ -592,10 +591,10 @@ cd ../..</pre>
<p>The <code>script/decrypt_keys.sh</code> script can be used to remove encryption,
which is not recommended. The script exists primarily for internal usage to decrypt
the keys in tmpfs to perform signing.</p>
</section>
<h4 id="enabling-updatable-apex-components">
<a href="#enabling-updatable-apex-components">Enabling updatable APEX components</a>
</h4>
<section id="enabling-updatable-apex-components">
<h4><a href="#enabling-updatable-apex-components">Enabling updatable APEX components</a></h4>
<p>GrapheneOS disables updatable APEX components for the officially supported devices
and targets inheriting from the mainline target, so APEX signing keys are not needed
@ -618,6 +617,7 @@ cd ../..</pre>
<p>For now, consult the upstream documentation on generating these keys. It will be
covered here in the future.</p>
</section>
</section>
<section id="generating-signed-factory-images-and-full-update-packages">
<h3><a href="#generating-signed-factory-images-and-full-update-packages">Generating signed factory images and full update packages</a></h3>
@ -661,9 +661,8 @@ cd ../..</pre>
Stable channel after public testing. A similar approach is recommended for derivatives
of GrapheneOS.</p>
<h4 id="generating-delta-updates">
<a href="#generating-delta-updates">Generating delta updates</a>
</h4>
<section id="generating-delta-updates">
<h4><a href="#generating-delta-updates">Generating delta updates</a></h4>
<p>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
@ -704,6 +703,7 @@ cd ../..</pre>
metadata is needed to make incremental updates work.</p>
</section>
</section>
</section>
<section id="prebuilt-code">
<h2><a href="#prebuilt-code">Prebuilt code</a></h2>
@ -964,9 +964,8 @@ mv android-studio studio</pre>
<section id="compatibility-test-suite">
<h3><a href="#compatibility-test-suite">Compatibility Test Suite</a></h3>
<h4 id="compatibility-test-suite-download">
<a href="#compatibility-test-suite-download">Download</a>
</h4>
<section id="compatibility-test-suite-download">
<h4><a href="#compatibility-test-suite-download">Download</a></h4>
<p>Testing with the Compatibility Test Suite (CTS) can be done by either building the
test suite from source or using the official releases.</p>
@ -996,10 +995,10 @@ 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</pre>
</section>
<h4 id="compatibility-test-suite-setup">
<a href="#compatibility-test-suite-setup">Setup</a>
</h4>
<section id="compatibility-test-suite-setup">
<h4><a href="#compatibility-test-suite-setup">Setup</a></h4>
<p>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
@ -1039,10 +1038,10 @@ rm android-cts-media-1.5.zip</pre>
network</li>
<li>The screen lock must be disabled.</li>
</ul>
</section>
<h4 id="compatibility-test-suite-run-modules">
<a href="#compatibility-test-suite-run-modules">Run modules</a>
</h4>
<section id="compatibility-test-suite-run-modules">
<h4><a href="#compatibility-test-suite-run-modules">Run modules</a></h4>
<p>Run the test harness:</p>
<pre>./android-cts/tools/cts-tradefed</pre>
@ -1058,6 +1057,7 @@ rm android-cts-media-1.5.zip</pre>
the entire test suite.</p>
</section>
</section>
</section>
<section id="obtaining-upstream-manifests">
<h2><a href="#obtaining-upstream-manifests">Obtaining upstream manifests</a></h2>