diff options
| author | Daniel Micay <danielmicay@gmail.com> | 2022-02-25 09:41:21 -0500 |
|---|---|---|
| committer | Daniel Micay <danielmicay@gmail.com> | 2022-02-25 09:42:39 -0500 |
| commit | 14a075aa18ca61e826984c82bbd917715f81d839 (patch) | |
| tree | a6ad0e242e6e24b657ea0cb4be10a137814a1d07 | |
| parent | d3684966f3e8414cbaab34c34dea69365f4f28ee (diff) | |
update sandboxed Google Play limitation docs
| -rw-r--r-- | static/usage.html | 30 |
1 files changed, 22 insertions, 8 deletions
diff --git a/static/usage.html b/static/usage.html index 3a5f5b08..b10945ea 100644 --- a/static/usage.html +++ b/static/usage.html @@ -918,14 +918,28 @@ <section id="sandboxed-google-play-limitations"> <h3><a href="#sandboxed-google-play-limitations">Limitations</a></h3> - <p>Functionality depending on privileged access such as special access to - hardware isn't available. We would need to implement compatibility layers - teaching it how to function as a regular app. This currently isn't within the - scope of the project beyond the existing support for dynamite modules and - partially implemented support for Play Store app installation/updates. The - official Android Auto interface is a good example of functionality heavily - depending on having highly invasive privileged access beyond what would be - realistic to get working with an expanded compatibility layer.</p> + <p>Our compatibility layer has to be expanded on a case-by-case basis to teach + Play services to work as a regular app without any of the invasive the access + and integration it expects. In many cases, it doesn't truly need the access or + we can teach it to use the regular approach available to a normal app. In some + cases, the functionality it offers fundamentally requiresy requires privileged + access and cannot be support. For example, it's unlikely Android Auto will be + supported. The same applies to other highly invasive OS integration / control + or privileged access to hardware. There are also a lot of features such as the + FIDO2 security key support which could be made to fully work despite reliance + on a lot of privileged APIs (their FIDO2 service is partially working + already). In the case of FIDO2, we could also eventually support redirecting + to our own implementation similarly to how we do that by default for + geolocation. Our compatibility layer is a very actively developed work in + progress and most of the remaining unavailable functionality is quickly + becoming supported.</p> + + <p>Functionality depending on the OS integrating Play services and using it as + a backend is unavailable. An OS integrating Play uses it as the backend for OS + services such as geolocation. GrapheneOS never uses it as the backend/provider + for OS services. In cases such as text-to-speech (TTS) where the OS allows the + user to choose the provider, Play services can often be used. It's on a level + playing field with other apps on GrapheneOS.</p> <p>Play Store assumes that uninstallation always succeeds so it will stall if it tries to uninstall an app and you reject it. You can work around this by |
