zlacker

[parent] [thread] 2 comments
1. strcat+(OP)[view] [source] 2025-04-13 05:48:37
In general, we do not reduce app compatibility by removing any useful features. Our privacy improvements are implemented in a compatible way, like Contact Scopes pretending to be the Contacts permission having been granted but users choose which contacts can be seen and which data for those is visible. The only issues with app compatibility by default are due to app bugs including apps having bugs uncovered by exploit protection features. We have toggles to work around that including a simple per-app exploit protection compatibility mode changing the values of the finer grained ones. There are also a tiny subset of apps banning using a non-Google-certified OS, which are mainly a small subset of banking apps. We do have opt-in features which reduce compatibility with non-buggy apps, but they're all opt-in, such as the Dynamic Code Loading and native debugging restrictions.

GrapheneOS includes a fork of the open source TalkBack. You need a text-to-speech implementation such as Google's Speech Recognition & Synthesis, RHVoice or eSpeak NG too. None of those is suitable for inclusion in GrapheneOS due to licensing and other reasons. There are some promising new apps based on more modern approaches which we're keeping an eye on. We may make our own text-to-speech and speech-to-text similarly. We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. The same thing is probably needed for TTS and the other direction.

You can install Google's Android Accessibility Suite for the full proprietary feature set including extended TalkBack features. It works fine on GrapheneOS. It needs sandboxed Google Play for the full feature set.

replies(2): >>gostsa+7O >>Aachen+nK2
2. gostsa+7O[view] [source] 2025-04-13 15:31:41
>>strcat+(OP)
thanks, this was one of my main unknowns about the alternative oses.
3. Aachen+nK2[view] [source] 2025-04-14 13:19:33
>>strcat+(OP)
> We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support.

Why build your own instead of working with BeaconDB? Or if you predate that project, vice versa: will this be an open dataset that other projects can use and contribute back to?

I tried looking up more info about it but DDG only comes up with forum threads about workarounds

[go to top]