959054 - Do not launch the usage widget frame when the phone boot up

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

Description

[Tzu-Lin Huang [:dwi2][:tzhuang]]

When running on low memory device like Tarako, sometimes Homescreen app gets killed before Cost Control app does.

On Homescreen, run 'adb shell b2g-info' to check processes and memory usage.

      NAME PID NICE  USS  PSS  RSS VSIZE OOM_ADJ USER   
       b2g 119    0 26.2 29.0 36.4 157.4       0 root   
           364    0  0.2  2.4  8.5  49.5       2 root   
     Usage 371    1  6.5 10.1 19.0  64.9       2 app_371
Homescreen 389    1 12.9 16.5 25.6  69.1       2 app_389


Open Settings app, run b2g-info again, 

    NAME PID NICE  USS  PSS  RSS VSIZE OOM_ADJ USER   
     b2g 119    0 25.7 28.6 35.7 163.0       0 root   
         364    0  0.3  2.4  8.4  49.5       2 root   
   Usage 371    1  5.7  9.3 18.0  64.9       2 app_371
Settings 492    1  7.6 10.7 18.7  63.2       2 app_492           

Homescreen app is killed but Usage app is still alive.

Currently, Usage app is brought up in utility tray of System app. So it lives all the time after device booting up.
We are wondering if is there any chance to run Usage app in a non-daemon way but achieve the same functionality so that we could save the memory consumed by Usage app.

Comment 1

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Hi

Comment 2

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Hi Salvador,

We would like to save memory as much as possible on low memory device. Since Usage app is brought up during start-up time and data usage is automatically kept in Gecko (MozNetworkStats), we are wondering if there any chance to run Usage app in an non-daemon way? 

Do you have any thought on it?

Thanks

Comment 3

[Salvador de la Puente González [:salva]]

Hello Tzu

Cost Control never was a daemon. Indeed, it acts in the same way as SMS, it only awakes when a system message is received (a call ended, a SMS was sent or a periodical alarm is triggered), then make its work, then auto-closes itself.

More even, the widget in the utility try is eligible to be killed by the OOM killer as any other normal application. It is auto awake when the utility try is displayed by the user.

The only problem is Cost Control is being launched at start-up but I though bug 938470 was trying to avoid it. Indeed, as all the multi-SIM stuff was moved to the new NetworkStatistics API I think we can stop launching CC at the beginning.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Salvador de la Puente González [:salva] from comment #3)
> The only problem is Cost Control is being launched at start-up but I though
> bug 938470 was trying to avoid it. Indeed, as all the multi-SIM stuff was
> moved to the new NetworkStatistics API I think we can stop launching CC at
> the beginning.

Update the title of this bug after reading the comment above and consult Tzu-lin offline. I think this should stop cost control app process from showing up.

Should be a quick two line patch.

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Github: https://github.com/mozilla-b2g/gaia/pull/15394

salva, could you review the patch? Thanks!

I don't think this will result any bad side-effect.

Comment 6

[Salvador de la Puente González [:salva]]

Comment on attachment 8360899 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/15394

Moving the review to :mai. Mai, can you ensure if, with this change, and in a postpaid scenario, are we tracking calls and SMS in the correct SIM. My concern is about line 158 of the config_manager.js I don't know if we have the ICCID ready when the message-handler starts or if it could suppose a race condition.

Comment 7

[Marina Rodríguez [:mai]]

Comment on attachment 8360899 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/15394

Hi,
there is no problem with the loading of the message-handler. The app starts message-handler.html, after loading the iccId. (If 'onsuccess' process of the method 'Common.loadDataSIMIccId')

The proposed patch does not work properly. It produces this error:
E/GeckoConsole(10119): [JavaScript Error: "TypeError: widgetFrame is undefined" {file: "app://system.gaiamobile.org/js/cost_control.js" line: 121}]

You must check if widgetFrame exists before to make the call 'widgetFrame.setVisible (false)' on line 117 and 121.

Moreover,
I think it's neccesary execute _attachNetworkEvents() if you remove
_ensureWidget, because the network alarms not works until Bug 858017
will be fixed.

And as Salva comments, if you don't launch the notification screen, the application doesn't have a normal init, then the iccId is not loaded before message-handler starts. This poduces another error because it's not possible tracking the calls and sms.

Content JS ERROR at app://costcontrol.gaiamobile.org/js/config/config_manager.js:73 in requestConfiguration: No iccInfo available

Regards

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Thank you for you careful review.

(In reply to marina rodríguez [:mai] from comment #7)
> Comment on attachment 8360899 [details] [review]
> Github: https://github.com/mozilla-b2g/gaia/pull/15394
> 
> Hi,
> there is no problem with the loading of the message-handler. The app starts
> message-handler.html, after loading the iccId. (If 'onsuccess' process of
> the method 'Common.loadDataSIMIccId')
> 

Good to hear that.

> The proposed patch does not work properly. It produces this error:
> E/GeckoConsole(10119): [JavaScript Error: "TypeError: widgetFrame is
> undefined" {file: "app://system.gaiamobile.org/js/cost_control.js" line:
> 121}]
> 
> You must check if widgetFrame exists before to make the call
> 'widgetFrame.setVisible (false)' on line 117 and 121.
> 

Yes. I realized I should remove the entire applicationready event handler block. Nothing is actually being run during boot after I removed the two lines.

> Moreover,
> I think it's neccesary execute _attachNetworkEvents() if you remove
> _ensureWidget, because the network alarms not works until Bug 858017
> will be fixed.

Ouch, isn't that means the widget frame MUST be live and stay in order for network alarm to be invoked?

> And as Salva comments, if you don't launch the notification screen, the
> application doesn't have a normal init, then the iccId is not loaded before
> message-handler starts. This poduces another error because it's not possible
> tracking the calls and sms.
> 
> Content JS ERROR at
> app://costcontrol.gaiamobile.org/js/config/config_manager.js:73 in
> requestConfiguration: No iccInfo available
> 

OK. So we DO need to ensure the launch of the widget frame *before* the app.

We *really* need to get rid of the persistent Usage process. How do we make it happen? Is there a set of dependent Gecko bug available for people to work on?

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Let's mark this as invalid and continue to working on this in bug 962444.

Comment 10

[Marina Rodríguez [:mai]]

Sorry for delay. 
Right now, I'm waiting for resolution of "Bug 960974 -[hamachi] NetworkStats Alarms not working" to work on "Bug 858017 -[COST CONTROL] Use Gecko native support for data usage alarms provided by NetworkStats API 2.0". I expect this to happen at the end of this week.

Besides, I'm thinking on the posibility of adding a new flag to check if the iccId was  previously loaded, when the widget it's not launched and the costcontrol application receive a sms or call notification on message_helper module.

Regards

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Joe, haven't have a chance to talk to you about priority on this today. Might if we talk about it tomorrow?