Incoming call/message/alarm have performance issue when video/music/camera apps foreground Fabrice's group apps patch can't handle these case. There are a lot of similar performance issue in spreadtrum bugzilla now. http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=294967 http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=294227 http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=294625

http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=294760 http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=294199 User can't answer incoming call when multimedia is working.

Add Sam here for discussion.

And multimeida apps may be killed by LMK when incoming call, we also have a lot of similar issue in our bugzilla.

Maybe we can use some special actions to fix this problem. for example in android of SPRD http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=121680 http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=97008 case RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED: if (RILJ_LOGD) unsljLog(response); - + // for bug 97008 start + if (mThread == null && Build.IS_LOWMEM_VERSION) { + mThread = new Thread(new Runnable() { + public void run() { + try { + if (RILJ_LOGD)riljLog("ActivityManagerNative.moveTaskToBack() start "); + ActivityManagerNative.getDefault().killStopFrontApp(ActivityManager.KILL_STOP_FRONT_APP); + if (RILJ_LOGD)riljLog("ActivityManagerNative.moveTaskToBack() end "); + Thread.sleep(3000); + } catch (RemoteException e) { + e.printStackTrace(); + } catch (InterruptedException e) { + e.printStackTrace(); + } + mThread = null; + } + }); + mThread.start(); + } + // for bug 97008 start

So the idea here is to kill the foreground app when there is an incoming call?

Supposedly, the video/music playing will be resumed after call ends. Where/How you keep the previous status in video/music playing?

We have no session restore for now, at that looks like a rather large undertaking giving the deadlines we have. One thing we could try is to make the dialer share the process of another certified app is one is already running. I'll write a wip to check if that helps us there.

(In reply to Steven Yang [:styang] from comment #6) > Supposedly, the video/music playing will be resumed after call ends. > Where/How you keep the previous status in video/music playing? LMK notify the apps will be killed, and the apps store the status in storage or system apps and restore the status when restart.

(In reply to Fabrice Desré [:fabrice] from comment #7) > We have no session restore for now, at that looks like a rather large > undertaking giving the deadlines we have. > > One thing we could try is to make the dialer share the process of another > certified app is one is already running. I'll write a wip to check if that > helps us there. I think we should implement session restore on gaia side. We have some bug without incoming call, SMS->lockscreen->SMS killed by LMK. SMS->homescreen->SMS killed by LMK. see http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=294824 You can translate some Chinese description bug by google translate, and sorry for that, not all of our QA can't use English description.

Implementing generic session restore requires fairly deep architectural changes and will take many months. It requires changes to the gecko and gaia side across all the apps. Our only option here is to accept some apps getting killed when going to the homescreen or lockscreen or to a call. We can try to reduce the number of ways this state can be hit by ensuring that we are smart about memory. We are currently not compacting the background app to improve app switch times, so SMS is less likely to survive and more likely to get outright killed. We should revisit that.

wip patch: that let apps that have 'critical' moztype (currently the clock and the comms app) reuse the process of another certified app if there's one available. I haven't tested much apart the clock yet. I'm also a bit worried about sharing processes with too many apps with that + the activities sharing. Let's test more and see if that improves the situation overall.

Now music player and video apps are very simple. I don't think it is a hard work to store the status and restart after the call application/Message ended. We can do it at first before we have the better solution for the performance.

The problem is regression risk. We have to create a framework to notify apps to store the state, avoid them being killed to fast, change the apps, etc. All of this will take a few weeks to implement, and a few more weeks to stabilize. This will easily slip our schedule by a few months total. We should very carefully decide whether this feature is worth that, or whether we want to ship the first version now, and iteratively make improvements to the software in future releases.

At first, we should know the performance is okay or not if we kill the front app when incoming call.

I think it is very clear that to kill apps to release memory could save the performance of incoming call, at least for incoming call. For session restoring, we have start a discussion at dev-b2g mailing list. - see https://groups.google.com/d/msg/mozilla.dev.b2g/7imJkAI6IGs/MfnStbwVMx8J Just like what Andreas said, I would rather like to have a frame and to make this as a long solution, not just a workaround for tarako only, although still have some short term solution that is being worked on. For example, bug 987022.

i'd like to have QA to confirm how bad the performance issue is. will be great to provide the number of seconds in delay Thanks

I got roughly about ~16 seconds testing incoming call ui coming up w/ camera app running in the foreground Gaia 02b97c89dec7a10a955c85b921b2a66181eebb0e Gecko f8bca24057937f5b09d73512ba1e771011ab4203 BuildID 20140331124355 Version 28.1 ro.build.version.incremental=75 ro.build.date=Mon Mar 31 12:45:23 CST 2014 Tarako

For video and camera, both of them could be killed according the definitions of requirement of the Tarako. This very possibly be the problem of how fast we could kill the app while the memory is going not enough. We would put the video and camera app into the check list to make sure our configuration could handle these cases. (see bug 974308) For music app, we already have the bug to handle it, bug 973596.

triage: incoming call must be able to be picked up by user. 1.3T+. To Patrick for now. thanks

We are going to kill apps when launching comms app on bug 987022, I believe that would also help this case. I will test the patch and update the result.

(In reply to Patrick Wang (Chih-Kai Wang) (:kk1fff) from comment #21) > We are going to kill apps when launching comms app on bug 987022, I believe > that would also help this case. I will test the patch and update the result. I have tried that patch under the condition decribed here. By killing video/camera, the launch of comms becomes faster.

hi Patrick, should we dup this bug with bug 990003? Thanks

I am trying if we can also fix on platform, probably by modifying priority manager or rearranging app startup routine.

QAWANTED, to confirm if this bug is still valid after bug 990003 lands

Mike, pls confirm this with latest build. After that, pls remove qawanted. Thank you.

verify with below build and it's fine Gaia c62bff0bfb8b069c962dfae2640e931cc9ad1bdf Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/7e764399b4fc BuildID 20140415164003 Version 28.1

Tried on the latest build. Incoming call screen shows up about 3 seconds after the first ringtone while video/music being played. Build Info: ----------------------------------------------------- Gaia c62bff0bfb8b069c962dfae2640e931cc9ad1bdf Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/7e764399b4fc BuildID 20140415164003 Version 28.1 ro.build.version.incremental=eng.cltbld.20140415.201139 ro.build.date=Tue Apr 15 20:11:46 EDT 2014

dup to 990003