reorder sections
This commit is contained in:
parent
09a4fd4f89
commit
d981e60c2f
@ -95,24 +95,6 @@
|
|||||||
<p>Official releases are available on the <a href="/releases">releases page</a> and
|
<p>Official releases are available on the <a href="/releases">releases page</a> and
|
||||||
installation instructions are on the <a href="/install">install page</a>.</p>
|
installation instructions are on the <a href="/install">install page</a>.</p>
|
||||||
|
|
||||||
<section id="upstream">
|
|
||||||
<h2><a href="#upstream">Upstream contributions</a></h2>
|
|
||||||
|
|
||||||
<p>GrapheneOS has made substantial contributions to the privacy and security of the
|
|
||||||
Android Open Source Project, along with contributions to the Linux kernel, LLVM,
|
|
||||||
OpenBSD and other projects. Much of our past work is no longer part of the downstream
|
|
||||||
GrapheneOS project because we've successfully landed many patches upstream. We've had
|
|
||||||
even more success with making suggestions and participating in design discussions to
|
|
||||||
steer things in the direction we want. Many upstream changes in AOSP such as removing
|
|
||||||
app access to low-level process, network, timing and profiling information originated
|
|
||||||
in the GrapheneOS project. The needs of the upstream projects are often different from
|
|
||||||
ours, so they'll often reimplement the features in a more flexible way. We've almost
|
|
||||||
always been able to move to using the upstream features and even when we still need
|
|
||||||
our own implementation it helps to have the concepts/restrictions considered by the
|
|
||||||
upstream project and apps needing to be compatible with it. Getting features upstream
|
|
||||||
often leads to an improved user experience and app compatibility.</p>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="never-google-services">
|
<section id="never-google-services">
|
||||||
<h2><a href="#never-google-services">No Google apps or services</a></h2>
|
<h2><a href="#never-google-services">No Google apps or services</a></h2>
|
||||||
|
|
||||||
@ -202,6 +184,24 @@
|
|||||||
particular sponsor or company.</p>
|
particular sponsor or company.</p>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
<section id="upstream">
|
||||||
|
<h2><a href="#upstream">Upstream contributions</a></h2>
|
||||||
|
|
||||||
|
<p>GrapheneOS has made substantial contributions to the privacy and security of the
|
||||||
|
Android Open Source Project, along with contributions to the Linux kernel, LLVM,
|
||||||
|
OpenBSD and other projects. Much of our past work is no longer part of the downstream
|
||||||
|
GrapheneOS project because we've successfully landed many patches upstream. We've had
|
||||||
|
even more success with making suggestions and participating in design discussions to
|
||||||
|
steer things in the direction we want. Many upstream changes in AOSP such as removing
|
||||||
|
app access to low-level process, network, timing and profiling information originated
|
||||||
|
in the GrapheneOS project. The needs of the upstream projects are often different from
|
||||||
|
ours, so they'll often reimplement the features in a more flexible way. We've almost
|
||||||
|
always been able to move to using the upstream features and even when we still need
|
||||||
|
our own implementation it helps to have the concepts/restrictions considered by the
|
||||||
|
upstream project and apps needing to be compatible with it. Getting features upstream
|
||||||
|
often leads to an improved user experience and app compatibility.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id="copyright-and-licensing">
|
<section id="copyright-and-licensing">
|
||||||
<h2><a href="#copyright-and-licensing">Copyright and licensing</a></h2>
|
<h2><a href="#copyright-and-licensing">Copyright and licensing</a></h2>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user