You can now do android:largeHeap="true" on an application.
Doesn't yet do anything, waiting for Dalvik API.
Also tweak package parsing so that the SDK API level is set in the
configuration, allowing manifest resource value selection based on
that.
Change-Id: I6e035f9702a97b055416743b88f83a22ba4a9584
Text color for the fast scroll panel is dependent on its background,
which is already configurable within the theme.
Change-Id: I6ac3018116f078b7567888d75fa34ffd250d2f92
This complements the secure rfcomm API.
The link key is unauthenticated and is subject to MITM attacks.
The link key may be encrypted depending on the type of Bluetooth device.
This helps apps which don't need the extra security or
have their own security layer built on top of the rfcomm link.
Bug: 3352266
Change-Id: I633fd0372e5e23288d6fec950dd1abc2896031f1
* New uses-policies value
* Definitions for storage domain and encryption status
* API to get and set encryption status
* Intent to launch encryption changes
* Both new calls bottom out in the DPM service and are suitable for
a device that does not support encryption.
NOTE: Nobody should use ACTION_START_ENCRYPTION yet. It needs a receiver
to be built in Settings (different CL).
Change-Id: I2ae193bedbec59f6ba46c0ec7de12ecf321e5803
LayoutTransition works by animating layout-related properties
(left, right, top, and bottom). This works great when that animation
is the only thing affecting the layout of the UI. But if there are other things
happening in the application that cause layout to run on that
container or in its parent hierarchy, this can cause the layout properties
on its children to get mis-set during the middle of the transition.
This results in artifacts like animating objects jumping to locations where
they would be were there no animation running.
The fix is to supress layout requests on that container (and its children)
until the transition is complete (then issue a layout request on the container
to make sure that the container has the correct layout data)
Change-Id: I15bf0423a11409f854076f86099233db7fe4edc0
o Prepare for publishing MediaMetadataRetriever as public API
step one:
o replaced captureFrame with getFrameAtTime
o removed getMode
o Replace MediaMetadataRetriever.captureFrame() with MediaMetadataRetriever.getFrameAtTime()
as part of the preparation for publishing MediaMetadataRetriever as public Java API
o Remove captureFrame from MediaMetadataRetriever.java class
It has been replaced by getFrameAtTime() method
o Replace extractAlbumArt() with getEmbeddedPicture() in MediaMetadataRetriever.java
o Publish MediaMetadataRetriever.java as public API
o Removed setMode() methods and related mode constants
o Removed some of the unused the metadata keys
o Updated the javadoc
o part of a multi-project change.
bug - 3309041
Change-Id: I2efb6e8b8d52897186b016cb4efda6862f5584c4
Allocation limits relied on conditionally compiled code in the virtual
machine that was disabled in released versions of Android. As such,
these setter methods were glorified no-ops. Now that the feature has
been removed from the allocator this interface is thoroughly obsolete.
Change-Id: Id7f9de37ecfece4b909e35f110e118e131457133
