This is mostly sharing some experiences, maybe it helps some others. I
don't really expect anything will change by telling this...
Oh, and it's not about the Android version "fragmentation", though
it's pretty bad to see that the majority of users isn't able to use an
important feature, just because the manufacturers either need ages to
offer an update or won't offer one at all. But that's another sad
story.
It all started with the introduction of the AudioEffects (Equalizer,
BassBoost, ...) in Gingerbread. I offer an audio player which uses
Android's playback routines, and many users cried for an equalizer, so
I implemented support asap. While it was pretty simple to differ
between "old" and Gingerbread devices, and the app worked fine on the
emulator and a while later on my Nexus S, things went bad with going
public.
The first problem that occured was as simple as effective: "new
Equalizer(...)" (or any other AudioEffects derivate) caused exceptions
to be thrown by several devices (UnsupportedOperation, NullPointer,
InvalidState, ...). In the beginning, this usually were custom ROMs,
where the implementation was incomplete, but nowadays it even happens
with some official ROMs. So I did a "test construction" and don't
offer the effects if the construction fails. This covers most
problems, though some rare devices/ROMs still crash completely (i.e.
require battery removal) just by a simple and correctly used object
creation...
The next problem was that some devices crashed or did weird things
(such as not responding to volume buttons or draining battery) when an
AudioEffects instance was created but not enabled and something was
played. So I had to create and release the instances as required
instead of just using setEnabled. Sure, better for memory usage
anyway, but it complicated the handling quite a bit.
This seemed to work for a while, but then some people reported the
effects won't work any longer after a track change. I use the effects
this way, which seemed to fit the description (simplyfied):
mp = new MediaPlayer();
equalizer = new Equalizer(0, mp.getAudioSessionId());
equalizer.setEnabled( true );
// some more equalizer initialization
while ( filesInPlaylist ) {
mp.setDataSource( file );
mp.prepare();
mp.start();
// wait with OnCompletionListener
mp.stop();
mp.reset();
}
equalizer.setEnabled( false );
equalizer.release();
mp.release();
Now it seemed like MediaPlayer.reset() resets the "attached" audio
effect instances on those devices. So I tried to work around this by
re-initializing the audio effect data (usePreset or things like that)
after each reset. This caused crashes on some devices, because
seemingly they not only reset the data but destroyed more. So the next
step was to release and recreate the instances on each track change.
This was a really bad idea. While it worked great on some devices,
others froze completely or did other weird things. The only thing they
didn't do was thowing an exception, so there wasn't an automatic error
report... Currently I hope this is only because I didn't think
"setEnabled(false)" was required before "release()", but I'm afraid
there's more to it... Probably I'll have to remove the workaround
because it triggers more problems than it solves.
Another problem, where I can't do anything about it, are really crappy
implementations of the audio effects. Even if there are no bugs
causing crashes, simply enabling something as simple as a bass boost
dramatically slows down some devices, sometimes even causing stutter,
and drains the battery in no time. I'm a bit at a loss how it's
possible to do this even to devices with 1GHz or more and a sound chip
which likely would support DSP.
When I switched from Windows Mobile, which had similar manufacturer
messups, I hoped this would become better with Android's unified and
powerfull API. Obviously, I was wrong. Even a clearly defined API can
be implemented in lots of buggy ways...
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
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
