Infeasible
Status Update
Comments
ja...@google.com <ja...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit 016fab7f37837deb6e0924730ed70b81042c36db
Author: Elif Bilgin <elifbilgin@google.com>
Date: Tue Jan 25 15:16:26 2022
Converting `query interceptor` related files in `room-runtime` from Java to Kotlin.
Test: N/A
Bug: 206859668
Relnote: Converting `query` related files in `room-runtime` from Java to Kotlin.
Change-Id: I92b932b1a1037c68195140ffb038f8add17d8de4
M room/room-runtime/src/main/java/androidx/room/RoomDatabase.java
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorStatement.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorOpenHelperFactory.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorOpenHelper.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorProgram.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorDatabase.kt
https://android-review.googlesource.com/1960726
Branch: androidx-main
commit 016fab7f37837deb6e0924730ed70b81042c36db
Author: Elif Bilgin <elifbilgin@google.com>
Date: Tue Jan 25 15:16:26 2022
Converting `query interceptor` related files in `room-runtime` from Java to Kotlin.
Test: N/A
Bug: 206859668
Relnote: Converting `query` related files in `room-runtime` from Java to Kotlin.
Change-Id: I92b932b1a1037c68195140ffb038f8add17d8de4
M room/room-runtime/src/main/java/androidx/room/RoomDatabase.java
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorStatement.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorOpenHelperFactory.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorOpenHelper.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorProgram.kt
M room/room-runtime/src/main/java/androidx/room/QueryInterceptorDatabase.kt
ja...@google.com <ja...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
commit 049d12d74b775c193e641a3fd11fb4b3c5c20dc6
Author: Elif Bilgin <elifbilgin@google.com>
Date: Tue Jan 25 15:37:31 2022
Converting `paging` related files in `room-runtime` from Java to Kotlin.
Test: LimitOffsetDataSourceTest.java
Bug: 206859668
Relnote: Converting `paging` related files in `room-runtime` from Java to Kotlin.
Change-Id: I82fc81469540315dbe4865ccde68396a4339dfd9
M room/room-runtime/api/restricted_current.txt
M room/room-runtime/src/main/java/androidx/room/paging/LimitOffsetDataSource.kt
M room/room-runtime/api/restricted_current.ignore
M room/room-runtime/build.gradle
https://android-review.googlesource.com/1960734
Branch: androidx-main
commit 049d12d74b775c193e641a3fd11fb4b3c5c20dc6
Author: Elif Bilgin <elifbilgin@google.com>
Date: Tue Jan 25 15:37:31 2022
Converting `paging` related files in `room-runtime` from Java to Kotlin.
Test: LimitOffsetDataSourceTest.java
Bug: 206859668
Relnote: Converting `paging` related files in `room-runtime` from Java to Kotlin.
Change-Id: I82fc81469540315dbe4865ccde68396a4339dfd9
M room/room-runtime/api/restricted_current.txt
M room/room-runtime/src/main/java/androidx/room/paging/LimitOffsetDataSource.kt
M room/room-runtime/api/restricted_current.ignore
M room/room-runtime/build.gradle
Description
This feature request would aim to standardize the way Android handles voice calls, video calls and messaging by decoupling them from their backend network.
The challenge:
There are many different video, audio and messaging apps on the market, all have their own branding, settings and way of interaction with us, which makes it unnecessarily complicated. It's also often not trivial to know who is available on which network.
The proposed solution:
The general idea would be to introduce an API that allows applications to act as a source or a sink (or both) for calls and messages.
The signal processing architecture could be similar to GNU Radio's framework. There would be sources and sinks, connected by routes.
Source:
Your friend calling you (a voice call initiated by another user on your mobile network) would be defined as a voice call source, and an incoming Viber, Whatsapp, Facebook, Duo etc. voice call would be also handled as a voice call source.
They would optionally have some metadata about the caller, the costs if there is any, signal quality, latency, GPS coordinates, velocity, temperature, etc.
Sink:
There would be a default voice call, video call and messages app to receive the calls and messages, like let's say the current Phone app, Duo app and Hangouts app.
The user could define in these apps the ring tone, skin, volume, etc. and it would be applied to all networks/vendors.
Routing:
The user could define how they prefer to handle phone calls, text messages in the Android system settings' routing options.
It's possible that someone would prefer the default Phone app for all voice calls, but Duo for all video calls (even if that is coming from Facebook's network).
Module: (optional)
Signal processing module to modify a audio/video/text stream between the source(s) and the sink(s).
Benefits for the vendors:
* Implementing this routing API would be optional, probably premium feature for the well-known companies (like Viber, Signal, Facebook, Skype, etc.), because they could not force their ads/stickers on users with their current Android clients. The backend service and the UI would be decoupled, so they would be motivated to compete to create the best UI for voice/video/messages and separately still compete to provide the best network for voice/video communication.
* Some (new) vendors on the market could highly optimize their app to make user interactions better for people with disabilities or for other niche cases.
* The already existing voice recognition, Snapchat-like video effects and DSP apps/modules could be sold separately as plugins in this routing system.
Benefits for the users:
* There would be a unified user experience on all the different communication networks.
* When we want to reach a friend, we would see all the platforms she is currently available on, and we could select the preferred platform and the way (video, audio, text) to reach her. For example, we could have priorities set in a way that if we tap on her name in our contacts: 1, we call her with video if we are on wifi 2, call her (for free) using a voice over IP service if we are on 4G and she is also online 3, and finally call her on mobile if we have no other choice.
* There would be no need to change settings in every app if someone wants to change the ringtone, or wants to change their status.
* If we permit it, apps/bots/AI could act as a (text) source that looked like a normal message (like admin bots on Discord or IRC).
* Bots/AI could easily react on events like phone calls/text messages.
* Google Assistant could join our conversations and we could ask it to look something up for us.
* Multiple sinks could join the same audio or video call, so if you attached a voice recognition engine to the call, it would generate subtitles for the call, which would greatly benefit the hearing impaired person.
* It would be possible to choose a different phone app to receive video or phone calls.
* The user could set its state to busy on all networks while he is in a phone call on mobile/Duo/Facebook/etc., but still receive silent/vibrating notification about another call during the ongoing call, or switch to it if it's important.
* The system would be totally transparent for the users; they would be able to check the router any time to know what communication is accessible by what application(s)/module(s).
* The user could insert DSP (digital signal processing) modules to make the sound/video better with post-processing.
* With some sophisticated modules and configuration, we could decide to forward some calls to another number/extension just like the modern telephone routing systems do.
* Logging and generating usage statistics would be much easier for all supported platforms.
* If you were in a video call, it would be easier to show your friend a YouTube video or your screen because both could act as another video source temporarily routed into your call.
* Conference calls would be possible even if the participants are reachable on different networks.
* Sooner than later we could have close-to-real-time translation services. If we inserted them into the routing, we could have conferences with multiple nationatilities while everyone is speaking and hearing only their native language.
* Filters for kids could be implemented where only the known phone numbers start to ring; and swearing, bullying, hate speech is filtered in all chats.
* Two recorder apps (like a car dashcam and Mapillary client) could use the same video source without any issues.
* Advanced emergency services could receive real-time video stream from us (including our GPS coordinates) if both we and they are in a situation where it's feasable, otherwise a normal call would be executed.
What do you think?
Kind Regards,
Andras