I've tested out the basic features and it looks good.
One thing that seems a bit different is the secondary progress (the light orange used for buffering) on seekbars. I only noticed because I just added this to DC for audio streaming but now the mediaplayer is always reporting 0 buffer progress, so no buffering progress is displayed. I think I read something in the 2.2 release notes about the streaming engine being replaced with another one. I'll keep digging into it though.
So far everything in DC seems to be working with Froyo except bluetooth, fast forward, rewind, pause and play.
As far as I can tell, the default music player, has control of those functions no matter what is playing, in the background or foreground.
All I use is the bluetooth headphones and I absolutely love this feature. No more digging around in the phone to pause, play, fast forward or rewind a podcast.
If you come up with a fix you would like me to test just let me know.
Thanks for letting me know, I hadn't tested this. I'll get the 2.2 source and see what's happening with the default music player. It may have snagged a priority that puts it in front of all other apps...I hope not.
yea.. i was just coming here to mention the same thing. I hope they made it (the buttons) available to other apps. I'd also like it if they could somehow add a short cut to the car dock app or that DC could somehow register for an icon there. I almost never use the music app and use DC all the time.
So the way it used to work (2.1 and earlier) is that applications declared that they wanted to receive a broadcast when the a button was pressed. The broadcasts were delivered in the order of the priority (declared by each app) and each app had the responsibility of deciding whether it wanted to handle the button press or not and also whether it wanted to let the broadcast propagate to the other apps that declared that they wanted the broadcast.
It doesn't work that way any longer (2.2). Applications tell android that they are the one that will receive the *single* broadcast. So the last app to tell android that they want the broadcast, gets it.
I've got something working so it reproduces the DC behavior on 2.1. It plays nicely with the android music app, but if another app gets installed that chooses to register for the broadcast and doesn't let you configure it to not register for the broadcast, there's not going to be a way for DC to respond to the button presses. We'll have to see how this goes and adapt as things develop.
I should be able to get this to the beta testers weds/thurs.
I've always been good with having to close DC in order to switch the media buttons to the music app. It sounds like if another application does register for the buttons, all we'd have to do is exit DC and then restart it to make it the last app to register.
This makes sense. Basically an app should respect my wishes - if i was last listening to the music app, it better receive my headset button events. Same with DC. So, whatever I used last should register itself, and catch the events.
the longer I play a podcast for in a continuous segment, the further back it'll be the next time I resume, sometimes as much as 10 minutes or so. I feel like it might have something to do with the program's perceived duration of the file, because the seek position seems a bit off too
I've completely re-written all my code around the media player to handle the changes in 2.2 media player. The beta testers haven't gotten it yet, probably within a week or so. If you want to join the beta group, you could see if it fixes the problem for you.
I think I found a bug. When I unplug my cassette adapter in the car, the sound mutes, but DC keeps progressing. When I plug it in again, the sound keeps playing.
It used to auto-pause on unplug in previous Android versions.
Does anyone else have this problem? Do you want me to send you a log?
Not a waste at all Karolis, if it happened, it's good to hear about it. The next time it happens, we'll know we have a pattern. It actually sounds like the new ducking audio feature in 2.2 when apps can take over the audio focus malfunctioned.
What the music app does is register every time you plug in the headset, I need to do the same thing, but afterwards (if you have bind to headset on). I'm not sure yet how the 2.2 approach improves on the older one, maybe there's something I just don't get yet.
I just updated my nexus one to froyo...looks like it's rolling out to n1 users now.
http://phandroid.com/2010/05/22/android-2-2-slowly-being-rolled-out-to-n...
I've tested out the basic features and it looks good.
One thing that seems a bit different is the secondary progress (the light orange used for buffering) on seekbars. I only noticed because I just added this to DC for audio streaming but now the mediaplayer is always reporting 0 buffer progress, so no buffering progress is displayed. I think I read something in the 2.2 release notes about the streaming engine being replaced with another one. I'll keep digging into it though.
So far everything in DC seems to be working with Froyo except bluetooth, fast forward, rewind, pause and play.
As far as I can tell, the default music player, has control of those functions no matter what is playing, in the background or foreground.
All I use is the bluetooth headphones and I absolutely love this feature. No more digging around in the phone to pause, play, fast forward or rewind a podcast.
If you come up with a fix you would like me to test just let me know.
Keep all of the great work.
Thanks for letting me know, I hadn't tested this. I'll get the 2.2 source and see what's happening with the default music player. It may have snagged a priority that puts it in front of all other apps...I hope not.
Create issue - http://mantis.snoggdoggler.com/view.php?id=512
yea.. i was just coming here to mention the same thing. I hope they made it (the buttons) available to other apps. I'd also like it if they could somehow add a short cut to the car dock app or that DC could somehow register for an icon there. I almost never use the music app and use DC all the time.
So the way it used to work (2.1 and earlier) is that applications declared that they wanted to receive a broadcast when the a button was pressed. The broadcasts were delivered in the order of the priority (declared by each app) and each app had the responsibility of deciding whether it wanted to handle the button press or not and also whether it wanted to let the broadcast propagate to the other apps that declared that they wanted the broadcast.
It doesn't work that way any longer (2.2). Applications tell android that they are the one that will receive the *single* broadcast. So the last app to tell android that they want the broadcast, gets it.
I've got something working so it reproduces the DC behavior on 2.1. It plays nicely with the android music app, but if another app gets installed that chooses to register for the broadcast and doesn't let you configure it to not register for the broadcast, there's not going to be a way for DC to respond to the button presses. We'll have to see how this goes and adapt as things develop.
I should be able to get this to the beta testers weds/thurs.
I've always been good with having to close DC in order to switch the media buttons to the music app. It sounds like if another application does register for the buttons, all we'd have to do is exit DC and then restart it to make it the last app to register.
This makes sense. Basically an app should respect my wishes - if i was last listening to the music app, it better receive my headset button events. Same with DC. So, whatever I used last should register itself, and catch the events.
Or, I should say I hear the same thing
since 2.2 it seems that when I resume a podcast, it will start about 10-20% earlier in the feed than where it left off.
the longer I play a podcast for in a continuous segment, the further back it'll be the next time I resume, sometimes as much as 10 minutes or so. I feel like it might have something to do with the program's perceived duration of the file, because the seek position seems a bit off too
Is this streaming or downloaded media?
Downloaded
I've completely re-written all my code around the media player to handle the changes in 2.2 media player. The beta testers haven't gotten it yet, probably within a week or so. If you want to join the beta group, you could see if it fixes the problem for you.
yeah that would be great, I'll report back if it works or not
I think I found a bug. When I unplug my cassette adapter in the car, the sound mutes, but DC keeps progressing. When I plug it in again, the sound keeps playing.
It used to auto-pause on unplug in previous Android versions.
Does anyone else have this problem? Do you want me to send you a log?
Yes, please do send a log.
I also use an audio adapater in the car with froyo but I haven't seen this problem.
Thanks.
http://mantis.snoggdoggler.com/view.php?id=513
Weird. I could not reproduce the issue. Might have been a one time glitch or maybe I just did something wrong and don't remember it properly.
Sorry for wasting your time.
Not a waste at all Karolis, if it happened, it's good to hear about it. The next time it happens, we'll know we have a pattern. It actually sounds like the new ducking audio feature in 2.2 when apps can take over the audio focus malfunctioned.
What the music app does is register every time you plug in the headset, I need to do the same thing, but afterwards (if you have bind to headset on). I'm not sure yet how the 2.2 approach improves on the older one, maybe there's something I just don't get yet.