Get rid of the file cache, since it tends to run out of memory for large
numbers of files. This slows down the scanner somewhat, but recent
optimizations more than make up for that.
With this change, the postscan phase of the media scan now only processes
playlists. Removal of entries for files that no longer exist is done as
part of the prescan.
Lookups in the file cache are replaced by simple queries, which are still
reasonably fast because of a new index recently added to the media provider
database. Note that there was a bug in the case-insensitive matching for
file cache entries, in that e.g. an uppercase a-accent-aigue would be mapped
to its lowercase version, whereas the underlying case-insensitive filesystem
treats them as different characters. Getting rid of the file cache also fixes
this issue.
Bug: 4474617
Change-Id: I39c6f1a35bb518ef7ab912e9b9401663821ef48e
Bring the Visualizer class into line with the SDK documentation by
returning ERROR_DEAD_OBJECT instead of ERROR_INVALID_OPERATION when
the Visualizer loses its binder connection to the mediaserver because
of a mediaserver restart.
Also add a new callback interface to allow clients to be
asynchronously notified in the case of server death. Right now, the
interface definition and the registration method are flagged as hidden
pending API council review/approval.
See http://b/issue?id=5717519 for details.
Change-Id: Ic15856f27ed5a950a583ac11ca81f79bd7e9b1a0
Signed-off-by: John Grossman <johngro@google.com>
Don't re-allocate buffers used by Visualizer callbacks as this causes an
unacceptable amount of GC thrash. Instead, lazily allocate the buffers and only
reallocate them when the required size changes.
See http://b/issue?id=5717519 for details.
Change-Id: Ibd157ed51f30687ce7c4ef0b4003258a484e0f5d
Signed-off-by: John Grossman <johngro@google.com>
A regression was introduced by the change enabling per device volume:
music volume will not be completely silenced even if volume is shown at 0.
The problem is that when media volume goes to zero, silent mode is entered and
AudioService sends one message per stream/per connected device to the audiosystem
handler to mute volume on each stream. As those messages were sent with the
SENDMSG_NOOP attribute, some of them where lost.
Change-Id: Ic665b1e9dcaf09506a4ec19bf3fe6997d4b071fd
Inserts of directories can be done in bulk as long as they're inserted before
the files contained within. Extend MediaInserter to accommodate giving priority
treatment to directories.
Bulk deleting of entries can be further sped up (by a factor of ~3 in my tests)
by deleting entries in database order. Switch the file cache to use
LinkedHashMap instead of HashMap to allow iterating over the cache in database
order. Also use bindArgs to allow for better caching of sql statements.
Change-Id: Ieb9ffc4e866c6cd505bf795eb80ff5d03ffc56bd
The use case for master mute is to toggle it on and off from a
KEYCODE_VOLUME_MUTE event, so this was unnecessary and prevented unmuting
in certain cases
Bug: 5724755
Signed-off-by: Mike Lockwood <lockwood@google.com>
This allows Music2 and other media apps to control master volume without changing their code
Bug: 5567694
Signed-off-by: Mike Lockwood <lockwood@android.com>
Still needs integration with Settings (for persistence) and VolumePanel UI.
Change-Id: I9eca92c4b1ef2df2564411006a35753ab9618dce
Signed-off-by: Mike Lockwood <lockwood@android.com>
Deleting entries from the database in bulk greatly speeds up the media
scanner in some cases; removing 31k entries used to take about 2 hours,
now it takes about 15 minutes.
Change-Id: Ia8f3fd6d828289e3d67178e9ad10399ded8d70d2
Added new API to enable cancelation of SQLite and content provider
queries by means of a CancelationSignal object. The application
creates a CancelationSignal object and passes it as an argument
to the query. The cancelation signal can then be used to cancel
the query while it is executing.
If the cancelation signal is raised before the query is executed,
then it is immediately terminated.
Change-Id: If2c76e9a7e56ea5e98768b6d4f225f0a1ca61c61
Don't automatically change the audio focus when
the audio mode changes. This is best handled by the
applications that change the audio mode so they
can address their usecases as they please (for
instance to define the behavior when switching calls).
Replaced the implicit "mode to focus" behavior with
two methods to request and abandon audio focus. These
methods are only to be used by the framework, and maintain
the logic in AudioService to prevent other apps to request
audio focus during a call.
A susequent change will update com.android.internal.telephony.CallManager
to take advantage of these two methods.
Change-Id: If84ebd508e985083e8cac82ece44940c72b5c669
Was a mix of audio_source_t, uint8_t, and int.
Related fixes:
- fix comments in MediaRecorder.java
- AudioPolicyService server side was not checking source parameter at
all, so if the client wrapper was bypassed, invalid values could be
passed into audio HAL
- JNI android_media_AudioRecord_setup was checking source for positive
values, but not negative values. This test is redundant, since already
checked at Java and now checked by AudioPolicyService also, but might
as well make it correct.
Change-Id: Ie5e25d646dcd59a86d7985aa46cfcb4a1ba64a4a
Improve volume management by keeping track of volume for each type
of device independently.
Volume for each stream (MUSIC, RINGTONE, VOICE_CALL...) is now maintained
per device.
The main changes are:
- AudioService now keeps tracks of stream volumes per device:
volume indexes are kept in a HashMap < device , index>.
active device is queried from policy manager when a volume change request
is received
initalization, mute and unmute happen on all device simultaneously
- Settings: suffixes is added to volume keys to store each device
volume independently.
- AudioSystem/AudioPolicyService/AudioPolicyInterface: added a device argument
to setStreamVolumeIndex() and getStreamVolumeIndex() to address each
device independently.
- AudioPolicyManagerBase: keep track of stream volumes for each device
and apply volume according to current device selection.
Change-Id: I61ef1c45caadca04d16363bca4140e0f81901b3f
Since the settings (notifications, ringtones, and alarms) request
rowId after inserting into DB, do not use bulk insert for them.
(Bulk insert does not return the rowId)
Change-Id: I8faf993f8ac2da96672594a1c92ddc917f964d6f
We need to close it explicitly after using it. Without this, fd will be closed
non-deterministically, and that will break the decode procedure.
Bug: 5808889
Change-Id: Icf9ff9abd6e327b122c6916df9750016b3d1b616
For historical reasons, messages to the AudioSystem
handler in AudioService have a complex identifier combining several information.
Messages for a particular stream contain the stream type as part of the message type.
This complexity is not needed as the stream messages also carry a reference to the
VolumeStreamState object which contains all necessary information, including the stream type.
Also grouped parameters of MSG_PERSIST_VOLUME message into a single bit field to make room for
further needs.
Change-Id: Ia27af626b3447541e8f9eaceba21389a824d88e2
