Obsolete
Status Update
No update yet.
Comments
kr...@gmail.com
This issue does not reproduce with dev preview 4.
vk...@google.com
vk...@google.com
Closing this issue as per
vk...@google.com
Hello. Can you please elaborate on what the exact functionality that is being asked for? We believe CallScreenService already provides what is being requested.
lb...@gmail.com
@4 There are 3 possible ways to have Caller-ID. Each has its own advantages and disadvantages:
1. Using CallScreeningService class. This is not good because it will let the current default Phone app mine for data that it has. Also it's not good because only a single one can be used at the same time. You can't have multiple caller-ID apps that will find who's the caller.
Another disadvantage is that it's available only from API 24.
That's also why I don't see even a single app that implements it. Data is precious for caller-ID apps, and they won't give it away so easily.
2. Replacing the Phone app. This should work well, but it requires a huge amount of work on implementing the app, and even Google doesn't offer an out-of-the-box repository that all developers can use for making a third party Phone app solution. This prevents mining because the data is shown right on the current app that already has the data for itself, but it doesn't let multiple callerID apps.
Another disadvantage is that most users are cautious about replacing the Phone app, as it's replacing too much for them. If there is a bug on such an app, it can damage the reputation a lot, and cause bad reviews.
Another disadvantage is that it's only from API 23.
Because of these reasons, it's very rare to see caller-ID apps that choose this path, especially not to the fullest, having all that a phone app can do.
3. Having an on-top view (using SAW). This is the most common solution. It has a lot of workarounds to make it work, but it allows users to have multiple caller-id apps, it protects the data of each, and doesn't require so much work.
The drawback is that when a phone call starts, you might see multiple floating views on top of the screen, making it quite annoying to answer the call. Even a single one could be annoying.
Apps can show a notification instead, but then other apps that can read from notifications could mine this data. Also some devices out there (I think of Samsung) don't allow to reach the notification when there is a phone call.
What I request is a solution that merges all of these.
Some sort of widget-like solution, that phone apps could have inside them (thus avoiding on-top floating views), to show the information about the caller (or outgoing call, of course), and that information would be available from multiple caller-id apps if needed and possible.
Each app would have time to get the information, and the user could swipe in a view-Pager between the available information that was gathered from each app. One page for each app. Each page could have various things, but at least those: name, photo, job, company.
You could think of more possible fields, but I think those are the minimal ones.
The only thing the phone app could do, is to set the template for the viewpager pages, meaning where to put each, and the sizes (including of course of the ViewPager itself).
Also, if the phone app tries to get information from this special widget in any way, it will only see black/empty content.
Not sure about supporting older Android versions though. That's the only drawback I see on this request.
1. Using CallScreeningService class. This is not good because it will let the current default Phone app mine for data that it has. Also it's not good because only a single one can be used at the same time. You can't have multiple caller-ID apps that will find who's the caller.
Another disadvantage is that it's available only from API 24.
That's also why I don't see even a single app that implements it. Data is precious for caller-ID apps, and they won't give it away so easily.
2. Replacing the Phone app. This should work well, but it requires a huge amount of work on implementing the app, and even Google doesn't offer an out-of-the-box repository that all developers can use for making a third party Phone app solution. This prevents mining because the data is shown right on the current app that already has the data for itself, but it doesn't let multiple callerID apps.
Another disadvantage is that most users are cautious about replacing the Phone app, as it's replacing too much for them. If there is a bug on such an app, it can damage the reputation a lot, and cause bad reviews.
Another disadvantage is that it's only from API 23.
Because of these reasons, it's very rare to see caller-ID apps that choose this path, especially not to the fullest, having all that a phone app can do.
3. Having an on-top view (using SAW). This is the most common solution. It has a lot of workarounds to make it work, but it allows users to have multiple caller-id apps, it protects the data of each, and doesn't require so much work.
The drawback is that when a phone call starts, you might see multiple floating views on top of the screen, making it quite annoying to answer the call. Even a single one could be annoying.
Apps can show a notification instead, but then other apps that can read from notifications could mine this data. Also some devices out there (I think of Samsung) don't allow to reach the notification when there is a phone call.
What I request is a solution that merges all of these.
Some sort of widget-like solution, that phone apps could have inside them (thus avoiding on-top floating views), to show the information about the caller (or outgoing call, of course), and that information would be available from multiple caller-id apps if needed and possible.
Each app would have time to get the information, and the user could swipe in a view-Pager between the available information that was gathered from each app. One page for each app. Each page could have various things, but at least those: name, photo, job, company.
You could think of more possible fields, but I think those are the minimal ones.
The only thing the phone app could do, is to set the template for the viewpager pages, meaning where to put each, and the sizes (including of course of the ViewPager itself).
Also, if the phone app tries to get information from this special widget in any way, it will only see black/empty content.
Not sure about supporting older Android versions though. That's the only drawback I see on this request.
sa...@google.com
ad...@google.com
We've passed along your input to our internal teams who are evaluating it for a future release. We're closing this issue for now, and thanks for sending us your feedback!
lb...@gmail.com
@6 Please do consider. Could be nice.
Description
But I'd like to add:
This should include both incoming and outgoing calls and also conference calls.
It should be possible to offer it only for calls, for the app that is currently the default Phone app, and it should be possible to offer those queries only for the current phone call. This is in order to avoid mining of data from the app that offers this information, about phones that didn't have a phone call at all.
These additions are because I've read about some alternatives, such as:
and:
Each of those solutions have disadvantages.