Bug: 7342767
As part of the process of sandboxing the online RenderScript compiler, we
need to install bcc.
Change-Id: Ia650bdcb760246f3f1e15ebb867f07d9802cdfbe
Add linker64 and debuggerd64 to embedded.mk. They will be silently
ignored on 32-bit builds, and filtered out on 32-bit sdk builds.
Change-Id: I8c30ea65e2b7e224ee73cc9fbbcb7555d3be04b5
Change core_tiny to not be minimal font footprint: UX really wants roboto
condensed. Checked /proc/meminfo before and after the change and didn't
see much difference.
Change-Id: I94072f674ff678dfdbddd66d3792e63245e5e7da
This adds a few missing font families to SDK system images.
This allows, in particular, support for the Korean language.
Note that this depends on other patches under device/generic/
to fix some board and product configuration files, otherwise
this change will have no effect.
See http://b.android.com/40340
Change-Id: Idba6471de32232833f511a4da97fd652906fec51
Support any number of overlay packages. Support any target package.
UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes
<overlay targetPackage="com.target.package"/>
For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.
THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').
UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.
Zygote initialization
Initial AssetManager object created
+ idmap --scan creates idmaps for overlays targeting 'android', \
stores list of overlays in /data/resource-cache/overlays.list
AssetManager caches framework-res.apk
+ AssetManager caches overlay packages listed in overlays.list
Android boot
New AssetManager's ResTable acquired
AssetManager re-uses cached framework-res.apk
+ AssetManager re-uses cached 'android' overlays (if any)
App boot
ActivityThread prepares AssetManager to load app.apk
+ ActivityThread prepares AssetManager to load app overlays (if any)
New AssetManager's ResTable acquired as per Android boot
SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.
LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.
When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.
Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:
<overlay targetPackage="com.target.package" priority="1234"/>
Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.
Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.
The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.
+------+------+- -+------+------+
| 0x01 | | ... | | 0x7f |
+------+------+- -+------+------+
| |
"android" Target package A
|
Pre-installed overlay B (priority 1)
|
Pre-installed overlay C (priority 2)
Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
This should never have been on the default include path.
The NDK statically links its own libthread_db, so I'm removing
bionic's unused copy from devices.
Bug: 11882807
Change-Id: I49a67fe0902cc4bc178360f6c993959774d74e3a
Add the vibrator.default package to all targets deriving from
generic_no_telephony, i.e. virtually all targets.
This change is related to other changes in:
- hardware/libhardware
- hardware/libhardware_legacy
- frameworks/base
- device/generic/goldfish
Change-Id: Ic8464844e12f7d31ca49597dfc4995b13e9ff419
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: David Wagner <david.wagner@intel.com>
Author-tracking-BZ: 94611
This makes it easier for OEMs to extend the PRODUCT_BOOT_JARS in their
product configuration files.
Change-Id: I5feca2f808b1914c275f28c7a4c38cca2ba6851f
This is an obsolete rule that was grandfathered in because
it was a USER module at some point. It's no longer
required, even by builds that use packages/app/VoiceDialer.
Change-Id: Ife9e89bd1b03c0364e27650863a83bad945b8089
Because a library or app can be built from mere static libraries,
or generated java files. For example, framework is built from only
static library framework-base but without LOCAL_SRC_FILES.
Also added framework2 to PRODUCT_PACKAGES.
Previously framework2.jar was installed by dependency explicitly
established in frameworks/base/Android.mk. That's not enough for the
.odex file.
This fixed the boot failure reported in bug 12382916.
Bug: 12382916
Change-Id: If1a70261ab2bb7fef77cf7b7b995bdc029be0fc3
Following the new vibrator hardware module implementation, the
goldfish vibrator module is no longer integrated in the default
vibrator implementation and therefore needs to be explicitly built
for the emulator.
This patch is related to others in:
- hardware/libhardware
- hardware/libhardware_legacy
- frameworks/base
- device/generic/goldfish
Change-Id: I844279f5535289f079d412fdc44c5cb3c9c1130c
Signed-off-by: David Wagner <david.wagner@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 94611
Since 558477c0b2a5a7db679c1ad7551d43e6364d1df2 in
external/wpa_supplicant_8 we don't need those modules if
WPA_SUPPLICANT_VERSION is not set by the BoardConfig.mk.
Actually the generic devices don't need them.
Change-Id: Iff7c1fbf483bd16d5f898836c4e7401d56def80f
Conflicts:
target/product/core_tiny.mk
Since 558477c0b2a5a7db679c1ad7551d43e6364d1df2 in
external/wpa_supplicant_8 we don't have WPA_SUPPLICANT_VERSION default
to VER_0_8_X.
This fixes the SDK build.
Change-Id: Ib7a8e10705dc6b987b60b1308405e89eaa2a47c9
vold now uses blkid to extract UUID and label information from
inserted physical devices.
Bug: 11175082
Change-Id: I56ebe733ff85a498f6d3cbdcf21d40ddc6123f82
