In this first cut, a raw parcel is parsed to check that the overall
format is correct.
At the same time, we record the metadata seen and their position in
the parcel for later retrieval using the get* methods.
This means that the 'has' method to check the existence of a metadata
should work.
Removed size and iterator methods. Instead, I added a new method
to give access to the set of keys. The user can make use of the set
to call size(), empty(), iterator() etc...
* changes:
add a ctor to Mutex to specify the type, which can be shared. This is used by sf and af an soon will allow some optimization in the kernel for non shared mutexes
IMediaPlayer.h
Added a getMetadata method that mirrors the on in MediaPlayer.java.
MediaPlayer.java
Added a native method to get the metadata from the native player.
Parse the parcel into a Metadata object.
Metadata.java
Added a stub to parse the Parcel returned by the native player into
a set of metadata.
android_media_MediaPlayer.cpp
JNI call to forward the getMetadata call.
MediaPlayerService.cpp
MediaPlayerService::Client implements the new getMetadata method added in IMediaPlayer.h
Merge commit 'b799616d8f0f94e866767fa730f56d82543fb49b'
* commit 'b799616d8f0f94e866767fa730f56d82543fb49b':
Move ExifInterface to android.media package so we can reference it from MediaScanner.
IMediaPlayer:
new setMetadataFilter method so set a filter (2 lists of allowed and blocked metadata type)
serialized in a Parcel.
MediaPlayer.java/android_media_MediaPlayer.cpp/mediaplayer.cpp
new setMetadataFilter that passes the filter down to the MediaPlayerService's binder interface.
MediaPlayerService.cpp
The Client inner class holds the allowed and blocked metadata types.
These are in 2 vectors that get populated in the setMetadataFilter.
A new shourldDropMetadata method returns true if a type of metadata should be dropped according
to the filters.
The notify method in run the metadata update notifications thru the filter and possibly drop them.
The cause is very likely that the WaveGenerator *lpWaveGen returned by lpToneGen->mWaveGens.valueFor(lFrequency) just before calling lpWaveGen->getSamples(lpOut, lGenSmp, lWaveCmd) is invalid. The frequency lFrequency is not part of the frequencies in mWaveGens.
This can happen if a different tone is started while the callback function is active: The state is changed to TONE_RESTARTING and the call to prepareWave() at line 1226 will change the tone descriptor pointed to by mpToneDesc as well as the content of mWaveGens. However, mpToneDesc was cached in a local variable lpToneDesc when entering the callback and is not reloaded when exiting prepareWave(). This causes a mismatch between the tone frequencies listed in lpToneDesc and the frequencies present in mWaveGens.
This regression was introduced in change 973 when mpToneDesc was cached in a local variable.
* changes:
Move ExifInterface to android.media package so we can reference it from MediaScanner. Also hide public constructor and wrap common use cases as atomic operation to avoid race condition in jhead native codes.
MediaPlayer.java
New method getMetadata to fetch metadata from the player.
New method setMetadataFilter to filter metadata notification and fetches.
Metadata.java
Added basic interface. Implementation incomplete.
Merge commit 'e9ac96f76d513d2cee50dfea7d70b14669643ba9'
* commit 'e9ac96f76d513d2cee50dfea7d70b14669643ba9':
Fix issue 1967295: Add a method to request reloading of audio settings by AudioService.
Merge commit '88e209dcf8c2ebddda5c272f46d1bd5478bc639c'
* commit '88e209dcf8c2ebddda5c272f46d1bd5478bc639c':
Fix issue 1743700: AudioTrack: setPlaybackRate can not set the playback rate to twice of the ouputSR
Store sample rate on 32 bits instead of 16 bits in audio_track_cblk_t.
Removed sampleRate() methods from AudioTrack and AudioRecord: replaced by getSampleRate().
AudioTrack::setSampleRate() no returns a status.
Merge commit 'ef1f21b34f5624adb7436d3da927660ed16c97c7'
* commit 'ef1f21b34f5624adb7436d3da927660ed16c97c7':
Don't trim() in the mediascanner, as that would remove the special "sort first" character.
Merge commit '2f8d58b7ae2b9dc60eed83e5dddc8c28223e1ede'
* commit '2f8d58b7ae2b9dc60eed83e5dddc8c28223e1ede':
Added two test cases to trace the failure in closing the hw decoder and the current playtime is greater than the duration.
Merge commit '2d9f31697fb5ece89c80cc66bdd3bd9caa9df9c3'
* commit '2d9f31697fb5ece89c80cc66bdd3bd9caa9df9c3':
We might try to close the Vorbis file twice under certain
Merge commit '3d7b8d1aa6a362292f56defbe8fb2d5653f79282'
* commit '3d7b8d1aa6a362292f56defbe8fb2d5653f79282':
Use a ref-counted callback interface for Camera.
Merge commit '9efba9d29f32daf1b6ee6485bae6764ab24f04e9'
* commit '9efba9d29f32daf1b6ee6485bae6764ab24f04e9':
Export the output to a text file and save to sdcard
MediaPlayer.java has 3 new methods:
* newRequest creates a Parcel that can be used to send data to the
native player using invoke.
* invoke issues synchronous calls to the native player using opaque
parcels for the request and reply.
IMediaPlayer.h has 1 new abstract method:
* invoke
The Midi and Vorbis players have a stub for these. So far only PV
makes use of that new feature.
To avoid any copy overhead, the JNI interface uses Parcel as a java
object (no serialization/copy happens at the JNI layer).
The remote interface token is inserted when the Parcel is constructed
in java. That way the parcel is already routable when it reaches
IMediaPlayer.cpp (proxy). No extra copy is needed there.
This allows the camera service to hang onto the callback interface
until all callbacks have been processed. This prevents problems
where pending callbacks in binder worker threads are processed
after the Java camera object and its associated native resources
have been released.
Bug 1884362
Merge commit '1bee98af6532eba3c6cda636eee890530c95a2a7'
* commit '1bee98af6532eba3c6cda636eee890530c95a2a7':
Fill in CDMA gaps and clean up ToneGenerator code
Merge commit '843f5eb36a67367ae76800f74e184f00af50ef54'
* commit '843f5eb36a67367ae76800f74e184f00af50ef54':
Rollback the number of loop in the memory stress test
The android.hardware.ICamera string have not been changed (but is looks
like the camera service and client one should undergo the same procedure)
The implementation of the interface must provide a unique string for
it's interface name. Currently all these strings in the media framework
start with 'android.hardware' when it should really be 'android.media',
the interface token has nothing to do with hardware.
