815856 - Dialer app goes to background OOM class when switching apps during a call

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P2)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Make a call
 (2) Switch to another app

I see

cjones@beast:~[]$ adb shell b2g-ps
b2g              root      109   1     221096 61608 ffffffff 40acd0c8 D /system/b2g/b2g
Messages         app_0     358   109   72168  22384 ffffffff 40108330 S /system/b2g/plugin-container
Homescreen       app_0     368   109   65900  16364 ffffffff 40069330 S /system/b2g/plugin-container
Cost Control     app_0     413   109   64924  15732 ffffffff 400d9330 S /system/b2g/plugin-container
Settings         app_0     461   109   79908  19236 ffffffff 400d7330 S /system/b2g/plugin-container
Communications   app_0     1398  109   91308  29584 ffffffff 407b57b4 R /system/b2g/plugin-container
(Preallocated a  app_0     1728  109   55512  10696 ffffffff 40070330 S /system/b2g/plugin-container
cjones@beast:~[]$ adb shell cat /proc/1398/oom_adj
6

An oom_adj score of "6" is the value for background apps, which get killed first on memory pressure.

The dialer has visible UI (the little green bar) during calls, even if something else draws that UI, so the dialer app should remain in the foreground while in a call.

Calls being interrupted because the lowmemkiller is accidentally allowed to choose the dialer app would be a severe problem, and possibly a certification issue.  We should bb+ this.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure that this is how we want to fix this bug.

Shouldn't the dialer be a higher priority even than foreground apps? If I switch to another app during a call, I think I'd prefer to the app that is currently visible to be killed rather than the dialer.

Seems to me like as long as you're on a phone call, the dialer should be an an even higher OOM class than visible apps.

Comment 2

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 3

[Etienne Segonzac (:etienne)]

Good news: we fixed it while fixing bug 813617 :)

Comment 4

[Darren]

Verified as fixed in build 201300103070201 on Unagi.