Add support for Motorola's Connected Music Player (CMP)

[GoogleCodeExporter]

This is the "new" Motorola media player, and it is available in several 
devices, as the Motorola Charm and Cliq XT.

Here is some information: 

http://downloadsquad.switched.com/2011/01/26/motorola-connected-music-player-for
-android-is-packed-with-aweso/

http://www.droid-life.com/2011/01/24/download-new-motorola-music-player/

Original issue reported on code.google.com by leonardo...@gmail.com on 16 Jun 2011 at 11:01

[GoogleCodeExporter]

I'm currently working on this.

Chances are very good that it will work with CMP 1.1.59 (the one that comes 
with the 2.2 update).
I doubt that older versions of CMP will be supported.

Original comment by darkligh...@googlemail.com on 17 Jun 2011 at 1:21

[GoogleCodeExporter]

It would be great if you could at least add support for Android 2.1, as there 
are lots of devices in Latinamerica with 2.1 that won't be updated because of 
the carriers.

Would you mind commenting why wouldn't 2.1 be supported? Is there any lack of 
API or something preventing it?

I could help to test, debug or even patch, if needed... with some guidance.

Regards and thanks for the quick reply to the issue above.

Original comment by leonardo...@gmail.com on 17 Jun 2011 at 2:39

[GoogleCodeExporter]

I had a look at CMP 1.0.179 (which is probably what comes with 2.1).
Unfortunately (as you already mentioned) it's missing a tiny broadcast intent.

With the newer CMP version you get a broadcast for an action called 
"com.android.music.metachanged".
The Motorola/TuneWiki guys were smart as the stock Android music player uses 
the same intent.

Maybe you can get the newer CMP working on Android 2.1?

Regarding my patch:
I'll attach it later, as I want to do some testing on my own first.

Original comment by darkligh...@googlemail.com on 17 Jun 2011 at 12:56

[GoogleCodeExporter]

My patch seems to work fine so far, so here it is.

The version I tested is: "CMP_AmazonFR_InternalFM_DataWarn_1.1.59".

Original comment by darkligh...@googlemail.com on 17 Jun 2011 at 1:52

Attachments:

• asls_cmp.patch

[GoogleCodeExporter]

In case my previous patch doesn't apply correctly, here's the fixed one.

Original comment by darkligh...@googlemail.com on 17 Jun 2011 at 2:06

Attachments:

• asls_cmp.patch

[GoogleCodeExporter]

Awesome! Short, well-formatted and clean, I like it.

A few questions:

CMP seems to use almost the same broadcast intents as the Android Music Player. 
Why didn't that receiver work? (Was it because of the new intents, or because 
the id wasn't an integer or a long, or something else?)

From the code I see a potential problem: com.android.music.metachanged should 
be received by both the AndroidMusicPlayerReceiver and The 
ConnectedMusicPlayerReceiver (right?). Doesn't this cause problems on your 
phone? Why not?

After discussing this I'd be more than happy to include the patch in SLS.

Original comment by tgwizard on 18 Jun 2011 at 5:49

• Changed state: Accepted
• Added labels: Type-MusicApp

[GoogleCodeExporter]

CMP uses a String for the ID, that's why I had to change the code in 
BuiltInMusicAppReceiver.

When I start your app and go to the supported players screen it tells me that 
it found both, CMP and the android music player.
But it clearly states, that the android music player is not installed.

I manually disabled the android player.
Maybe players that were detected but that are not installed should be 
"disabled" by default?

Original comment by darkligh...@googlemail.com on 18 Jun 2011 at 5:54

[GoogleCodeExporter]

Unfortunately that is a problem, since lots of music apps use the Android Music 
intents to scrobble through SLS, and the install check is only made for 
com.android.music.

A separate issue, which I plan to fix soon, is that in newer versions of 
Android Msuic Player the id sent with the broadcast is not an id to the 
MediaStore, so it cannot be used like this. Other players use it that way 
though, but this can easily be configured.

Anyway, perhaps the simplest solution is to remove your 
ConnectedMusicPlayerReceiver and add these:
<actio android:name="com.android.music.playerstopped" />
<action android:name="com.android.music.playerpaused" />
<action android:name="tunewiki.intent.action.PLAYLIST_FINISHED" />

to AndroidMusicReceiver?

(Perhaps not the tunewiki intent, as that might cause duplicate receives.)

What do you think?

Original comment by tgwizard on 18 Jun 2011 at 6:07

[GoogleCodeExporter]

Sounds like a good idea.

OK, to sum it up, this is the plan:
-(your part?) add code makes the "Android Music Player" receiver more flexible 
so multiple app packages can be given
-Add the "com.android.music.playerstopped" and "com.android.music.playerpaused" 
actions to the AndroidMusicReceiver

I will check if "tunewiki.intent.action.PLAYLIST_FINISHED" is important.
What should we do if it is?

One more question:
What to do with the pause intent?
Should we implement code for this in the AndroidMusicReceiver?

Oh and before I forget: only the "com.android.music.metachanged" action brings 
an ID in it's bundle.
All other actions don't have any extras (they also don't supply 
artist/track/etc).
This will cause BuiltInMusicAppReceiver to choke (due to "null track values").
This was the real reason why I started a new class (as I could work around such 
things easily without breaking existing code :)).

If you want I will make all necessary changes (once we've discussed all 
problems) and upload a new patch once I'm done.

Original comment by darkligh...@googlemail.com on 18 Jun 2011 at 6:22

[GoogleCodeExporter]

If you'd submit a patch that fixes this, that'd be great.

As to the id-stuff, you can do something similary as in the 
ScrobbleDroidMusicReceiver. The actual track info is only needed when a new 
song starts playing.

Original comment by tgwizard on 18 Jun 2011 at 6:28

[GoogleCodeExporter]

Here's my updated patch.

I also refactored ScrobbleDroidMusicReceiver to use the new 
BuiltInMusicAppReceiver API but I did *NOT* test it (due to the lack of a 
working player)!
You can simply ignore the changes in the ScrobbleDroidMusicReceiver class, 
those are just optional (and everything else will work just fine without those 
changes).

CMP still scrobbles fine, even though it shows up as "Android Music Player" 
(This app is not installed).

Ignoring "tunewiki.intent.action.PLAYLIST_FINISHED" makes "Also on playlist 
finish" not work. But that should not be a big problem.

It would be nice if you could test this patch on your device before committing 
it.
Feel free to ping me if there are any problems :)

Original comment by darkligh...@googlemail.com on 19 Jun 2011 at 1:27

Attachments:

• asls-cmp-v2.patch

[GoogleCodeExporter]

I'm working on some unit tests that will help make sure that changes don't 
break existing functionality. When I've completed enough of them, I'll add your 
patch.

Original comment by tgwizard on 20 Jun 2011 at 5:53

[GoogleCodeExporter]

Hi, I've moved the project to github, https://github.com/tgwizard/sls. Could 
you please add the issue there instead?

Sorry that nothing has happend on this. If you do a pull request with the 
changes (on github) I'll incorporate it and release a new version.

Original comment by tgwizard on 28 Jul 2012 at 10:37