This follows up to my previous CL [1], which forgot to update
BridgeIInputMethodManager.java (again!).
[1] I56934f18e30d90fcdf77bcbb0c35a92a5feb1b82
05c25f8a3a
Bug: 25373872
Change-Id: I0643069fd0b677115c89c340b7a23f1d12bd7988
This allows libraries to coexist a bit easier, since a lot of them
declare the same attribute. When used together they cause errors.
Bug:27101533
Change-Id: I10327251636392e810637a79e7c9aa514f3f07a6
Every RenderSession would call the AttachInfo.setAttachInfo but wouldn't
issue a View.dispatchDetachedFromWindow.
This caused some Canvas to be slowly leaked in the DelegateManager in
every session.
Change-Id: Iec418a86f5c5e55c2a2860ef945268c51c0e8173
Every RenderSession would call the AttachInfo.setAttachInfo but wouldn't
issue a View.dispatchDetachedFromWindow.
This caused some Canvas to be slowly leaked in the DelegateManager in
every session.
Change-Id: Ib0392303e6d00a4fe5494ae484f28135b1fe6b28
Every RenderSession would call the AttachInfo.setAttachInfo but wouldn't
issue a View.dispatchDetachedFromWindow.
This caused some Canvas to be slowly leaked in the DelegateManager in
every session.
Change-Id: I0322767e5fffc6053ce1be852dd8ca904dfaa137
Backup requires both CE and DE storage to be available, so delay
spinning up the backup system until the user is unlocked, since
that's when CE storage becomes available. Note that devices without
FBE immediately transition USER_SYSTEM into the unlocked state,
since their CE is always available.
Offer to backup and restore files under both CE and DE. Since DE
is effectively the same as CE, most logic is simply duplicated for
now, but it could be simplified in the future. Since system apps
can force their default storage location to DE, we always build
explicit CE and DE paths.
Add getDataDir() to give clean access to the top-level private data
directory, but disclaim that apps shouldn't create files there.
Bug: 26279618
Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
The main build hasn't swtiched to java 8, but lambdas are already used
in layoutlib. This fixes the build break.
Change-Id: I4dd69ebd736179067899f5d86d3608d5fdb03d93
When a preferred density is supplied, the closest matching densities
will be selected, the rest stripped from the APK.
Split support will be enabled in a later CL. Command line support is still
needed, but the foundation is ready.
Bug:25958912
Change-Id: I56d599806b4ec4ffa24e17aad48d47130ca05c08
This will process all the classes and replace all the uses of
java.text.DateFormat and java.text.SimpleDateFormat with the
android.icu.text. package implementations. The original ones do not
match the Android platform behaviour.
Change-Id: Id55f103c21117a8d6403bf2124b6c1a0e1fb2f71
Refactor setPackageSuspended into setPackagesSuspended. The rationale
is that the consumers of this API are likely to want to remove
multiple packages at once. Rather than calling the API N times, call
it just once.
The good part is that we already have the broadcast intent for
suspended packages take an array so only one broadcast. Less stress
on the system.
Another good part is that (right now) we only have one consumer of
this API and it will be easy to make changes once this CL goes in.
As a shell command, for consistency only allowed one package at
a time.
Bug: 22776761
Change-Id: Ic8b8cf64d0a288ea3a282bb7b72f9d663b3b0049
Now that we've moved the majority of system components to the
PackageInstaller, we can remove the majority of the "installPackage"
methods and the VerificationParams/ContainerEncryptionParams
classes. There are still some lingering references to the two
installPackage() methods left [both internal and external; play
is using these methods via reflection].
Bug: 24542768
Change-Id: Ib65323d842d9f0e7fed60e37e6b5f103c94c859b
Instead of always rebuilding the full ApplicationInfo for a
package when callers are only interested in the suspended status
add a new fast API in Packagemanager (which only checks the
suspended user setting for the requested package and returns
a boolean) and change the appropriate caller code too.
Bug: 26794775
Bug: 22776761
Change-Id: Ide8428ef734479360d5a8a75fd8e0ed8ddf2da7a
We're starting to see more instances of device features that will
increment separately from the SDK API level, such as camera HAL,
GPU capabilities, Bluetooth, and other hardware standards.
This change adds the ability for device features to specify a
version, which is defined to be backwards compatible. That is, apps
requesting an older version of a feature must continue working on
devices with a newer version of that same feature.
When a version is undefined, we assume the default version "0".
Bug: 27162500
Change-Id: If890bf3f3dbb715e8feb80e7059a0d65618482ea
This allows us to preserve the various product definitions during the compile
phase, and allows us to select the product in the link phase.
This allows compiled files to remain product-independent, so that they do not need
to be recompiled when switching targets.
Bug:25958912
Change-Id: Iaa7eed25c834b67a39cdc9be43613e8b5ab6cdd7
