@wmd It won't negative impact GrapheneOS users since the Advanced Protection feature largely won't be available in GrapheneOS due to not having privileged Google Play services integration. We can provide any of the future useful features tied to it as standalone features. Some of the features will likely be possible to use. It's possible to use their theft protection features automatically locking the device by giving Google Play services basic admin access but we should provide our own.
@GrapheneOS @wmd hi, i am blind, does your OS have a screenreader i can turn on during setup to setup and use the OS? Androids screenreader is Talkback
@wmd @GrapheneOS @J3317 it’s there, but there’s no TTS engine installed out of the box since the Google services don’t come packaged with.
@evilcookies98 @wmd @GrapheneOS ah, can't they just include espeak or something?
@J3317 @GrapheneOS @wmd they could yes, but there’s the issue of finding a version that has direct boot support. If it doesn’t have direct boot support, it’s kind of useless in this scenario anyway. Honestly, I am very strongly pushing for that. I installed it once on my old phone, but sadly had to remove it because play integrity was screwing up my reading app. Now that I don’t need the reading app, I really want it back, but I’m not prepared to handover my phone to someone. I don’t trust to set it up.
@evilcookies98 @GrapheneOS @wmd what is direct boot?
@J3317 @evilcookies98 @GrapheneOS @wmd Direct boot aware apps can run in the time between system boot and first unlock. The app needs to be able to run without an access to (most) of its files, since these are encrypted and need unlocking.
I am not sure what exact implication this has for the usability of screen readers, since I haven't needed one.
@darkyen @evilcookies98 @GrapheneOS oh, thanks for explaining that, so if a tts can't run at boot like most cant, it switches to google TTS, or if you have a Samsung phone Samsung tts when you power on your phone
@J3317 @darkyen @GrapheneOS still though, you're working under the assumption that all of us have someone trustworthy on command to help us set up our phones. Spoiler alerts, we don't. Since there's no way to push an app to the phone at the same time. Things are flashed, we're screwed. I love what you're doing but that is really putting me off of using it. If I can't set up my phone independently, that's a barrier. I don't always have trustworthy people on hand. I would venture a guess that a lot of us don't. I live with at least one Snoop. We're talking someone who would immediately start going through my messages.
@evilcookies98 @darkyen @GrapheneOS same, i just like being able to turn on a screenreader and go
@J3317 @evilcookies98 @darkyen We're not aware of a TTS app we could include right now due to the need for licensing acceptable for inclusion in GrapheneOS and the need for direct boot support. That means either permissive licensing or GPLv2 for both the code AND the language models. We won't use something with non-commercial usage licensing for the language models, etc. We also won't include GPLv3 software in the base OS, although we're fine with redistributing it in our App Store.
@J3317 @evilcookies98 @darkyen We have our open source fork of TalkBack included so all we need is a permissively licensed text-to-speech implementation including the language models (GPLv2 is permissive enough, GPLv3 is not, but we'd prefer MIT / BSD / Apache 2). We'd then need to integrate it so that it's functional by default and add a way to enable TalkBack in our Setup Wizard. We cannot make a TTS implementation ourselves right now, so unless there's a good one we can use, this is blocked.
@GrapheneOS @evilcookies98 @darkyen oh, well as for a way to enable talkback the android shortcut is hold both volume buttons for 3 seconds, as for tts can't you just use espeak? i remember hearing there was a version that supports direct boot but don't know where to get it
@J3317 @evilcookies98 @darkyen No, since it's GPLv3, and we don't include GPLv3 software in GrapheneOS due to overly strict licensing terms. We don't want GrapheneOS to have stricter licensing terms than the Android Open Source Project. We want GrapheneOS to be usable where AOSP is used as a direct replacement for it.
@GrapheneOS @J3317 @evilcookies98 @darkyen ... so then include espeak and distribute a separate build that omits GPLv3 components like espeak for the AOSP drop-in usecase?
@joepie91 @J3317 @evilcookies98 @darkyen There are better options than eSpeak NG with the permissive licensing we neeed. Regardless of the choice of the app to fork, there's work involved in forking it and integrating it to work seamlessly out-of-the-box without requiring any setup. There's further work to add TalkBack integration into Setup Wizard.
We're not to blame for a project choosing licensing which is broadly known to be something many companies want to avoid. That choice limits usage.
@GrapheneOS @J3317 @evilcookies98 @darkyen Better options such as? And didn't you say two posts ago in this thread that "unless there's a good one we can use, this is blocked", implying that there isn't one?
@joepie91 @J3317 @evilcookies98 @darkyen Better options for a starting point existing doesn't mean we can simply drop it into GrapheneOS as a bundled app right now. That also wouldn't solve any problem without changing the app to have everything required built-in and already configured to work from the moment a fresh install is booted. We could then add a shortcut to the setup wizard for enabling TalkBack. It doesn't do any good if the app doesn't have a seamless auto-configured experience.
@joepie91 @J3317 @evilcookies98 @darkyen https://github.com/k2-fsa/sherpa-onnx is an example of a permissively licensed and more modern implementation. We have not reviewed it in depth and far away from being able to bundle a fork of it into the OS. All we know is that it's what many of our users recommend we use when this is brought up.
It also supports speech-to-text in addition to text-to-speech and various other functionality. It's more like Google's speech services app. Doesn't mean it's ready to ship.
@joepie91 @J3317 @evilcookies98 @darkyen If we include this, there are other people who are going to be very angry about it because it's based on neural networks.
https://bsky.app/profile/stopgenai.com/post/3lp2mtrxnec2m
https://bsky.app/profile/stopgenai.com/post/3lp2n6lxgac2m
This is how modern speech-to-text, text-to-speech, translation, automatic captions, etc. are all implemented. If we tied our hands and refused to use anything using neural networks, we wouldn't be realistically ever able to include speech-to-text, translation, captions, etc.
@GrapheneOS @J3317 @evilcookies98 @darkyen There are, to my knowledge, exactly *zero* models in the LLM/GenAI space that are actually open-source by any reasonable definition, and there's good reason to believe that they can't ever be (because this amount of training data is virtually impossible to ethically source), so the idea of this kind of model as an open-source solution is essentially vaporware.
There is already a viable system which can be implemented today, as has been presented to you by someone *who actually uses these accessibility tools*, which is espeak.
@joepie91 @J3317 @evilcookies98 @darkyen
> There is already a viable system which can be implemented today, as has been presented to you by someone *who actually uses these accessibility tools*, which is espeak.
No, a dozen people who depend on text-to-speech to use their devices have told us they cannot possibly get by with eSpeak NG as their text-to-speech implementation. They would use it to get from the start of the setup wizard to installing a proper TTS app. We want a decent feature.
@joepie91 @J3317 @evilcookies98 @darkyen eSpeak NG does not use a license we can use in GrapheneOS. Unless you convince every contributor to the eSpeak NG code to relicense their code as GPLv2 or a more permissive license, we can't use it. GrapheneOS is not going to become more restrictively licensed from AOSP. There are people who actually support our project and help us keep it going who care about this. We're not throwing away a large set of use cases and support for us by including GPLv3.
@GrapheneOS @J3317 @evilcookies98 @darkyen I have literally suggested a solution for this several posts up, that would absolutely work.
"Do not want to do this" is a very different thing from "cannot do this".
@GrapheneOS @J3317 @evilcookies98 @darkyen That is just a lot of words to say "we do not want to do this, we do not think that accessibility is worth doing this".
@GrapheneOS @J3317 @evilcookies98 @darkyen (Which, incidentally, is *exactly* what the original complaint was about.)
@joepie91 @J3317 @evilcookies98 @darkyen You should check back on the article you spread and attacked us over. The person who published it retracted it and apologized to us for approaching it that way. They want to help us integrate and test something that is acceptable for us to ship instead.
The app which multiple people have recommended to us is https://github.com/k2-fsa/sherpa-onnx. We would still need to review it, fork it and integrate it to have a seamless out-of-the-box auto-configured experience.
@GrapheneOS @J3317 @evilcookies98 @darkyen As I have brought up before, that system appears to be based on LLM/GenAI tech and models, which means it cannot ever be open-source.
And what the author of the article decides to do frankly has no bearing on my arguments here. You are still presenting "do not want to do" as "cannot do", which are two very different things.
@GrapheneOS @J3317 @evilcookies98 @darkyen Like, to be clear: depending on circumstances, "we do not think this is worth the cost for the gain we get" *can* sometimes be a reasonable point.
But then be honest about what you're actually saying, take responsibility for your choice, and don't frame it as an impossibility that is out of your hands.
@joepie91 @J3317 @evilcookies98 @darkyen
Proposing building and testing twice as many releases as the solution to anything where we cannot do both things at once in the same builds is something we regularly see about multiple topics including root access. It's not something realistic. It would require an enormous amount of resources.
16 separate 45 minute OS builds followed by a long release signing process and then delta generation from previous releases is already a huge amount to be doing.
@GrapheneOS @J3317 @evilcookies98 @darkyen Once again, this is still just "we do not want to do it", regardless of how justified you feel your reasons for that decision are. But it is not that you *cannot* do it, so don't present it as if it is.
@GrapheneOS @J3317 @joepie91 @darkyen it boils down to this. Either you or User first or your idealism first. User first would be getting this thing rushed because it’s locking people out, not oh that’s not our priority right now. This is not just something you can say we’ll get too later. If you can’t develop for everyone, don’t develop for anyone.
@joepie91 @J3317 @GrapheneOS @darkyen here’s what you’re saying. We don’t want to do this because we’d rather work on the shiny stuff. We don’t care if people are mad at us and get left out and have to potentially expose their personal information to someone. They don’t trust just so long as we can get the shiny stuff done.
@evilcookies98 @joepie91 @J3317 @darkyen We're not working on shiny stuff. We're working on keeping what we have now from substantially degrading. We're primarily working on porting to Android 16 so we can continue providing the latest privacy and security updates for GrapheneOS. We're also trying to fix a bunch of different types of regressions including regressed app compatibility from recently added anti-competitive checks for Play Store installation. We have our hands full not adding more.
@evilcookies98 @joepie91 @J3317 @darkyen What shiny stuff do you think we're adding or working on? When have we ever been focused on things like aesthetics or trivial frills? Our focus is consistently on important things. After Android 16, we also need to get several additional non-DNS-related Android VPN leak fixes we've implemented shipped, which we consider high priority but haven't had time to get fully finished and especially fully tested. Many of our users consider that very critical.
@J3317 @darkyen @joepie91 @GrapheneOS anything that is such a huge priority that it’s worth leaving people literally locked out over is shiny stuff. I tried to be patient with you back in the winter when there was genuinely nothing you could do, but now you can and won’t. We are asking you to bundle an app, not write 10 million lines of code.
@evilcookies98 @J3317 @darkyen @joepie91 You're asking us to significantly change the licensing for GrapheneOS in a way that we've committed to not doing. eSpeak NG would still need significant changes to turn it into what we would need for a seamless experience. There are other apps available and we are not locked into using any particular one. There are at least around 6 options, most permissively licensed, so we're not going to be using the GPLv3 one. We use GPLv3 outside the OS, not in it.
@darkyen @joepie91 @GrapheneOS @J3317 i’ve done some research on this. All you would have to do is put it in the darn package so it would be installed. It doesn’t have to run at the system level. Most of the third-party engines are just regular apps. We installed them, they run. if you can bundle a bunch of fancy stuff that doesn’t even make sense, then you can bundle a TTS engine. You’re ignoring us.
@joepie91 @J3317 @evilcookies98 @darkyen In what sense are the models for RHVoice, etc. open source in a way that these models are not? They're still a form of model with an unclear origin.
@GrapheneOS @J3317 @evilcookies98 @darkyen This was about espeak, not RHVoice; and to my knowledge, espeak is algorithmic in nature and not trained on a massive dubiously sourced set of training data, which means it does not suffer from the same problem.
I have my doubts that this discussion is going to be moving in a productive direction for either of us, so I'll leave you with this comment:
The way you've responded to this situation has damaged your reputation in my eyes *far* more than that article ever could have.
You've yelled at a blind person for expressing their frustration with being excluded, you've threatened pausing development on accessibility entirely (which feels rather "look what you made me do!"), you've repeatedly refused to take responsibility for your decisions by framing them as if they are out of your hands, and you've confirmed the long-standing rumours that you call all criticism "attacks" (which is something I'd remained undecided on until now because I didn't have enough information, but now got to see first-hand).
You yell a lot about how that article has "harmed the project", but if you're concerned about harm to the project, I think that you need to be looking inward instead, at the way you interact with criticism.
@joepie91 @J3317 @evilcookies98 @darkyen
It's clear you've been heavily influenced by attacks on the project and team. If this is your attitude, avoid contacting us.
We haven't yelled at anyone. We were attacked with now retracted false claims, hyperbole and claims that we're cruel because we get things implemented slowly and need to use software meeting our requirements.
GrapheneOS is missing features some people need to use it. That doesn't only apply to blind users. We're working on it.
@joepie91 @J3317 @evilcookies98 @darkyen
Not having features everyone needs to use GrapheneOS despite our ongoing work improving many different areas of usability and accessibility doesn't mean we don't care. It takes us a long time to implement things. We had no network location from 2014 until late 2024. We had no compatibility with apps depending on Google Play until summer 2021. We still have a bunch of legacy AOSP sample apps. We'd have SVOX Pico TTS if it wasn't removed from AOSP.
@J3317 @joepie91 @GrapheneOS @darkyen no one is asking you to build the darn engine from scratch people. There’s an APK already made. I have it. It exists. If you would do your homework, you would know that. Maybe if you don’t have the resources, tell people to quit working on the shiny stuff for a while.
@evilcookies98 @J3317 @joepie91 @darkyen What shiny stuff? We're working on keeping GrapheneOS alive despite having our lead developer forcibly conscripted to fight in a war. Our entire focus has been on Android 16 porting for weeks. The only things we've shipped recently are minor features implemented weeks or months ago which were sitting as open pull requests which hadn't been fully reviewed and tested yet.
We don't even have a real boot animation since our focus is so much on the core OS.
@J3317 @joepie91 @darkyen @GrapheneOS people, get your priorities straight. Locking people out is more important than any shiny update out. There will ever be. How was that so hard to understand? I swear if I knocked on some heads, they would ring Hollow.
@joepie91 @J3317 @evilcookies98 @darkyen No, it's not at all. What we're going to do is review, fork and integrate a permissively licensed text-to-speech and speech-to-text implementation. We're not going to double the amount of builds we have to make, which already takes far too long and has required significant changes to the house where most of the builds are done to accommodate the heat, power usage and network transfers. Doubling the number of releases to build and test is not reasonable.
@joepie91 @J3317 @GrapheneOS @darkyen that’s what I’ve been saying all morning. That would be like turning up your nose in a perfectly good new house because the walls were green and you didn’t like green. Although you could repaint it later, you chose to be stubborn and willful and just totally dismissed the whole thing.
@joepie91 @J3317 @evilcookies98 @darkyen We currently support 16 devices. Building for each device takes around 45 minutes. More importantly, testing each build including the future upgrade path takes a long time. It is not feasible to start making multiple builds of the OS. This is also not the only case where people are suggesting making multiple builds. People also want that for multiple other things. It is not actually a realistic solution. It would take an extreme increase in resources.