Some JPEG images generated by various camera vendors have wrong offsets
and invalid numbers for indicating the size of components. Instead of
throwing exceptions, this CL makes Exifinterface ignore these cases to
read the information without losing contents already parsed.
Bug: 27583378
Change-Id: Ie8ee0bf49283ef519f4f31c5b8ba78ce3f82fe92
One image can have multiple image file directories, which stores the
attributes of the image, in Exif specification to save metadata.
In the old version, the all attributes from several image file
directories were combined in a one hash map eventually and were served
without distinction of the original IFD group.
In order to keep the original data as much as possible, it loads/saves
the attributes based on the original IFD group internally.
Bug: 26044456, Bug: 11224701
Change-Id: I416e4e79fd47461c9aa83ce13591ed1a5d42f26e
The Context passed in has already been tied strongly to a specific
user, so resolve Settings based on that user.
Bug: 27568161
Change-Id: I1365c25f97c4177afe592d7c9f410eab777110e7
The readExifEntry method has raised an unnessary EOFException on reading
an non-ASCII byte array.
Bug: 27484747
Change-Id: I19371e0eed25770929f50b3ca25f249c50113925
And also the following things are included:
- Remove mInputStream.
- Update javadoc accordingly.
Bug: 11224701
Change-Id: I30b4c29ac800ae396fca8f6b2c2c0f68028a44b3
If MediaBrowser and MediaBrowserService are on the same process,
the options object could be shared.
Bug: 27398805
Change-Id: I61ce63f667e46229662d85cd6f417b104f9d1388
Below changes are included:
* Defer the buffer lock to Image#getPlanes call. This will save quite a bit
CPU cycles associated with lock buffer if the application doesn't really
want to access the data.
* Refactor the code: move some common code to some utility class, and use
one unified consumer (BufferItemConsumer) in ImageReader native implementation.
The code refactoring will also make it easier to support non-opaque image
attach/detach.
Bug: 22356918
Bug: 19962027
Change-Id: I4fb865b0ea3deb6650afc64c32a5906f30e8ccbd
This has been causing some confusion among streaming-based channel app
developers without having any clear benefit, hence drop the requirement.
Bug: 27536480
Change-Id: I51be65ccc402171a0ce34ae4640905ec48d39e37
- Documented what TvInputInfo.getTunerCount returns if the input is not
of TYPE_TUNER.
- Documented what all getters/setters in TvTrackInfo throw if not called
on proper types.
Bug: 27531254
Change-Id: I32d83ce888507ec29cda8dce74871a3d55783766
In package android.media:
- rename AudioRecordConfiguration to
AudioRecordingConfiguration to avoid ambiguity with the
android.media.AudioRecord class
- rename AudioManager.getActiveRecordConfigurations() to
getActiveRecordingConfigurations.
Bug 27385560
Change-Id: I5ef404ff36522193990c9b563d4545893529b365
RingtoneManager is the public API that everyone should be going
through, and it now has the side-effect of caching the set ringtone
to make it available before CE storage is unlocked.
Bug: 27435331
Change-Id: I30ed4e2df2ef1e4fd47f947c70845aaa74356384
When setting default ringtones, RingtoneManager now caches the
selected media for playback before the device is unlocked. However,
this API hasn't historically required the caller to hold storage
permissions.
To keep this working, we attempt to delegate ringtone access over
through RingtonePlayer, which is what we do for playback. However,
because we're caching the real ringtone bits now, we need to be much
more careful about the PFDs we're willing to return. This change
requires that they be in external storage, and that they have the
ringtone/alarm/notification bit set.
Bug: 27366059
Change-Id: I59c2adc1d1250a3eac281f190f35a7cb3119967b
In package android.media: rename AudioRecordConfiguration to
AudioRecordingConfiguration to avoid ambiguity with the
android.media.AudioRecord class
Bug 27385560
Change-Id: Ia633ac30cbe151b8f0f903dc96a459a56737ace2
Make AudioRecordConfiguration final since it is parcelable.
In AudioRecordingCallback, pass the array of active recording
configurations.
Add @IntDef for return values for
AudioRecordConfiguration.getClientAudioSource()
Bug 27385560
Change-Id: I01193577f50e50496742d888b45f89a2c3b67904
Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
