Closed AndroidDeveloperLB closed 6 years ago
OK since I can't find the API for this, I assume it doesn't exist, so I've requested it here: https://issuetracker.google.com/issues/110862206
I think that's a very different part of Android API, looks like Notification.Builder.setFullScreenIntent()
is what you're after? You can check out the notification
branch here for an example.
But that would still not be good, because you don't know when to show it. Somehow, the notification of a phone call appears when the device is in immersive mode, and in full screen when its screen is turned off. This sample shows only the part of full screen, but it will still be shown full screen no matter what.
Did you try to run it?
Run the sample? Yes.
When I run it on an emulator with Oreo, the full screen activity is shown when the phone is locked or the screen turned off. When the phone is unlocked, only a heads up notification is shown.
You said:
it will still be shown full screen no matter what
but that is not what is happening in my case.
When you ran the sample, it worked differently from what I described above?
OK, I've checked again (tested on Android 8.1), and here are the various scenarios, on a real device:
for outgoing call, shows fine in full screen. Makes sense. Rest of the cases below are for incoming calls.
unlocked, no immersive mode - shows fine in full screen. Makes sense.
unlocked+immersive mode (for example on YouTube) - still shows full screen. Might be better to know in this case, as some people might want to have a notification instead, or something even more subtle.
locked, screen turned on/off, or screen turned off with any type of locking (even without) : on the current sample, there is a bug that you have to first unlock the lock screen, and only then see the full screen UI. This can easily be fixed, by using mechanism that's used for alarm clock apps (disabling keyguard etc...). If you wish I can show you. Since it's Android 8.0 and above, maybe I don't even need all the code that fix it, but only a small part of it.
In all of the above, there is no notification from the app or even from the OS, about the phone call.
BTW, since replacing the during-call-UI is only from Android O, I think you should change the minSdkVersion to be 26 and not 23
Here, attached a fixed project (fixed for #4 on my list of scenarios) .
You've also forgotten to add addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
to the Intent of CallActivity, which cause a crash on Android P.
simple-phone.zip
Tested to work fine even on Android P DP4 (beta 3) on Pixel 2.
Let's rewind a bit. Were you testing that with the master
branch, or the notification
branch?
Oh sorry I missed the part of the notification. Why did you make a branch for it? Could simply add a preference or something...
Now I've tested it. Seems it shows a notification when the screen is unlocked, and full screen when screen is turned off or when you are on the lock screen, just like on the normal UI. However, for outgoing call, it still shows a notification, and it shows "null" as the caller, and says to "tap to answer call" even though I'm the one who initiated the call... This branch also has minSdk 23 even though it's not supported there.
Anyway, back to the original question: is it possible to handle immersive mode apps differently?
Also, thanks to your app, I think I've found a bug on the OS : https://issuetracker.google.com/issues/111134149
You've also forgotten to add addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) to the Intent of CallActivity, which cause a crash on Android P.
Thanks, it is so weird that this does not cause a crash on O, but does on P and M. I've added the flag now.
BTW, since replacing the during-call-UI is only from Android O, I think you should change the minSdkVersion to be 26 and not 23 This branch also has minSdk 23 even though it's not supported there.
I have no idea what you are talking about. What method call, or class used by this sample app require API 26? I just tested it on API 23 without issues.
Why did you make a branch for it?
For one thing, because this repo is not aiming to implement a fully functional phone app. As stated in the readme, it's the bare minimum you need to have for Android to recognize you as a Phone app.
Also, like you mentioned, I didn't care to cover all the cases like they should be on that branch. That should be no surprise, there's a lot this app does not cover.
Anyway, back to the original question: is it possible to handle immersive mode apps differently?
Handle incoming calls when in immersive mode differently than the notification
branch already does? In what way?
It's not weird. It was always supposed to be this way, and they had a bug on some versions of not enforcing it : https://developer.android.com/preview/behavior-changes#fant-required
About API 23 vs 26, you are right. I was sure this whole API of changing the UI was newer, but it's actually from API 23 : https://developer.android.com/reference/android/telecom/InCallService https://developer.android.com/reference/android/telecom/TelecomManager#ACTION_CHANGE_DEFAULT_DIALER https://developer.android.com/reference/android/telecom/TelecomManager#METADATA_IN_CALL_SERVICE_UI Why did I think about 26 ... Odd.
About the bare minimum, I think it's important to show both ways in the same sample. It's still quite minimum. If you wanted, you could have put 2 samples in the same project, instead. When you put it in a branch, it's much more hidden... It's like you plan some time to merge them...
"Handle incoming calls when in immersive mode differently than the notification branch already does? In what way?" I don't understand the question. My question was if it's possible to do something else in case the user is in immersive app. Maybe I could avoid showing a notification on top of his game, so that he won't accidentally click on the notification when he tried to click on something on the game (happened to me a lot) .
Maybe I could avoid showing a notification on top of his game, so that he won't accidentally click on the notification when he tried to click on something on the game (happened to me a lot).
I understand the heads up notification as being the less interruptive way (compared to switching apps) of letting people know about high priority things.
If there was nothing at all popping up on the screen, how would the user take the call?
In any case, I don't think the android.telecom
APIs have anything interesting to you in this regard.
Switching apps give the game a change to pause. Having the notification doesn't. Instead, if the user is about the touch there, it leads to accidental touches (answer or end call).
"If there was nothing at all popping up on the screen, how would the user take the call?" Hearing the ringtone should be enough. If it's on silence, he can choose what to do on this case (whether to see full screen or something else).
I really hate dialogs popping out of nowhere, making accidental choices. This is no different than those.
Imagine an app would have shown you such a notification asking you to see an ad, in the middle of a game, and you clicked it because you were about to tap there. Wouldn't it really annoy you?
An incoming call is not an ad.
Also, I don't think all games pause when you just switch apps.
It was an example of making you do something you didn't intend on doing, by interrupting what you are doing with on top UI, when you aren't prepared for it. An improper time and position of an ad is the same as here. There are even guidelines of when and how it's recommended to show them.
OK made a request: https://issuetracker.google.com/issues/111154123
In the built in dialer, in case you are in an immersive app (playing a game or watching a video), and someone calls you, you get a notification instead of a full screen Activity asking you what to do.
Is it possible to handle it too, using the new API ? Maybe even give the user a choice, of whether to show it as notification or a full screen Activity ?