Closed Bug 983476 Opened 6 years ago Closed 6 years ago
[Tarako] incoming phone call can take up to 5 seconds to show the UI
1. place a SIM in SIM 1 in the device ( no SIM 2 ) 2. reboot the phone 3. unlock the phone 4. unlock the SIM PIN lock 5. wait for the signal to be picked up 6. give the phone a call Expected: first ring should show the ui Actual: 2 second delay, ringing occurs, 3 seconds later the UI appears Gaia 7329446974f0ea3b14d61bd38f205eb17a5ce62d caution: filename not matched: chrome/toolkit/content/global/buildconfig.html BuildID 20140313135844 Version 28.0 ro.build.version.incremental=104 ro.build.date=Thu Mar 13 14:02:18 CST 2014 Tarako
blocking-b2g: --- → 1.3T?
We should get a scope here before we mark it blocking. What is the target time?
From partner: the receiving (MT) phone is expected to ring before the calling (MO) phone hears the 2nd ring 5 sec could be pretty close to 2nd ring. Can QA confirm again? Thanks
Verified that the bug still exists. Gaia 15385efaf840090391d182d821eaeda6d25cf0e0 BuildID 20140317060055 Version 28.0 ro.build.version.incremental=113 ro.build.date=Mon Mar 17 06:10:08 CST 2014 Tarako
Ken, any idea if this could be a RIL issue ?
I can not reproduce this issue in Taipei. I wonder if this is a network issue? Could you test it in other network? Or Could you please provide logs for us. Thanks.
To Naoki for comment 8
Priority: -- → P1
Whiteboard: [c=progress p= s= u=]
There is at least a 2 second delay between hearing the ring and getting the ui for the call. Sometimes up to 5. I don't think that's related to the network. There is a 13 second delay from the time of the call to hearing the ring. That might be network related. I have not filed that bug yet. Please investigate the issue with the delay from ring to ui. I will investigate getting the logs for the delay in call connectivity in a separate bug.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(kchang)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #10) I got the different test result. Device pop up incoming call right away when I heard the ring tone. Hi Aknow, can you please analyze this bug? If you are not available for this, please let me know. Thanks.
Flags: needinfo?(kchang) → needinfo?(szchen)
could the difference be in the number of background apps when the call is coming in? could you share what app are in the background during your testing? thanks
Yes, I will analyze the bug. Naoki, Are both MO/MT within the same operator network? If not, could you reproduce the issue on this condition. >> Actual: 2 second delay, ringing occurs, 3 seconds later the UI appears What do you mean "2 second delay"? At which moment, you strat to measure the delay. And the "ringing occurs" means the MT phone ringing, right?
As per the STR, this is after a reboot and unlocking SIM and screenlock. Please see the attached video.
It might not be a ril issue I think. The issue focus on the long delay from MT call ring to UI. Hi Patrick, I remember you have done some imporvement on this topic. Do you have any idea?
Code of playing ringtone had been moved to system app recently, and it has become faster now. However, showing the UI needs to launch Comms app, it takes more time. In my local test, even with music playing in background, the ringtone starts to play at almost the same time when the first ringback starts. I can't reproduce the 2 seconds delay, either.
Two HTML files are loaded when there's an incoming call, first dialer/index.html, and then dialer/oncall.html. After index.html is loaded, dialer.js registers a handler for message "telephony-new-call", which opens oncall.html. I am wondering: - Can we load oncall.html only for incoming call? - Is the fist "telephony-new-call" queued and delivered to dialer right after it registers the handler? Will try to figure these out tomorrow.
perhaps Etienne can provide some insight on comment 17
(In reply to Ting-Yu Chou [:ting] from comment #17) > Two HTML files are loaded when there's an incoming call, first > dialer/index.html, and then dialer/oncall.html. After index.html is loaded, > dialer.js registers a handler for message "telephony-new-call", which opens > oncall.html. > > I am wondering: > > - Can we load oncall.html only for incoming call? Nope. Eventually I think we'd like to direct system messages at attention screens directly, but it's not possible right now. > - Is the fist "telephony-new-call" queued and delivered to dialer right > after it > registers the handler? Yes. We could also investigate setting the message handler without waiting for the "onload" event...
is Ting working on this at this moment or is it Aknow? Thanks
Unassign myself. It might be a performance issue and not just the ril issue.
Assignee: szchen → nobody
Joe, seems :kk1fff is working on this, Thinker'd like me to figure out why UI comes up faster when there's no background app.
Whiteboard: [c=progress p= s= u=] → [c=progress p= s= u=][priority]
hi Patrick, are you working on this bug? Thanks
Etienne, wonder if you have some thoughts on this bug? thanks
I am focused on the case with music for now. But I will update this bug if I find anything related to this.
We have moved the ringtone code to sysapp, @firstname.lastname@example.org what is the version of your code?
Triage: team's working on bug 987022 to speed up incoming call rings. let's track bug 987022
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 987022
Duplicate of this bug: 989931
Duplicate of this bug: 990003
This is not a duplicate. It's not the ringing that's the problem; it's the phone UI not showing. The ringing happens for 5 seconds before the user has the UI to answer the call.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Etienne, this bug seems to be a dup of Bug 990003. do you have a preference on which bug you want to work on and dup one of it to the other? Do you mind taking the bug? thanks
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 990003
You need to log in before you can comment on or make changes to this bug.