Normal apps can't hold it now. If they try to use
getRecentTasks() or getRunningTasks() without the permission,
they will only see their own tasks and home in the list.
Also took this opportunity to eradicate all of the old pending
thumbnail stuff.
Change-Id: I6dc52a06221c78097162e4a8b482027b798bf3ee
Logical address in CEC is to distinguish each logical device from others.
In order to allocate logical address for new device, CEC sends
<Polling Message> to CEC bus. <Polling Message> is a CEC message
which has the same address for both source and destination without
body frame. (10bits).
CEC allows one and more logical address for a device type.
For example, there are 3 logical address defined for recorder device(1, 2, 9).
Among logical address candidates for the given device type, CEC scans
first the previous logical address (preferred logical address) of device.
If a device has not been allocated any logical address, preferred address
will be 15 (Unregistered), which means scan address from the minimum address
number of type. For example for recorder device, it starts from 1.
If no devices acks to the <Polling Message> during scan, it will be the
logical address of the device.
Since logical address is determined by a series of sending <Polling Message>
it happens in IO thread with separate allocate logical address message
instead of individual sendCommand message.
Along with this, updated ADDR_FREE_USE(14) to ADDR_SPECIFIC_USE(14)
which is revised name on HDMI 1.4.
Change-Id: Ic96dcdbe4aaa3789cfed0352a88ca75369335a98
In order to manage info of all cec devices connected hdmi bus,
HdmiCecController should have data structure for them.
This change includes two major pieces.
1. HdmiCecDeviceInfo
It's data structure containing basic device information such as
logical address, physicall address, device type and vendor id.
It will not be available to thirdparty but some system component
like TIF needs this to update device information connected to
its hdmi ports.
2. Managing device list in HdmiCecController.
HdmiCecController is a host to manage all CEC device.
and we need to have logic add or remove as well as get it.
All cec devices are managed as sparsearray which uses logical address as key.
This change introduces internal api and the later change will have logic
to call these apis.
Change-Id: Idc2f189ac0bffe904e011ced0ac991f16da07db1
Store the listener's userhandle in a cookie and compare profile
relationships before delivering package broadcasts to a listener.
Basically, don't leave TODOs around, they'll result in bugs :)
Bug: 14436558
Change-Id: I57a21719caab6cf54b78de7be2eca3e398dc6288
Bind long-term conditions (like "in a meeting") to enter/exit
zen mode automatically.
Persist automatic condition subscriptions to maintain them across
reboots.
Normalize condition state binding: true => enter zen, false => exit.
Change-Id: Icba2b8b25c0a352ae8215f4c0a324e4f966c0165
This makes RCC and MediaButtonReceiver (via AudioManager) also use the new Session APIs in parallel to their existing code. This will allow us to bring up the Session compatibility pieces without disrupting the old behavior and then switch everything over to just using the new APIs when ready.
Change-Id: I33ce0a044dea3ec763f2302b91a5e415be27d4a4
If means the package hasn't been scanned yet, and we
will adjust the ABI during the scan of the last package
in the shared user group.
NOTE: This needs some more cleaning up, which will be
done along with the remaining TODO in this function.
(cherry picked from commit 6609990e35b11c38f55f6e632160d4f2ff201ea3)
Change-Id: Ibace7849485865054e062d2b979f320bf89ff0f3
We should now prune all normal files from /data/dalvik-cache
in addition to looking for dex files in all subdirectories of
/data/dalvik-cache.
(cherry picked from commit 51a6f9253399588eedf77d75c578d9aa23d11529)
Change-Id: I536dfdc48e94155e7be64eb4efd9f7f2a1d2d00a
Since shared UID apps are run in the same process,
we'll need to make sure they're compiled for the same
instruction set.
This change implements the recompilation of apps that
don't have any ABI constraints.
Apps that *do* have ABI constraints are harder to deal
with, since we'll need to rescan them to figure out the
full list of ABIs they support and then re-extract the
native libraries from these apps once we find an ABI we
can use throughout.
(cherry picked from commit 85703d58af1dac692d7d83c03220e45ab2a5aded)
Change-Id: I8311a683468488cc7e30381965487a3d391609ae
- Pass down the app's instruction set to dexopt so that
it can compile the dex file for the right architecture.
- Also pass down the app's instruction set to rmdex, movedex
and getSize so that they can construct the cache file
location properly.
- Temporarily compile "system" jars such as am,wm etc. for
both architectures. A follow up change will ensure that
they're compiled only for one architecture (the same
arch. as the system server).
- Java "shared" libraries are now compiled for the right
architecture when an app requires them.
- Improve the app native library ABI detection to account
for system apps installed in /system/lib{64}/<packagename>
and also handle sdcard and forward locked apps correctly.
(cherry-picked from commit b4d35dc8e9702f9d0d82d35a105f0eea35672b52)
The per-package /system/lib/* feature introduced bugs in the
native library path handling during app upgrade installs. The
crux of the fix is that when recalulating the desired native
library directory, the basis for the calculation needs to be
the scanned APK's location rather than the extant package
settings entry -- because that entry refers to the pre-upgrade
state of the application, not the new state.
Bug 14233983
(cherry picked from commit 353e39a973dbbadce82fee2f83ad194e04a47449)
Change-Id: I26f17a596ca2cd7f963955c0642548c15138ae26
Bundled apps can now use /system/lib/apkname or /system/lib64/apkname
in addition to the (globally shared) /system/lib and /system/lib64
directories. Note that when an app is updated post hoc the update APK
will look to its normal library install directory in
/data/data/[packagename]/lib, so such updates must include *all*
needed libraries -- the private /system/lib/apkname dir will not be in
the path following such an update.
"apkname" here is the base name of the physical APK that holds the
package's code. For example, if a 32-bit package is resident on disk
as /system/priv-app/SettingsProvider.apk then its app-specific lib
directory will be /system/lib/SettingsProvider
Bug 13170859
(cherry picked from commit addfbdc09ccf258395db8bfc510989a4c583f7ab)
Change-Id: Id82da78024a6325458b8b134d7d91ad0e5f0785e
