Alternative dialers & messaging apps have no reason to have access to each other's data.
Proper factorization would be requesting a QR scan and having a system service do it.
-
-
This is essentially what spawning the zxing barcode scanner app does. If the stock OS had to bundle QR code scanning support in the Camera app, it could work without needing the zxing app. We didn't see an advantage to using zxing vs. requesting Camera ourselves + better UI.
-
The zxing app / libraries used to be an official Google project and they could have polished it up and put it into AOSP as a standard OS feature and required it for the OS camera app. Not sure why they let it bitrot as a near dead now independent project instead. *shrug*
-
Seems like Android 9.0 will have some kind of standard QR support but that might simply be as part of Play Services like so many other useful libraries are now, which is no use to us...
-
Time to get around to implementing fake Play Services...
-
Yeah, it's really hard to implement some parts of it like the computer vision parts with OCR, detection of different object types, etc. The easy parts are either stubbing out actual server-based services or making real clients to them like microG does for GCM, etc.
-
Also there's the VR / AR stuff now and maybe that will end up being important to people in the future. A large amount of that is open source in AOSP but there's a lot of fancy stuff that isn't. Maybe AR will become a killer feature for people, who knows.
-
We think of a lot of the research / work that we do as simply figuring out how to do things properly for some saner future system... but app layer is probably going to be needed in practice for a long time to use existing apps. Fancy new microkernel is easy vs. new app ecosystem.
-
I don't think ux for integrating legacy apps is that hard. When installing give user simple control (2-3 choices) for "do you want it to integrate with other apps?"
- 11 more replies
New conversation -
-
-
If you want to allow more power, let app provide custom code to run in full seccomp processing camera stream with small-N byte limit to send back when done.
-
Agree, and the situation is that these existing operating systems / APIs with massive app ecosystems are here and they need to be slowly moved towards approaches like that via incredibly painful ecosystem-wide breaking changes with each major release.
-
Fully expect that stuff like persistent, bulk access to pictures, etc. gets mostly or entirely phased out. It's a painful, long process. Google eventually implements a fair number of the things that we implemented earlier and never expected them to provide any time soon.
-
It's a lot harder for them to do a lot of the things we decide are good ideas and implement downstream. Sometimes they make features for us and don't deploy them, like legacy app permissions review (we don't grant those at install time and we don't silently disable by default).
-
Permissions review == when you first run a legacy (API <= 22, i.e. not updated for post-5.x era APIs) app, you're shown toggles for all the permissions instead of them being enabled by default. It's a standard AOSP feature, not something we made. We only made some tweaks to it.
-
Earlier, we offered an opt-in option to disable permissions for legacy apps by default, but that wasn't very usable at all. Certainly not usable enough for us to enable it by default, and not enabled by default effectively means useless since few people will actually use it.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.