Closed Bug 980984 Opened 10 years ago Closed 10 years ago

Alert the user of an incoming from the system app

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T fixed, b2g-v1.4 fixed)

RESOLVED FIXED
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: etienne, Assigned: etienne)

References

Details

Attachments

(2 files)

Bug 979419 and bug 979426 are not going to cut it :/
Event when lazy loading everything getting the ringtone from the mozSettings DB takes a loooong time while the phone is so buzzy.

Good news is, this patch is less risky and insta-backaoutable (adding a new file).

And it's working *very* well, even on the tarako I hear the phone ringing *before* the first ring on the SIP client side. Then it takes a few seconds for the call screen to show up.
Blocks: 973596
Assignee: nobody → etienne
blocking-b2g: --- → 1.3T?
Attached file Gaia PR
r? Alive for the system part (you'll like it, it's small and System2 compliant :))
r? Rik for the dialer part (only removals) and a more than welcome feedback on the system part
Attachment #8387749 - Flags: review?(anthony)
Attachment #8387749 - Flags: review?(alive)
blocking-b2g: 1.3T? → 1.3T+
Comment on attachment 8387749 [details] [review]
Gaia PR

r+ with nit
Attachment #8387749 - Flags: review?(alive) → review+
Comment on attachment 8387749 [details] [review]
Gaia PR

Looks very good. A few questions/comments on the PR but good to go.
Attachment #8387749 - Flags: review?(anthony) → review+
https://github.com/mozilla-b2g/gaia/commit/88677ea30dff41d6dc404ab95285d318accdd738
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Was able to reproduce locally, this should be better.
https://github.com/mozilla-b2g/gaia/commit/5aa7d6e424c46c2a9761ec85a016f39de3105d71
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Is there still a few seconds delay before the screen shows up after the phone rings?
Flags: needinfo?(etienne)
base on initial testing, ringtone does ring quickly but screen still show up after a couple rings
If music app is at foreground, its audio channel that used to play music won't be suspended when ringtone starts in system app. So the music and ringtone are both playing before music is put to background.
(In reply to Patrick Wang (Chih-Kai Wang) (:kk1fff) from comment #9)
> If music app is at foreground, its audio channel that used to play music
> won't be suspended when ringtone starts in system app. So the music and
> ringtone are both playing before music is put to background.

Did you file a followup? (I can't find one but that may be me!)
ni answered in Comment 8.
Flags: needinfo?(etienne)
After the commit, call screen shows about 5-10 seconds after the ringer plays. Should we also open call screen in system app like call ringer?
Flags: needinfo?(fabrice)
Flags: needinfo?(etienne)
(In reply to Jesse from comment #14)
> After the commit, call screen shows about 5-10 seconds after the ringer
> plays. Should we also open call screen in system app like call ringer?

Technically we _could_.
But I don't see it happening in the 1.3t time frame...
The call screen talks with the dialer app a lot, so making it part of system app will require a rewrite of:
* the insertion in the call log history
* the bluetooth support
* the headset support
Flags: needinfo?(etienne)
I agree with Etienne. Moving more things in the system app is not doable for 1.3t and is not desirable in general.
Flags: needinfo?(fabrice)
Are there any other ways to shorten latency of opening oncall.html?
I like the android activity. Could we open call screen html page directly like android start call screen activity registered in AndroidManifest.xml directly?  Opening oncall.html by way of dialer's index.html is a time of waste.
Depends on: 987211
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: