The visualizer enables application to retrieve part of the currently playing audio for visualization purpose.
It is not an audio recording interface and only returns partial and low quality audio content as a waveform or
a frequency representation (FFT).
Removed temporary hack made in MediaPlayer for animated wall papers based on audio visualization (snoop() method.
This commit also includes a change in AudioEffect class:
- the enable()/disable() methods have been replaced bya more standard setEnabled() method.
- some fixes in javadoc
Change-Id: Id092a1340e9e38dae68646ade7be054e3a36980e
Simple API for tracking .obb files associated with packages. Stores the
path in the PackageSettings. No verification of file content is done
now since the PackageManagerService can't read the SD card where these
files will likely live.
Change-Id: Ibeaf26ba0526b6d60f401137e58f46ee9faff39e
Removed old input dispatch code.
Refactored the policy callbacks.
Pushed a tiny bit of the power manager state down to native.
Fixed long press on MENU.
Made the virtual key detection and cancelation a bit more precise.
Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
This allows us to avoid exposing the file descriptor of
the event queue; instead, you attach an event queue to
a looper. This will also should allow native apps to be
written without the need for a separate thread, by attaching
the event queue to the main thread's looper and scheduling
their own messages there.
Change-Id: I38489282635895ae2cbfacb88599c1b1cad9b239
Merge commit '7df7447112371fb5e46f6084b55ac2ccdfde139d' into gingerbread
* commit '7df7447112371fb5e46f6084b55ac2ccdfde139d':
Flush binder buffer after setting raw heap to avoid leaking a reference.
The problem was:
1. In handleShutter(), thread A in CameraService calls
registerBuffers(IMemoryHeap) and it's received by thread B
in system_server. [transaction 1]
2. While thread A is waiting for the reply, thread B calls
back to thread A to get the id of the heap
(IMemoryHeap.getHeapID). [transaction 2]
3. Thread A replies transaction 2 and is preemptied in kernel.
Thread B gets the reply and finishes registerBuffers and send
reply for transaction 1.
4. When thread A runs again, it gets the reply for transaction 1
and returns to handleShutter().
5. At this point the transaction buffer for transaction 2 (which
holds a reference to IMemoryHeap) is not freed because the
BC_FREE_BUFFER command is kept in thread A's local command
queue and not sent to the kernel.
6. Normally when thread A makes next transaction, the
BC_FREE_BUFFER command will be sent together (piggyback) with
the commands for that transaction. But in this case thread A
is a callback thread from camera driver, so it does not make
any binder calls afterwards, and the IMemoryHeap is never freed
(until the next time handleShutter is called).
Change-Id: I435a258187509bdbbaf353339eb9ea577610cbd2
When inflating a notification's view fails, include the exception in
the log message. Without this exception all we get is "couldn't
inflate view for notification <package>/<id>", which isn't very
helpful for tracking down the particular error in the view.
This exception used to be included in the log message, but it was
removed in 005847b03b2 -- any particular reason why?
Change-Id: I623b9e4c8291e4c035f26380e5f22ad6b65176a7
Merge commit 'c03befe3d62eb2a3e1d56fec0ca188a6094d53dd' into gingerbread
* commit 'c03befe3d62eb2a3e1d56fec0ca188a6094d53dd':
Fix issue 2811538: System server crash when disconnecting BT headset after using SCO off call.
Problem:
When the bluetooth device is removed, the AudioService clears all active SCO connections
and unlinks from the client application's binder interface death.
The problem is that the unlinking is done even if no more connections are active for a given client,
which throws a runtime exception that is not catched causing the system server to crash.
The fix consists in calling unlinkToDeath() in ScoClient.clearCount() only if the number of
active SCO connections for this client is not 0. The NoSuchElementException exception is also
catched when calling unlinkToDeath()
Change-Id: I7086424301fc63a5666da61c38169349d3e078f4
Can be accessed through PowerProfile.getBatteryCapacity()
Individual device profiles need to be updated with their capacities.
(merged from master)
Change-Id: Ie76ab6de47c44807a46934331665e077a7226566
Problem:
When the bluetooth device is removed, the AudioService clears all active SCO connections
and unlinks from the client application's binder interface death.
The problem is that the unlinking is done even if no more connections are active for a given client,
which throws a runtime exception that is not catched causing the system server to crash.
The fix consists in calling unlinkToDeath() in ScoClient.clearCount() only if the number of
active SCO connections for this client is not 0. The NoSuchElementException exception is also
catched when calling unlinkToDeath()
Change-Id: I29a28fcce1a579217cea271956a55778e05d3e37
The guard is compiled out by default because it adds overhead to
android.os.Process.setPriority().
Change-Id: Ibb2a648c6349b381abb7ae62a358888b04fba871
On omap3 h/w we force opaque formats to RGB_565 instead of RGBX_8888
because the GL driver doesn't support it. RGBX_8888 is always remapped
to RGBA_8888.
Change-Id: I0bfabeb98c8d3a399079e6797cf2a0ee95915324
