View Issue Details

IDProjectCategoryView StatusLast Update
0010985MMAGeneralpublic2013-08-06 00:02
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.4 
Target Version1.0.4Fixed in Version1.0.4 
Summary0010985: Lock screen doesn't activate using 'home button' (regression in 145--it fails completely)
DescriptionIf the lock screen has never been activated, and the user turns on their device by pressing the home button --> the lock screen player doesn't appear. In fact it will never appear as long as the user tries to access it via the home button, and it hasn't previously been activated.

If the lock screen has previously been activated, and the user turns on their device by pressing the home button --> the lock screen player briefly appears and is then replaced by the lock screen.

Ideally, in both of the above cases, pressing the home screen should trigger the appearance of the lock player.
TagsNo tags attached.
Fixed in build151

Relationships

related to 0011021 closedmartin Lock Screen Player can't be disabled on JB devices 
related to 0010153 closedmartin Ability to control playback on pre-4.2 phones that screen lock active 
related to 0009627 closedmartin Don't show Tray MM icon when nothing is playing back 
related to 0009630 closedjiri Entry displays in notifications bar even when it shouldn't 
related to 0010808 closedmartin Termination timer should be configurable 
related to 0011033 closedmartin Lock screen activates when it shouldn't 
related to 0011342 closedmartin Lock screen player fails to activate if MMA isn't in focus 

Activities

martin

2013-06-13 16:25

developer   ~0036483

Isn't it possible that this occurs only if the tracklist is empty? If tracklist is empty and there are no current track, lock screen player doesn't appear or just briefly appears.

rusty

2013-06-13 17:10

administrator   ~0036487

It seems that the problem is device specific.

On an S3 (JB 4.1), the bug occurs exactly as described.
On an Xperia Pro (ICS), the bug doesn't occur.

martin

2013-06-14 09:44

developer   ~0036500

The bug apparently occurs just in JB4.1 (API 16+) , but for this API there is no possibility to block the HOME button for security reasons. So I made special solution for API 16+. Upon click home screen button, previous lockscreen player is destroyed but new one appears. So maybe we could see lock screen for a while .
Fixed in build 142.

rusty

2013-06-16 17:38

administrator   ~0036526

Tested 142. The behavior on an S3 running JB (4.1.1) is the same. i.e. pressing the lock button causes the lock player to briefly appear, and then be replaced by the standard lock screen.

martin

2013-06-17 16:50

developer   ~0036538

Perhaps it caused by slight delay adjustment of flag from KeyguardService, should be fixed now. If issue still occurs, please attach a log file.
Fixed in build 143.

peke

2013-06-24 01:47

developer   ~0036649

Verified 145 no regressions on Nexus 7

rusty

2013-06-24 15:13

administrator   ~0036653

Last edited: 2013-06-24 15:14

