At least part of what is broken. Other stuff still seems to be.
Change-Id: I367dc0377bd5b4e59d9d9b68f3506bf1d64aa591
(cherry picked from commit 32bb5fae353b5bb6275e75952e89c514c7369cee)
Modified ActivityView to inject touch events it receives back into
its activity container. The container then injects the event into
the input system along with the display id of the underlying virtual
display.
Enhanced the input system to support concurrent dispatch of touch
events on multiple displays which is required for this to work.
Change-Id: I9cf1870db3be6f99a52ed9a1e3ceafe42c940093
Remove all of the pieces except the PointerController and SpriteController over
to frameworks/native in preparation for inputflinger. Those two need to stay in
frameworks/base for now because they depend on Skia currently. In the long run
they should be merged into either the InputManager or the WindowManager rather
than as a part of the inputservice / inputflinger.
Try 2.
Change-Id: I84259356d3eb8efc5aefb9d6b311b5fc590ea3ed
Remove all of the pieces except the PointerController and SpriteController over
to frameworks/native in preparation for inputflinger. Those two need to stay in
frameworks/base for now because they depend on Skia currently. In the long run
they should be merged into either the InputManager or the WindowManager rather
than as a part of the inputservice / inputflinger.
Change-Id: Iebef71f3030fb3d26a5f338eb66d75bb37c17734
This gets us one step closer to removing our dependency on Skia, which is at
least one of the things blocking us from moving the input system out of
f/b.
Change-Id: I755e6267996c93fe700f1056327386923287575a
Support 3 letter language codes, script codes &
variants. The bulk of the changes are related to
the implementation of command line filtering of
locales etc. The previous code assumed that the
value of each "axis" (locale, density, size etc.)
could be represented by a 4 byte type. This is
no longer the case.
This change introduces a new class, AaptLocaleValue
which holds a (normalized) locale parsed from a
directory name or a filter string. This class takes
responsibility for parsing locales as well as
writing them to ResTable_config structures, which is
their representation in the resource table.
This includes minor changes at the java / JNI level
for AssetManager. We now call locale.toLanguageTag()
to give the native layer a well formed BCP-47 tag.
I've removed some duplicated parsing code in
AssetManager.cpp and replaced them with functions on
ResTable_config. The native getLocales function has
been changed to return well formed BCP-47 locales as
well, so that the corresponding java function can use
Locale.forLanguageTag to construct a Locale object
out of it.
Finally, this change introduces default and copy
constructors for ResTable_config to prevent having
to memset() the associated memory to 0 on every
stack allocation.
Change-Id: I899a56a9a182ee6be52b9389d1ae59266f5482e9
- 3 letter codes are packed into the existing 32 bit locale
field in ResTable_config
- We introduce new fields for script / variant information.
Note that we define a "match" between two ResTable_config
structures to be purely on the basis of their language &
country (disregarding the script and the variant). However,
configs with scripts and variants are considered to be more
specific than those without.
Change-Id: I3c2e909ebbebdbbd0ab72a639d531b2b9fdbd9b9
TinyHashMap used hash_t(key) to generate hashcode. This
would not work for 64-bit pointers as hash_t is declared as
an uint32_t.
Replaced the hash_t(key) call to more generic android::hash_type(key).
This function is a template function declared in TypeHelpers.h and
has a version available for all data types including pointers.
Change-Id: I612cf18b49ca7c30b63f9d6938df68fed7d80d08
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
This will allow us to inspect the paint for thing other than
color and xfermode, such as SkColorFilters and SkShaders.
bug: 10650594
Change-Id: I2c3ddd07a3966e1e77af34136307e2b59b2898c1
Move the projection surface to be a property of a DisplayList,
set to true for every background drawable.
Additionally, handle a projecting view background such that it doesn't
try to project onto itself (which is undesirable).
Change-Id: Ic70b17474bd87340e80767f8518f73b233419c7a
Somewhat unifies the ortho/perspecive paths - the property matrix
(translate/scale/rotate) is now always a Matrix4.
Change-Id: I36e4fe83d1150ee6e4be5f64f34d0fc8d6525cc6
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
Introduce a new tool 'idmap' to handle generation and verification of
idmap files. The tool is modelled on 'dexopt', and is intended to be
used similarly, notably by 'installd'.
See cmds/idmap/idmap.cpp for further documentation on 'idmap'.
Note: this commit is interdependent on a commit in project build/ to add
'idmap' to PRODUCT_PACKAGES.
Note: the changes to androidfw are only stubs. The actual implementation
will be provided in Runtime resource overlay, iteration 2.
Change-Id: I7131b74ece1e46c8a9c0a31d103e686aa07da2bb
