initial layer of explicit sections for build guide

This commit is contained in:
Daniel Micay 2020-12-06 13:02:36 -05:00
parent d9f57a84b0
commit b67a21664a

View File

@ -121,9 +121,8 @@
</ul>
</nav>
<h2 id="building-grapheneos">
<a href="#building-grapheneos">Building GrapheneOS</a>
</h2>
<section id="building-grapheneos">
<h2><a href="#building-grapheneos">Building GrapheneOS</a></h2>
<h3 id="build-targets">
<a href="#build-targets">Build targets</a>
@ -704,10 +703,10 @@ cd ../..</pre>
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.</p>
</section>
<h2 id="prebuilt-code">
<a href="#prebuilt-code">Prebuilt code</a>
</h2>
<section id="prebuilt-code">
<h2><a href="#prebuilt-code">Prebuilt code</a></h2>
<p>Like the Android Open Source Project, GrapheneOS contains some code that's built
separately and then bundled into the source tree as binaries. This section will be
@ -801,10 +800,10 @@ 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
no modifications made to it.</p>
</section>
<h2 id="update-server">
<a href="#update-server">Update server</a>
</h2>
<section id="update-server">
<h2><a href="#update-server">Update server</a></h2>
<p>GrapheneOS uses a static web server as the update server. The release signing
script generates the necessary metadata alongside the release files. You simply need
@ -845,10 +844,10 @@ $DEVICE-stable</pre>
The update client will check for the presence of a delta update from the current
version on the device to the newer release in the selected release channel. There is
no additional metadata to include alongside the delta update package.</p>
</section>
<h2 id="stable-release-manifest">
<a href="#stable-release-manifest">Stable release manifest</a>
</h2>
<section id="stable-release-manifest">
<h2><a href="#stable-release-manifest">Stable release manifest</a></h2>
<p>Manifests for stable releases are generated with <code>repo manifest -r</code>
after tagging the release across all the repositories in a temporary branch and
@ -858,10 +857,10 @@ $DEVICE-stable</pre>
repository. This also means the whole release can be verified using the GrapheneOS
signing key despite referencing many upstream repositories that are not forked by the
GrapheneOS project.</p>
</section>
<h2 id="standalone-sdk">
<a href="#standalone-sdk">Standalone SDK</a>
</h2>
<section id="standalone-sdk">
<h2><a href="#standalone-sdk">Standalone SDK</a></h2>
<p>It can be useful to set up a standalone installation of the SDK separate from
the Android Open Source Project tree. This is how the prebuilt apps are built, rather
@ -924,10 +923,10 @@ export PATH="$HOME/android/sdk/cmdline-tools/latest/bin:$PATH"</pre>
<p>You should update the sdk before use from this point onwards:</p>
<pre>sdkmanager --update</pre>
</section>
<h2 id="android-studio">
<a href="#android-studio">Android Studio</a>
</h2>
<section id="android-studio">
<h2><a href="#android-studio">Android Studio</a></h2>
<p>You can install Android Studio alongside the standalone SDK and it will detect it
via the <code>ANDROID_HOME</code> environment variable rather than installing another
@ -945,10 +944,10 @@ mv android-studio studio</pre>
<pre>export PATH="$HOME/android/studio/bin:$PATH"</pre>
<p>You can start it with <code>studio.sh</code>.</p>
</section>
<h2 id="testing">
<a href="#testing">Testing</a>
</h2>
<section id="testing">
<h2><a href="#testing">Testing</a></h2>
<p>This section will be expanded to cover various test suites and testing procedures
rather than only the current very minimal coverage of the Compatibility Test Suite
@ -1058,10 +1057,10 @@ rm android-cts-media-1.5.zip</pre>
<p>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.</p>
</section>
<h2 id="obtaining-upstream-manifests">
<a href="#obtaining-upstream-manifests">Obtaining upstream manifests</a>
</h2>
<section id="obtaining-upstream-manifests">
<h2><a href="#obtaining-upstream-manifests">Obtaining upstream manifests</a></h2>
<p>The Android Open Source Project has branches and/or tags for the releases of many
different components. There are tags and/or branches for the OS, device kernels,
@ -1094,10 +1093,10 @@ rm android-cts-media-1.5.zip</pre>
<p>As another kind of example, <code>prebuilts/clang</code>,
<code>prebuilts/build-tools</code>, etc. have a manifest file committed alongside the
prebuilts. Other AOSP toolchain prebuilts reference a build number.</p>
</section>
<h2 id="development-guidelines">
<a href="#development-guidelines">Development guidelines</a>
</h2>
<section id="development-guidelines">
<h2><a href="#development-guidelines">Development guidelines</a></h2>
<h3 id="programming-languages">
<a href="#programming-languages">Programming languages</a>
@ -1269,6 +1268,7 @@ rm android-cts-media-1.5.zip</pre>
if it truly makes the correct approach simpler. Ignore fads and figure out if it
actually makes sense to use, otherwise just stick to the old fashioned way if the
fancy alternatives aren't genuinely better.</p>
</section>
</main>
<footer>
<a href="/"><img src="/logo.png" width="512" height="512" alt=""/>GrapheneOS</a>