Lock screen seems to fail completely in build 145 (i.e. it doesn't activate using either the on/off or home buttons).

peke

2013-06-25 01:38

developer   ~0036655

Have you tested to add new lock screen?

rusty

2013-06-25 20:32

administrator   ~0036658

Yes--it seems that the problem occurs when the lock screen is initially activated. i.e. If I run MM, activate the lock screen, press on/off to trigger the lock --> it fails to activate.

BUT if I wait an hour (i.e. for MM to terminate), then it works.

So it seems that the problem isn't quite as bad as I'd originally thought--it _does_ work, but it doesn't work right away.

peke

2013-07-01 00:54

developer   ~0036689

I guess that solving http://www.ventismedia.com/mantis/view.php?id=11021 would also fix the problem

martin

2013-07-01 11:21

developer   ~0036695

Fixed in build 147.
One problem was if you change lock screen setting and stay in Options. I have added listener to that place, so it reflects current setting immediately.

rusty

2013-07-03 17:57

administrator   ~0036716

Tested 147, and I can still trigger the problem:
0 Clean install of MMA
1 Enable lock screen player in MMA
2 Press power button (to trigger lock screen)
3 Press power button or home button to turn on the device
--> Lock player flashes, and is then replaced by the Lock screen!!
4 Play a track in MMA and press Pause
5 Press power button (to trigger lock screen)
6 Press power button again
--> This time the Lock Player appears as expected. It seems that initiation of playback causes the lock player to behave correctly.

Tested with Samsung S3 running JB 4.1.1

martin

2013-07-03 18:28

developer   ~0036718

If you have clean install of MMA, so you have no tracks in your NP list, right?
If it's not this issue please attach log.

rusty

2013-07-04 04:03

administrator   ~0036729

I believe that (the absence of any content in the NP list) may have been the issue.

rusty

2013-07-04 05:16

administrator   ~0036730

Actually, further testing shows that a problem does remain. In a significant % of the time, when the user presses the 'Home' button, MMA fails to add the MM icon to the notifications bar, and when this occurs, the lock player never activates.

e.g.
1 Enable lock screen player in MMA
2 Ensure that the NP list has content in it
3 Press _home_ button to exit MMA and trigger the termination timen (10s)
--> Very often, MMA fairs to appear in the notifications bar. If it doesn't appear then step 4 will result in the lock screen not appearing
4 Press the power button twice before 10s have passed
--> Lock screen fails to appear

Debug log submitted at 1:10am.

martin

2013-07-04 10:06

developer   ~0036732

But this is currently considered to be correct. When MMA starts and nothing is playing, then PlaybackService isn't running too. Also notification doesn't appear if PlaybackService isn't running. Lock screen player appears only if MMA is visible or PlaybackService is running.

rusty

2013-07-04 22:10

administrator   ~0036747

Our termination timer indicates 'Show in notifications bar--runs in notifications bar when inactive and closes after x seconds'. To most users, this implies that if MM is inactive (i.e. if the user presses Home key to cause it to run in the background), it'll continue running for x seconds and then terminate.

Users have _no_idea_ whether or not the PlaybackService is running or not--they just expect the app to behave consistently. So if notifications appear in some cases, but not in others, it's confusing (especially considering that the PlaybackService sometimes runs when playback isn't occurring, but doesn't other times)

Similarly, since the user has no idea whether or not PlaybackService is running or not, it doesn't make sense to base the Lock Screen Player's behavior on that.

I'm not sure of the implementation details, but wouldn't it make sense to:
a) base the appearance of the MM notifications icon solely on whether or not MMA is running in the background
b) base the behavior of the LockScreenPlayer on whether the MMA is running (in focus or in the notifications bar)

marek

2013-07-05 08:02

developer   ~0036751

I think that the whole problem occurred when we decided to show notification whenever user leaves application. The first concept was that notification was displayed only when playback was running. When playback was paused or stopped, notification wasn't shown (and whole behaviour was consistent). We should think about what is the purpose of android notification. It displays that something very important is going on or something important have just happend. But we show the notification even when nothing is going on.

This change, even it looks trivial, is change in whole concept of playback service management in our application. Now we don't start the service only when it is necessary. So we try to spare the resources. And also speed up the application start up. Now it will be necessary to force the playback be running even it is completely unnecessary. Because notification can be handled only from playback service. Now when user is in activity that doesn't use playback service (like sync list, or other options), this service is not needed and is terminated. We can change it the way you suggest but it probably might have some side effects... like slower startup, higher battery drain,...

rusty

2013-07-11 21:10

administrator   ~0036817

Last edited: 2013-07-11 21:38

To answer your question, the notification serves 2 requirements:
1) to let the user control playback in causes when the app isn't in focus and the user hasn't performed an action to terminate the app.
2) to let the user know whether the app is running when it isn't in focus so that they know whether it'll respond to external playback commands and so that they have an idea of whether it's using the device's resources

Here's how a couple of other apps work:
Samsung music: shows player in tray whenever player isn't in focus AND
 i) playback is in progress
 ii) playback has been paused (via any mechanism)
It only goes away when the user exits the app using the 'End' command.
Users tend to like this (and ask for this) because they are always clear about whether the app is running or not, and because it meets the requirements defined above. The only downside is that it doesn't automatically terminate in cases where the user would expect it to (i.e. in cases where the user backs out of the application).

