I'm currently leaning towards looking at having a separate always on device, since really my usecase is just while driving so I could have a specific device (e.g. using a raspberry pi or something) just installed in my car which then communicates with an app on the phone over bluetooth.
Ppythoner6
- Dec 16, 2022
- Joined Dec 13, 2022
I feel like one of the big things missing for me in graphene right now is the ability to interact via voice (e.g. while driving). I've been looking into what it would take to get something working, but I'm beginning to think that it might be a much harder task than I was thinking it might be. Even assuming I was able to piece together some things to do text to speech to text and natural language processing, it seems like hotword detection (at least in an efficient manner) might be an issue. For one finding much documentation about how voice interaction works in android has been very difficult, but more importantly I have run into what seem to be two roadblocks. The first is that it seems all of the hotword related facilities are now a "system api" and to my understanding therefore only available to privileged system apps, which would require them to be signed by the same key as graphene which obviously I don't have unless I build graphene myself (and then I wouldn't get the automatic updates). The second is that I don't know if there's any documentation about how to create a model for the AlwaysOnHotwordDetection to use - which I assume might be hardware dependent since the aosp code just says things like
A KeyphraseSoundModel is a specialized {@link SoundModel} for key phrases. It contains data needed by the hardware to detect a certain number of key phrases and the list of corresponding {@link Keyphrase} descriptors.
Maybe this is just going to be a dead end, but I was wondering if anyone has done any digging into what it would take to get hardware supported hotword detection working on graphene.I can't say I fully understand exactly how things are sandboxed so maybe the profile isn't too necessary from that perspective. However the main thing is that it lets me have a second copy of apps (signed into different accounts), and be more sure I'm not accidentally giving permissions I didn't mean to. E.g. if I accidentally give permissions to see contacts, in the work profile I don't have any contacts.
- Edited
As much as I want to like user profiles, they have some glaring inconveniences that would be problematic at least for me. The first is notifications - while there is now notification forwarding, it seems to never show notification content, even if the content would be available on the lock screen. Switching between user profiles is also a big pain requiring many extra interactions (swipe down to get the notification tray, swipe down again, tap to pull up the set of user profiles, tap on the one I want, and then wait several seconds for the fingerprint sensor to wake up, or type in the passcode). Finally, with work profiles you can e.g. be on a call in discord in the main profile, while using an app from the work profile at the same time; as far as I understand it, this isn't possible with user profiles. For my usecases these inconveniences make user profiles just really not work. Are there any ways in which these pain points might be addressed in the future?