You want some code like this to play from raw resources:
AssetFileDescriptor afd = getResources().openRawResourceFd
(R.raw.test);
if (afd != null) {
mp.setDataSource(afd.getFileDescriptor(), afd.getStartOffset(),
afd.getLength());
} else {
throw new IOException("Unable to open test file");
}
I don't quite grok what you want to do with the music player. Is your
app in the foreground while the music player is in the background? If
so and you aren't using any elements of the music player UI, why not
just create your own music player inside the app that you can control?
There is a headset button interface you might be able to inject events
into to get the music player to pause and resume if you have to go
that way to get the UI. It's not going to give you very fine-grained
control over timing.
If the user is on a call, your application does not have focus and you
should not be doing anything. That said, the user could bring your app
to the fore while on the call and start playing with it. My view on
that is to let them do it, so we allow users to pull up YouTube or the
music player and use them while still on the call. There is an API to
detect if the ringtone is playing or the user is on a call - I believe
it's in android.media.AudioService, but I could be wrong.
We're working on improved docs for the media framework. Generally,
there's a pretty strict regiment you have to follow to get from a new
MediaPlayer object to the playing state:
MediaPlayer m = new MediaPlayer();
m.setDataSource(uri);
m.setAudioStreamType(streamType);
m.prepare(); // or prepareAsync() and wait for OnPrepared to fire
// setDataSource and setAudioStreamType are no longered allowed unless
after reset()
// getDuration, getCurrentPosition, setLooping, setVolume, isPlaying
are all valid now
m.start();
// now you can also pause, start, seekTo (paused or playing), and
stop.
reset() is valid in any state, though we have a bug in RC30 if you
haven't take a media player to prepare state, the app thread will
deadlock in reset(). Will be fixed in a release soon.
Hope this helps.
On Dec 10, 6:01 pm, Greg <[EMAIL PROTECTED]> wrote:
> I've been googling and searching the groups for answers and haven't
> been able to find anything concrete. I have several questions
> regarding the use of MediaPlayer if somebody can help me out:
>
> 1. I need to package an audio resource with my application, which I
> have done in /res/raw. However, it appears that I must use
> MediaPlayer.create() to use a resource ID rather than
> MediaPlayer.setDataSource(). I found some references to creating a
> URI to raw via "android:resource://package/raw/name" and
> "android:resource//package/" + resourceId. However, both of these
> tries resulted in IOExceptions during setDataSource. I'm assuming due
> to a bad URI. Is it possible to get a valid URI in SDK 1.0 that will
> point to a raw resource?
>
> 2. I'm writing an app that does some tracking and will typically go
> hand in hand with the music player running. Part of my app will, at
> times, need to play sound on top of the running audio stream. Is
> there any way for my app to get ahold of and temporarily pause the
> music stream so that the user will be able to clearly hear my audio?
> Is this prevented because it's considered 'bad behavior'? (I hope not
> because in my case its actually good and desirable behavior)
>
> 3. I see that I can set the audio stream but is there any
> documentation/discussion/details on what the various streams are, how
> they are used, and how they interact with one another? For example,
> as mentioned above I want to be able to pause/override/interrupt a
> music playing stream with my notification but I would NOT want to have
> my notification play if they are on an active phone call. Also, is
> there any doc/discussion/detail on which methods can be invoked on the
> mediaplayer at what times? As I experiment I seem to get a lot of
> 'invalid media state' errors when I try things with very little
> indication as to what state it is in and how I get it from the bad
> state to an acceptable state for the method in question.
>
> Thanks for any assistance. I've been researching for a couple of days
> but all the information I can find is very sparse or appears to be
> things that were valid in early SDKs but may not be any longer.
>
> Thanks,
>
> Greg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