Google music: shows player in tray whenever player isn't in focus AND
 i) playback is in progress
 ii) playback has been paused via the notifications bar
It only goes away when the user pauses playback from within the app. This meets requirement 1, but not requirement 2.

Re. MediaMonkey, my understanding of the intended functionality was to show the notification whenever the user leaves the application _provided_ that:
 i) playback is in progress
 ii) playback has been paused AND
. . a) the user didn't intentionally exit the application (i.e. the user didn't back out of the app OR press the STOP button)
. . b) the user isn't connected to an external device (headset/bluetooth), which would indicate that playback is liable to resume
. . c) the termination timer hasn't expired (so as to prevent termination in cases where e.g. the user has temporarily stopped the car, and then will reconnect the bluetooth device)
In this way, all of the requirements defined above would be met.

I think that the intended functionality is mostly being met, EXCEPT that:
i) the wording in the Options should be changed:
Runs in notification bar when inactive, and closes after X seconds
-->
When paused/inactive, run in notifications bar for X seconds then close. (part of the rationale for the change is in 0010808 )
ii) Appearance of MMA in the notifications bar is inconsistent, because the PlaybackService sometimes runs/doesn't terminate as expected:
 a) Sometimes as soon as MMA is started, pressing the 'home' button causes it to appear in the notification bar, but other times it doesn't. In such cases, pressing the 'Stop' button in the notifications bar has no effect in terms of terminating the app.
 b) It'll often _not_ appear in the notifications bar when the user has backed out of the application--even though both MediaMonkey and the PlaybackService are still running.
If these problems are resolved, then the Lock Screen Player would also work fairly consistently.

marek

2013-07-15 09:27

developer   ~0036852

Well I don't think that notification should serve these 2 requirements
re 1) Surely, this is the purpose of notification
re 2) I think that this is not task for notification bar. We shouldn't mix it with Windows Taskbar functionality. Notification doesn't show applications that are using some resources. The notification bar shows only some important actions that happen or are running(like playback).

Multitask manager (http://developer.android.com/sdk/images/3.0/tasks_full.png) serves this functionality. This is the right way how to switch between two applications. And when device have button for this action (they have software navigation bar or special hw button) it is even faster way.

Google music does not meet requirement 2 because it respects the android UI design.

I understand that it looks that we are close to desired behaviour. But this next step needs another deflection from our core application design and from android design...another small hack that might bring some issues (and bigger resources requirements). Simply because this behaviour is not supported in android design.

jiri

2013-07-17 09:19

administrator   ~0036882

Per IM discussion with Marek and Martin, here is the summary that should resolve all the unclear issues:

Individual cases:
1. MMA is running, playback service running -> Playback service shouldn't be terminated according to MMA Options, it should either run permanently, or for a rather long time (5 or 10 minutes?). (this currently isn't implemented this way and should be changed)
2. MMA is exited, e.g. using Home button:
 a. playback service already running, playback isn't running -> MMA icon in the tray and the playback service will keep running for time specified in MMA Options. (this is already supposed to work this way)
 b. playback service and playback running -> MMA will play until the end of tracklist, then wait for time per MMA options and close playback service. (this is already supposed to work this way and is actually very similar to a. above)
 c. playback service isn't running yet -> the behavior isn't clear, we could either:
  i) start the playback service and continue as in 2a.
  ii) don't do anything, don't show MMA icon in the tray. (currently works this way)
   I think that ii) might be preferable, since it's more resources friendly. Note also that according to my testing (and contrary to what Rusty wrote above), Player Pro also works this way, e.g. start of the app followed by the Home button doesn't result in an icon in the tray.

As for issues described by Rusty:
 a) Shouldn't happen, particularly in the next build with some more fixes from Martin.
 b) According to Martin might be caused by playback service not running, so it would probably be fixed by fixing 1. above.

As for the text change - agreed, it should be done.

martin

2013-07-17 16:17

developer   ~0036892

Fixed in build 151.

peke

2013-08-06 00:01

developer   ~0037105

Verified 156