989594 - [Tarako] Incoming call have performance issue(20s delay) when video/camera apps foreground

Status: RESOLVED DUPLICATE of bug 990003

(Firefox OS Graveyard :: Performance, defect, P1)

Description

[James Zhang (Spreadtrum)]

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

Comment 1

[James Zhang (Spreadtrum)]

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.

Comment 2

[James Zhang (Spreadtrum)]

Add Sam here for discussion.

Comment 3

[James Zhang (Spreadtrum)]

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

Comment 4

[sam.hua]

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

Comment 5

[Andreas Gal :gal]

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

Comment 6

[Steven Yang [:styang]]

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

Comment 7

[[:fabrice] Fabrice Desré]

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.

Comment 8

[James Zhang (Spreadtrum)]

(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.

Comment 9

[James Zhang (Spreadtrum)]

(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.

Comment 10

[Andreas Gal :gal]

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.

Comment 11

[[:fabrice] Fabrice Desré]

Attachment: critical-shared-process.patch

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.

Comment 12

[sam.hua]

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.

Comment 13

[Andreas Gal :gal]

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.

Comment 14

[sam.hua]

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

Comment 15

[Thinker Li [:sinker]]

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.

Comment 16

[Joe Cheng [:jcheng] (please needinfo)]

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

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 18

[Thinker Li [:sinker]]

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.

Comment 19

[Joe Cheng [:jcheng] (please needinfo)]

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

Comment 21

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

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.

Comment 22

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

(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.

Comment 23

[Joe Cheng [:jcheng] (please needinfo)]

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

Comment 24

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

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

Comment 25

[Joe Cheng [:jcheng] (please needinfo)]

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

Comment 26

[Brian Huang [:brianhuang][:brhuang]]

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

Comment 27

[Mike Lien[:mlien]]

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

Comment 28

[Bingqing Li]

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

Comment 29

[Brian Huang [:brianhuang][:brhuang]]

dup to 990003