The old way actually mis-used the API (I misunderstood the docs) because
it specified the marker position as a "low buffer watermark" but instead of a
future playback head position.
The replacement is a simple thread that writes the data regardless of the
filling level of the buffer (write() will just block) and polls the playback
state periodically.
Change-Id: If29237cee4ce78dc42f5a8320878bab0cafe78f7
Reviewed-on: http://gerrit.rockbox.org/422
Tested-by: Dominik Riebeling <Dominik.Riebeling@gmail.com>
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
Sometimes (and perhaps only on some devices) Android's YesNo dialog
loses focus and is put to the background. Since the native code waits on the
result (which is then impossible to happen) it would become impossible
to further control Rockbox. This is an attempt to fix as I cannot reproduce
the problem on my device(s).
Change-Id: Iff849ff4be5e8f41922fb7d36491d860486c6441
3f4be75 introduced this regression where the back button stopped working
as intended. Explicitely request the focus on the RockboxFramebuffer
object to fix.
Change-Id: Ibc67e3d02e076674a086d43c5967370c4524fd14
* rename some java methods (to update(), initialize())
* re-create the ByteBuffer object from the framebuffer on every update.
This is needed now since 2c71aa9 added the possiblity for lcd_framebuffer to change.
* do so, along with the creation of the dirty Rect object, in native code.
Change-Id: Id39ea8e4b6148987c5f216a87e0ff3c8e7babe92
BitmapFactory.decodeFile() fails when called outside the main thread.
Work around by running the code on the main thread. This also has the advantage
of off-loading from the Rockbox thread which should improve track skipping
delays.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30825 a1c6a512-1295-4272-9138-f99709370657
Instead of showing the small Rockbox clef logo show the Album Art if available.
If no Album Art is available show the clef logo about the same size as the
Album Art.
- The notification area process doesn't have permissions to access the SD card.
Therefore the image needs to be read and set as Bitmap instead of simply
setting the Uri to it as done in the widget.
- Passing a full sized image to the Notification Manager can cause issues
(Rockbox UI hanging, notification not updating anymore, force closes). Scale
down the image to the same size the launcher icon has to avoid this. This
also makes the logo shown when no Album Art is available have the same size
which looks nicer than having different sizes. Album Art images are allowed
to be wider since there is enough room.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30629 a1c6a512-1295-4272-9138-f99709370657
On the first start Rockbox extracts libmisc.so which in fact is a zip file
holding resource files like theme bitmaps. Those can requires quite a bit of
memory.
As extended version of FS#12063 resources will now be extracted to SD card if
the file /sdcard/rockbox/rockbox-info.txt is found. This file is part of the
extracted resources and can therefore safely be used for checking.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30430 a1c6a512-1295-4272-9138-f99709370657
Making a JNI call from tick tasks is not permitted as the underlying thread
is not attached to the Java VM. This is an error and crashes in the emulator
(which has stricter JNI checks enabled by default).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30173 a1c6a512-1295-4272-9138-f99709370657
Restore pre-r29562 way of doing compatibility and adapt
it to what MediaButtonReceiver looks like. I.e. assume the new API is there,
and fall back to the old API if an exception is raised because the API isn't there.
The old API still needs to be discovered through reflection because it's removed
entirely from Honeycomb.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30165 a1c6a512-1295-4272-9138-f99709370657
* Cleanup RockboxService.java by moving the battery and
headphone monitors to separate classes and detaching their instances
* Move those monitors and RockboxTelephony.java into a new
monitors subdirectory
* Call those monitors all the same from native code by creating
the objects there
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30160 a1c6a512-1295-4272-9138-f99709370657
Android restarts services that are killed during memory pressure.
The intent parameter is null then. This caused a null pointer exception.
Now replace this null intent with one saying we've been restarted.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30156 a1c6a512-1295-4272-9138-f99709370657
It's not enterly clear what fixed it but it seems to be a combination of
increasing the buffer size and reducing the amount of code run in the callback.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29961 a1c6a512-1295-4272-9138-f99709370657
This event is sent before the audio is routed back to the speaker so we
get the information about the unplugged headphone notably earlier.
Decrease the debouncing of the headphone status from 1s to 0.5s to work
around audio still getting played back via the speaker due to the pause
delay by debouncing. On Android we shouldn't need the debouncing at all.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29957 a1c6a512-1295-4272-9138-f99709370657
Listen to headphone plug events. There are currently two glitches with this:
- Android takes a while until it reports the unplug event, so there will be
some delay until playback gets paused. This is an Android limitation.
- Rockbox debounces headphone state changes for one second. Therefore playback
will shortly be routed to the speaker on unplug until Rockbox does the actual
pause.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29956 a1c6a512-1295-4272-9138-f99709370657
* Get rid of reflection since the lack of methods can be detected via exceptions
* Use requestAudioFocus/abandonAudioFocus APIs on 2.2+ to play nice with other music apps.
* Don't unregister the receiver on exit so we can receive media button presses (and startup the service) after idle poweroff (hopefully it's ok if mMediaButtonReceiver is garbage collected)
This should fix that Android calls the standard music app sometimes when those buttons are pressed.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29865 a1c6a512-1295-4272-9138-f99709370657
Technically, the difference between stop and pause isn't important enough to keep it when no music is playing. This is how other media apps also act.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29405 a1c6a512-1295-4272-9138-f99709370657
* Re-create RockboxFramebuffer instance with every time there's a new Activity.
* Also, allow Rockbox to be started via multimedia buttons, immediately starting playback if wanted.
We don't need to keep the fb instance around when it backround, and it makes us less depending on it and the activity (less race conditions). And this is how you usually do it in Android apps.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29384 a1c6a512-1295-4272-9138-f99709370657
That enables drawing from outside the apps UI thread, i.e. from within the Rockbox native thread, without needing synchronization means, and adds determinism as to when the draw happens.
It simplifies the drawing routines and adds a convinient way of detecting whether drawing should happen or not (surfaceCreated/Destroyed).
It also restores max. fps on my phone which went down drastically with the gingerbread(CM7) update.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29333 a1c6a512-1295-4272-9138-f99709370657
