Closed Bug 989594 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:1.3T+)

RESOLVED DUPLICATE of bug 990003
1.4 S6 (25apr)
blocking-b2g 1.3T+

People

(Reporter: james.zhang, Assigned: kk1fff)

References

Details

(Keywords: perf, Whiteboard: [c=memory p= s= u=tarako] eta:4/11)

Attachments

(1 file)

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
blocking-b2g: --- → 1.3T?
Flags: needinfo?(tlee)
Flags: needinfo?(styang)
Flags: needinfo?(gal)
Flags: needinfo?(fabrice)
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.
Severity: major → critical
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?
Flags: needinfo?(gal)
Supposedly, the video/music playing will be resumed after call ends. Where/How you keep the previous status in video/music playing?
Flags: needinfo?(styang) → needinfo?(james.zhang)
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.
Flags: needinfo?(fabrice)
(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.
Flags: needinfo?(james.zhang)
(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.
Flags: needinfo?(tlee)
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
Keywords: qawanted
Summary: [Tarako] Incoming call/message/alarm have performance issue when video/music/camera apps foreground → [Tarako] Incoming call have performance issue(20s delay) when video/camera apps foreground
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
Keywords: qawanted
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
Assignee: nobody → pwang
blocking-b2g: 1.3T? → 1.3T+
Duplicate of this bug: 989931
Severity: critical → blocker
Priority: -- → P1
Whiteboard: [c=memory p= s= u=]
Status: NEW → ASSIGNED
Keywords: perf
Whiteboard: [c=memory p= s= u=] → [c=memory p= s= u=tarako]
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.
Depends on: 987022
Whiteboard: [c=memory p= s= u=tarako] → [c=memory p= s= u=tarako] [MP_Blocker]
(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.
Depends on: 992759
Whiteboard: [c=memory p= s= u=tarako] [MP_Blocker] → [c=memory p= s= u=tarako] [priority]
Whiteboard: [c=memory p= s= u=tarako] [priority] → [c=memory p= s= u=tarako] [priority] eta:4/11
Whiteboard: [c=memory p= s= u=tarako] [priority] eta:4/11 → [c=memory p= s= u=tarako] eta:4/11
hi Patrick, should we dup this bug with bug 990003? Thanks
Flags: needinfo?(pwang)
I am trying if we can also fix on platform, probably by modifying priority manager or rearranging app startup routine.
Flags: needinfo?(pwang)
QAWANTED, to confirm if this bug is still valid after bug 990003 lands
Keywords: qawanted
Mike, pls confirm this with latest build. After that, pls remove qawanted. Thank you.
Flags: needinfo?(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
Flags: needinfo?(mlien)
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
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 990003
Keywords: qawanted
Target Milestone: --- → 1.4 S6 (25apr)
You need to log in before you can comment on or make changes to this bug.