WAI
Status Update
No update yet.
Comments
ad...@google.com
We have passed this to the development team and will update this issue with more information as it becomes available.
lb...@gmail.com
@2 Thank you.
BTW, trying to have a workaround of ContentObserver of call-logs won't help, because it gets updated only after the call has finished.
BTW, trying to have a workaround of ContentObserver of call-logs won't help, because it gets updated only after the call has finished.
lb...@gmail.com
Attached sample project to show the issue.
When you call someone, you will get something like that in the logs :
android.intent.action.NEW_OUTGOING_CALL null null
android.intent.action.PHONE_STATE OFFHOOK someNumber
Where "someNumber" is the phone number, and the time difference between them is very very short.
When you call someone, you will get something like that in the logs :
android.intent.action.NEW_OUTGOING_CALL null null
android.intent.action.PHONE_STATE OFFHOOK someNumber
Where "someNumber" is the phone number, and the time difference between them is very very short.
tg...@google.com
Hello, I'd appreciate if you could explain your use-case. Ideally we'd like to have developers NOT rely on the PHONE_STATE broadcast going forward and instead provide better APIs to handle specific use-cases in a more controlled and reliable manner.
lb...@gmail.com
@5 Why not?
How else would you have apps respond to call events?
CallerID apps? Call recording apps? Call tasks? Call reminders ? Caller enhancers? Different UI for call screen ?
And the list goes on...
Please stop removing APIs. It's ruining the platform, breaking apps, and drastically reducing the potential of apps.
You already ruined so many things because of this: Proper Sd-card support, proper shortcuts creation, File Uri sharing, ...
I even read that accessibility apps might be removed if they are not only for disabled people. Haven't seen it occur yet, but read about it. I really hope this isn't true.
Anyway, I work in a company that handles phone calls as they occur, telling the user who the person is, even if they are not in the address book, and can show the photo of this person in some cases.
Recently I was tasked to also support call recording feature, when possible.
Sadly this field is very buggy and fragmented on Android, seeing multiple devices and Android versions work in different ways.
I really wish Android would have a solid API that would allow recording calls. It's legal in many countries and it helps multiple professions: lawyers, businessmen, ... even the simple people who call for services and need the call be recorded.
Even the most advanced recording app that I've found (here:https://play.google.com/store/apps/details?id=com.boldbeast.recorder&hl=en ) doesn't work on all devices, and requires root on some cases which even then might not work.
Somehow they managed to overcome what I've written here, of being notified when the call is answered in outgoing calls. But I haven't figured it out, so I've written about it here:
https://stackoverflow.com/q/50926025/878126
How else would you have apps respond to call events?
CallerID apps? Call recording apps? Call tasks? Call reminders ? Caller enhancers? Different UI for call screen ?
And the list goes on...
Please stop removing APIs. It's ruining the platform, breaking apps, and drastically reducing the potential of apps.
You already ruined so many things because of this: Proper Sd-card support, proper shortcuts creation, File Uri sharing, ...
I even read that accessibility apps might be removed if they are not only for disabled people. Haven't seen it occur yet, but read about it. I really hope this isn't true.
Anyway, I work in a company that handles phone calls as they occur, telling the user who the person is, even if they are not in the address book, and can show the photo of this person in some cases.
Recently I was tasked to also support call recording feature, when possible.
Sadly this field is very buggy and fragmented on Android, seeing multiple devices and Android versions work in different ways.
I really wish Android would have a solid API that would allow recording calls. It's legal in many countries and it helps multiple professions: lawyers, businessmen, ... even the simple people who call for services and need the call be recorded.
Even the most advanced recording app that I've found (here:
Somehow they managed to overcome what I've written here, of being notified when the call is answered in outgoing calls. But I haven't figured it out, so I've written about it here:
tg...@google.com
Hello,
As stated in the latter part of my response in
Waking up countless background apps to notify them of phone state changes ultimately slows down the user's device and makes for a poor user experience. PHONE_STATE is also poorly suited to use cases like call screening apps since broadcasts are not guaranteed to arrive in time for an app to perform a particular action; e.g. think of a call screening app which wants to reject a call; it may have already started ringing.
As you stated on
Your use case of a caller ID app fits well into the category of what I would consider a "call screening and identification app". Its a perfectly valid use case, and its one we intend to support more directly through new APIs.
In terms of being able to more closely monitor the state of calls, an extension of the existing InCallService API sounds like a better solution. That API already supports detailed reporting of call states, including when a dialing call transitions to an ACTIVE state.
Call recording is a whole other use case itself; its something we want to support, but I can't give any timelines on this.
As stated in the latter part of my response in
Waking up countless background apps to notify them of phone state changes ultimately slows down the user's device and makes for a poor user experience. PHONE_STATE is also poorly suited to use cases like call screening apps since broadcasts are not guaranteed to arrive in time for an app to perform a particular action; e.g. think of a call screening app which wants to reject a call; it may have already started ringing.
As you stated on
Your use case of a caller ID app fits well into the category of what I would consider a "call screening and identification app". Its a perfectly valid use case, and its one we intend to support more directly through new APIs.
In terms of being able to more closely monitor the state of calls, an extension of the existing InCallService API sounds like a better solution. That API already supports detailed reporting of call states, including when a dialing call transitions to an ACTIVE state.
Call recording is a whole other use case itself; its something we want to support, but I can't give any timelines on this.
lb...@gmail.com
@7 I have to disagree with a lot of what you wrote :
"the intention is to provide better APIs which are targeted to specific use-cases. "
- As I wrote, there are countless of apps that depend on this, and hurting them is bad. It's bad for developers and for users.
"Waking up countless background apps to notify them of phone state changes ultimately slows down the user's device"
- And how will adding a new useless Intent call help here? Why duplicate the call to this Intent? It doesn't make sense.
"PHONE_STATE is also poorly suited to use cases like call screening apps since broadcasts are not guaranteed to arrive in time for an app to perform a particular action"
- Incorrect. It's the best thing that Android can offer currently, letting all apps that need it to use it.
"this field is very buggy and fragmented on Android"
This I wrote about call recording. Not about PHONE_STATE. The new behavior makes it worse, though. There is absouloutly no reason for duplicate Intent call. Really.
"its one we intend to support more directly through new APIs"
I really hope you won't make it worse or too restricted, like you did in so many cases : SD card (limited and ugly API of SAF, instead of the perfectly working File API), creating shortcuts (replaced with very limited API of pinned shortcuts, without backward compatibility) , global Intents (which made me put a foreground service just because of it, instead of just broadcastReceiver) , getting current foreground Activity (almost impossible unless maybe using accessibility) , getting app size (need storage permission for some reason), never ending battle vs background processing (leaving only foreground service to be safe to use),...
"an extension of the existing InCallService API"
- Never heard of it, but reading it now doesn't seem like a good one at all. Only one can be active, and it also has to be the "default phone app". Doesn't make sense if the app only needs to show call information.
Users should have a choice.
"Call recording is a whole other use case itself; its something we want to support, but I can't give any timelines on this."
I've longed wanted this to be in Android built in. Even Chinese OEMs did it before Google. What's so hard about it? Only legal stuff? Can't you handle it the same as you handle other situations?
How about making it responsibility of the user, and by default, have a behavior that fits current country, while having fallback of the global laws, that will fit all countries.
Can you please explain to me why the need of this change, of sending duplicate Intents, when one with the current phone number was enough?
Why now we get 2 Intents for each event, while the first one is useless?
Because of this, there is no way to differentiate between them well. That's why I requested that if that's intended and here to stay, at least provide us a way to differentiate between them, so that we will ignore the one that can't help.
"the intention is to provide better APIs which are targeted to specific use-cases. "
- As I wrote, there are countless of apps that depend on this, and hurting them is bad. It's bad for developers and for users.
"Waking up countless background apps to notify them of phone state changes ultimately slows down the user's device"
- And how will adding a new useless Intent call help here? Why duplicate the call to this Intent? It doesn't make sense.
"PHONE_STATE is also poorly suited to use cases like call screening apps since broadcasts are not guaranteed to arrive in time for an app to perform a particular action"
- Incorrect. It's the best thing that Android can offer currently, letting all apps that need it to use it.
"this field is very buggy and fragmented on Android"
This I wrote about call recording. Not about PHONE_STATE. The new behavior makes it worse, though. There is absouloutly no reason for duplicate Intent call. Really.
"its one we intend to support more directly through new APIs"
I really hope you won't make it worse or too restricted, like you did in so many cases : SD card (limited and ugly API of SAF, instead of the perfectly working File API), creating shortcuts (replaced with very limited API of pinned shortcuts, without backward compatibility) , global Intents (which made me put a foreground service just because of it, instead of just broadcastReceiver) , getting current foreground Activity (almost impossible unless maybe using accessibility) , getting app size (need storage permission for some reason), never ending battle vs background processing (leaving only foreground service to be safe to use),...
"an extension of the existing InCallService API"
- Never heard of it, but reading it now doesn't seem like a good one at all. Only one can be active, and it also has to be the "default phone app". Doesn't make sense if the app only needs to show call information.
Users should have a choice.
"Call recording is a whole other use case itself; its something we want to support, but I can't give any timelines on this."
I've longed wanted this to be in Android built in. Even Chinese OEMs did it before Google. What's so hard about it? Only legal stuff? Can't you handle it the same as you handle other situations?
How about making it responsibility of the user, and by default, have a behavior that fits current country, while having fallback of the global laws, that will fit all countries.
Can you please explain to me why the need of this change, of sending duplicate Intents, when one with the current phone number was enough?
Why now we get 2 Intents for each event, while the first one is useless?
Because of this, there is no way to differentiate between them well. That's why I requested that if that's intended and here to stay, at least provide us a way to differentiate between them, so that we will ignore the one that can't help.
lb...@gmail.com
Using InCallService seem like a very bad choice for this. It requires a lot more than just monitoring calls. It requires to be the default dialer.
Not all users will like this.
Not all users will like this.
ni...@gmail.com
I agree with #9. It would be much cleaner and easier to have another way of accessing it . Less intrusive to user .
I also strongly agree that call recording api permission should be left to user. Just like Screen Recording.
I also strongly agree that call recording api permission should be left to user. Just like Screen Recording.
ke...@gmail.com
@8
just some note for "never ending battle vs background processing"
Please use Chinese apps for some time, we don't even think current implementation could possibily enough, since they have already been abusing foreground service for several years.
just some note for "never ending battle vs background processing"
Please use Chinese apps for some time, we don't even think current implementation could possibily enough, since they have already been abusing foreground service for several years.
lb...@gmail.com
@11 "abusing foreground service"
You mean background?
I ask because foreground is still ok.
I don't know about Chinese apps, but it's not a new thing that there are apps that abuse what's possible on Android.
But there are also apps that use what's possible on Android for good reasons.
For example, this cool app that so many users like (I don't use it, but I think it's cool) :
https://play.google.com/store/apps/details?id=mobi.drupe.app&hl=en
It has a small on-top view that allows the user to access it for contacting people.
I don't know how they made it work for so long without disappearing, but the more Google restricts background apps, the more I think they will have to put a foreground service.
And now Google has made it impossible to hide notifications of foreground apps right from the notification drawer (still at least possible from other settings screen) :
https://issuetracker.google.com/issues/79640835
And it was replaced with 2 useless buttons instead:
https://issuetracker.google.com/issues/110237818
Users don't like to get reminded that the app is running in the background. When they see this notification, even if the app doesn't do anything in 99.9999% of the time, and doesn't appear in the battery consumption list, they think the app wastes battery power.
You mean background?
I ask because foreground is still ok.
I don't know about Chinese apps, but it's not a new thing that there are apps that abuse what's possible on Android.
But there are also apps that use what's possible on Android for good reasons.
For example, this cool app that so many users like (I don't use it, but I think it's cool) :
It has a small on-top view that allows the user to access it for contacting people.
I don't know how they made it work for so long without disappearing, but the more Google restricts background apps, the more I think they will have to put a foreground service.
And now Google has made it impossible to hide notifications of foreground apps right from the notification drawer (still at least possible from other settings screen) :
And it was replaced with 2 useless buttons instead:
Users don't like to get reminded that the app is running in the background. When they see this notification, even if the app doesn't do anything in 99.9999% of the time, and doesn't appear in the battery consumption list, they think the app wastes battery power.
lb...@gmail.com
@11 ok maybe Drupe is a bad example. I'll give you my example instead.
My spare time app is an app manager alternative (here:https://play.google.com/store/apps/details?id=com.lb.app_manager ) . It listens to app related events.
There are at least 2 features in the app that need to get those intents even if the user isn't seeing any Activity: widgets, qnd removed apps list.
The removed apps list is updated in my DB , to store which apps were removed, so the user can see the history of them later.
Because of the new restrictions, I had to use foreground service, and some users were angry about it, thinking the app consumes battery even though everything is technically the same as before
My spare time app is an app manager alternative (here:
There are at least 2 features in the app that need to get those intents even if the user isn't seeing any Activity: widgets, qnd removed apps list.
The removed apps list is updated in my DB , to store which apps were removed, so the user can see the history of them later.
Because of the new restrictions, I had to use foreground service, and some users were angry about it, thinking the app consumes battery even though everything is technically the same as before
lb...@gmail.com
@7 About what I wrote in the end on @8 , I was confusing this matter with another:
https://issuetracker.google.com/issues/110314359
https://issuetracker.google.com/issues/110372762
Here what I request is that when the user calls someone, we would be notified of when the other side has answered the call (meaning it stopped ringing due to answering the call).
Here what I request is that when the user calls someone, we would be notified of when the other side has answered the call (meaning it stopped ringing due to answering the call).
ad...@google.com
We've deferred this issue for consideration in a future release. Thank you for your time to make Android better.
ad...@google.com
In case you want to provide more information with respect to this bug, please file a bug in AOSP via "https://goo.gl/TbMiIO ".
ad...@google.com
We anticipate in a future release that the InCallService API will be extended to support providing call information to apps which use the CompanionDeviceManager (see https://developer.android.com/reference/android/companion/CompanionDeviceManager ) API to provide expose call information to a connected companion device. However, there are no plans to expose this API beyond that use-case.
lb...@gmail.com
@17 I'm not talking about InCallService , and I've already written that it has too many disadvantages:
https://issuetracker.google.com/issues/110374382#comment8
Check here and see an example of what I talk about:
https://issuetracker.google.com/issues/110374382#comment4
Since you didn't understand the request, made a new one here:
https://issuetracker.google.com/issues/158177685
Check here and see an example of what I talk about:
Since you didn't understand the request, made a new one here:
Description
It tells you that the phone call is answered, when the state (using TelephonyManager.EXTRA_STATE) is TelephonyManager.EXTRA_STATE_OFFHOOK .
However, for outgoing call we have no indication of when the call was answered.
The moment we get OFFHOOK is the same as the moment of starting to dial. Not from the moment it was answered.
Please provide us an API for being notified when an outgoing phone call is being answered