It certainly appears as if the CTS doesn't properly exercise those
packages.
I think the only way this would improve is if Google put down its
foot, by setting a deadline for OEMs to confirm to the CTS or face the
denial of Google services. I bet these problems would be addressed
very quickly by the OEMs if that were the case.
On Jun 15, 3:41 pm, mort <m...@sto-helit.de> wrote:
> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment