GitLab

Bug: 26928703
Change-Id: I871e3346bfe23dfccf6635d7318ae8e4e48a9741

used. Related feature was removed from DocumentsUi.

Bug: 26829518
Change-Id: I3131c14f1de8b354b9c3a4b7598d87e3ad314152

If you want to observe media changes with the job scheduler, we'd
like to give you details of the files that changed when possible.
However, MediaProvider was only reporting the containing path of
a change, not the actual URI that changed.

Fix this by now reporting the newUri when doing an insert.

There is a comment in there about whether we should continue also
reporting the parent URI.  I am not sure what to do about that.

Change-Id: I03667c4466bde933cf2e04f8aca85eac913609f7

Bug: 22958127
Change-Id: I7aae9b0271d0331ce8b6670b76379e6ab20a76cb

Bug: 20953950
Change-Id: Ic20807acabc542fe388efc89c236a7e68b0e2671

Wrap the update/delete commands in an sql transaction so
they both either succeeds or fails. The problem adressed
here is that the MediaProvider may be interrupted while
handling the ACTION_MEDIA_EJECT intent and only the
update may have happened. This leads to numerous weird
problems later when _data contains unexpected null posts
causing crashes with stacks like:

  java.lang.NullPointerException: Attempt to invo\
  ke virtual method 'char[] java.lang.String.toCh\
  arArray()' on a null object reference
	at java.io.File.fixSlashes(File.java:185)
 	at java.io.File.<init>(File.java:134)
 	at com.android.providers.media.MediaProvider.\
    getCompressedAlbumArt(MediaProvider.java:4836)
 	at com.android.providers.media.MediaProvider.\
    makeThumbInternal(MediaProvider.java:5005)
 	at com.android.providers.media.MediaProvider.\
    getThumb(MediaProvider.java:5001)
 	at com.android.providers.media.MediaProvider.\
    openFile(MediaProvider.java:4591)
 	at android.content.ContentProvider.openAssetF\
    ile(ContentProvider.java:1322)

The problem can be reproduced on a device with external
SDCard by inserting a Thread.sleep(10000) between update
and delete and then just power of the device normally.

Change-Id: I2c104958dbe4e300aa80abedc4d44e0d77495180

Now that we're putting the media roots up front and center through
the Settings > Storage UI, users have an expectation of deleting
media to free up disk space.

Bug: 24450605
Change-Id: I38e1b021db2bf1f42a43f81f609818df905a0c0b

Previously, MediaProvider would only create default directories once
during the lifetime of a device.  However, we're now regularly wiping
storage devices when formatted as internal or portable, so we should
create these directories the first time we encounter each device.

Bug: 23329611
Change-Id: I71f8e9b47ad28c9883925c61f31ae61a070cc9b4

Devices that use physical media as their primary storage may not
have that storage mounted by the time that MediaProvider is started,
which means we'd snapshot a stale primary storage path.

To fix this, refresh those paths as volumes are mounted or unmounted
over time.  Also fix logic that detects secondary storage devices.

Bug: 22629557
Change-Id: I3c6b057ce082318e1b28e261c953a436da42e36f

The media provider can call into the downloads provider which
runs in the same process from an IPC. In this case the
permission and ap ops checks in the downloads provider will
be verified against the caller of the media provider instead
of against the media provider itself.

bug:22629557

Change-Id: I444a2db96353f50c60cd1d7bb20538ab7d463a1e

Bug: 22519119
Change-Id: I8aff294201dfd8ec46ff3d30e4ceecea1346f29b

Bug: 22753582
Change-Id: I73f3e8b7bc3fabab92909a183fcc71be7bb667b4

When enforcing various storage permissions, check associated app-ops
to see if they've been revoked.  We're okay throwing outright, since
Environment already told the app that volumes are unmounted, so they
have no business poking around.

Read/write sanity checking should only be relaxed to group-level for
files living on storage devices; continue using globally readable
flags for all other files.

Refresh storage paths whenever volumes change.

Bug: 22718722
Change-Id: I8640998f490550b4cd3a9b27bb6cb1a658bd102a

The new storage layout used for runtime permissions uses the "group"
ACL for enforcing access, and the "other" ACL is usually masked off
completely.

Bug: 22525550
Change-Id: I29b48cc3425ccfc8d3ff5ec323c8dc50be104878

Return START_REDELIVER_INTENT to make sure we always get the intent
if we're ever killed and restarted.

Bug: 22349167
Change-Id: I696284b8d55a8c8d1fb2362cd769981ae0d45366

It ends up that MediaProvider is persisting MTP storage IDs in its
database, so we need to make sure we generate stable IDs over time,
otherwise we can end up looking into a black hole.

Bug: 22256092
Change-Id: Ia419c37f87c7c0aa59ef0de530fd219c82988f6c

This reverts commit b696ff47.
which caused issues for applications specifying a "group by" clause.

Change-Id: Ifbd67b05c695cbec80cb542cd24708b0d0419f64

Bug 21581123

Change-Id: I765e047ea65b3b6e19b3814502246a31be1b41b3

When adb is disabled, the default usb mode would be "none", which
would turn off the driver and prevent UsbDeviceManager from receiving
any new USB connect / disconnect messages. This prevents the user
from ever enabling MTP and sharing data when adb is turned off.

As discussed in bug 21429947, we work around this problem by keeping
the USB driver in MTP mode most of the time, so that we continue to
receive USB connect / disconnect messages.

To avoid leaking confidential user photos, this change honors the
unlock state sent to us by the UsbDeviceManager code. We only expose
user data if explicitly authorized by the user. MTP being enabled
is decoupled from data being exposed on the USB connection.

Bug: 21429947
Change-Id: I495011aa4e3e18c5e5e6fe7b9d0e1a3efe747ee7

Read EXTRA_RINGTONE_AUDIO_ATTRIBUTES_FLAGS from intent to change
  the AudioAttributes flags on the Ringtone instance used to play
  the selected ringtone.

Bug 19407114

Change-Id: I2d923ef27e8db19b2560a129ba2462c90a07a997

This protects against various SQL injection attacks.
Bug: 20530237

Change-Id: I9f54db69dbae798873d74919841197c68ece614a

We can now have primary emulated removeable storage, which causes
this code to be upset.

Bug: 19993667
Change-Id: Id806c5d41ede6e040af9a48496b9e103a9c75962

Bug: 19993667
Change-Id: I6380ac08f2eb91af81277d0ace42943e20112b2d

Bug: 19246412

Change-Id: I25c2f09ded0527ac062d9c8a57adf3aa7639ea76

Change-Id: Ib91d67a952582090d1fccf1dc8e7902edad2dfa5

Don't notify MTP.

Steps to Reproduce:
1. Connect DUT to Win7 PC via USB cable.
2. Do Factory reset, don't unplug the USB cable during the reset.
       ->DUT will reboot automatically after factory reset.
3. After DUT enters the system, transfer some files to the DUT by MTP or
take some photos by Camera.

Expected Results:
Read DUT files normally on Win7 PC.

Actual Results:
The files transferred by MTP are named as "Local Disk" on the PC.
And the photos token by Camera can not be showed.

After file is inserted into "internal.db", don't notify MTP. If notify,
PC will get no data from DUT because MtpServer will only query
file's info from "external.db" and after PC gets no data so many
times, it won't send "GetObjectPropList" request to DUT, that will
cause "Local Disk" showed on the PC side.

Change-Id: I6cb364158dbda8b267bdfbf6663d0682f7d4d6cb
Signed-off-by: xiaochao <xiaochao.huang@intel.com>
Signed-off-by: Bo Huang <bo.b.huang@intel.com>

    Because Sprout has removable storage, the framework needs to maintain
    external database for keeping multiple databases between SD cards.
    When cleaning up databases for old external storage volumes, we can't
    delete .db-shm and .db-wal because these two files always have the
    latest data and .db doesn't have. Using camera or Google+ will access
    .db-shm and .db-wal to get the latest data and will cause SQLite Disk
    I/O exception if they are deleted.

    The fix is to modify the logic of cleaning up databases (only delete
    .db file, not to delete .db-shm and .db-wal file).

    Bug 18412563

    Review: https://partner-android-review.git.corp.google.com/#/c/187072

Signed-off-by: Benson Huang <benson.huang@mediatek.com>

Change-Id: I484bd535ddebee09824a10f12241f6b2ce086b94

Bug: 18118488
Change-Id: If1d12def4598be9cbf86b8550061f4d075be9717

Bug: 17943556
Change-Id: I1ee026fc0f6248dab2e678e478ba76e8d464dba6

This reverts commit c50b2bef.

When user set alarm ringtone in DeskClock,
It can't play with AudioManager.STREAM_SYSTEM stream type

Bug: 16906307
Change-Id: Ia0d8df9b5c31441d34dc82678bceccd8ce31423d

Bug 16552638

Change-Id: If32429d6c124970b22075930a60fa23cafed8395

When choosing a ringtone, avoid the ringer stream during
playback to avoid interception.

As before, no playback is performed if muted.

Bug:15344396
Change-Id: I7301c7e60682c57187708dfc8fa933a150c5147a

vaguely related to bug 10733373

Change-Id: Icda99a66d893374de7a1ed84d24f2c97a72b90b2

Make sure we release cursor resources.

Change-Id: Ia122100b1350ae5db4804f8f0e95c49785ab645b

Change-Id: Ie2ee436d9d5aa8f189bcb5a64116d09fccc5233b

Issue description:
Unable to use camera after deleting all files in internal storage from PC
with MTP. The toast message "Connect USB storage before using the camera"
is poped up when we launch camera after deleting all files in internal storage
from PC with MTP.

Steps to reproduce the issue:
1. Launch Camera and take a picture.
2. Connect device to PC with MTP mode.
3. Delete all files on Internal stoage from PC.
4. Launch Camera after step 3 finished.
Then we find that we are unable to use camera and the toast message is poped
up.

Root cause:
The .thumbdata3--xxxxx in /sdcard/DCIM/.thumbnails/ is opened in 
android.process.media process when we take picture in step 1. But the file is
never closed. So camera cannot create the directories(/sdcard/DCIM/Camera) 
it needs to store captured pictures because "Device busy" error.

Solution:
Deactivate the MiniThumbFile when it is not needed.

Change-Id: I0faab5ffd95c5626f7f9ef1bc02b2ae56e2eb19b
Signed-off-by: hanpengx <pengfeix.han@intel.com>

This fixes a broadcastreceiver leak.
b/13622801

Change-Id: If9da147163c8f819eae66f97424a37e6f6f6d3aa

Allows custom ringtones, notification sounds, and alarm sounds.

Bug: 13340779
Change-Id: I50dc9c6feca6c769edaf6b1fdd85f4b488c4da73

Bug: 7342482
Change-Id: I56851a97303a72e999bdff009a59a2924f586e69

Change-Id: I2355ec73cdf82b7c51a154c7ef2269791240638b