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.
(cherry-picked from commit 91447d88f2bdf9c2bf8d1a53570efef6172fba74)
Change-Id: I1b43086860661012f949fb8e5deb7df44519b854
- 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.
(cherry picked from commit 378c6775a62d9c461cde51f06c1b14bb014c78fd)
Change-Id: I7dce82a3fe2412834252723f458826ae41535a78
At least part of what is broken. Other stuff still seems to be.
(cherry picked from 32bb5fae353b5bb6275e75952e89c514c7369cee)
Change-Id: I280376645166fe772ff7a31ff2e8494dce2adbf8
ResTable::createIdmap takes a size_t*, and the idmap command is
passing in a size_t*, make AssetManager::createIdmap take a
size_t*. Should fix the mac build.
Change-Id: Idc16dedfe2aa7367c75f89a937a8242d494e8f8e
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
Also change the order of parameters in ResTable constructors
to avoid ambiguity.
(cherry picked from commit 00b314436f4fdfada4bbf1e79ec12e9fa38aeaf1)
Change-Id: I874c5d03c134dc3c331fba423b5280366296287c
Cookies are really indices into vectors and arrays, so
they don't need to be void*. We choose int32_t instead
of size_t to allow their width to be well specified.
(cherry picked from commit ebfdd0f467e39c3af8d92cade78263935340acb7)
(cherry picked from commit a7fa2e592e2e579e5acdb903dba83fc074ebc215)
(cherry picked from commit a9d5701b034ed2d9771b3f0943e1add00741d7cd)
Change-Id: I2aed3db568b6fdc487bf99e2c5dd123206736fda
In commit 08d5b8f, the ResTable_config::CONFIG_* enum was incorrectly
changed to assign the same value to both CONFIG_MCC and CONFIG_MNC:
- CONFIG_MCC = 0x0001,
- CONFIG_MNC = 0x0002,
+ CONFIG_MCC = ACONFIGURATION_MCC,
+ CONFIG_MNC = ACONFIGURATION_MCC,
This commit assigns CONFIG_MNC the value ACONFIGURATION_MNC, as
intended.
Change-Id: I3b8799914a55debdb3ff30a82ada7ad990c49970
This lets us share zip archive processing code with both
the runtime (Art, dalvik) and critical java code
(StrictJarFile).
This change also moves several utility methods to ZipUtils
and dedups code across several zip inflation methods.
One of the side effects of this change is that several
processing loops are now O(n) instead of O(n^2).
bug: 10193060
Change-Id: I3c7188496837a47246c4f342e45485a70fef3169
Don't ever need the cached UTF-16 string conversions on the
device. Don't need to create those strings, and don't need
to create the lookup array for them at all. This requires
fixing all of the remaining places in the platform where we
interacted with the resources with the blind assumption that
the strings are UTF-16.
Change-Id: Ia0e5a150499837471e494e85b23b05fa06e0cf1d
No longer compile libandroidfw as a static library on the device
since it already exists as a shared library. Keeping the static
library would force us to provide a static library version of
libinput for the device as well which doesn't make sense.
Change-Id: I3517881b87b47dcc209d80dbd0ac6b5cf29a766f
Changes:
- The static device version of libandroidfw now includes
the extra functions needed by aapt. I could only find
a few host tools that use the static library, so this is
hopefully not a problem.
- The pseudolocalization code is moved into aapt.
It was previously in libhost, but only used by aapt.
Change-Id: Ib393ebb7dcebee8abbb628cbe5255ea1679674ac
InputChannels are normally duplicated when sent to a remote process
over Binder but this does not happen if the recipient is running within
the system server process. This causes problems for KeyGuard because the
InputMethodManagerService may accidentally dispose the channel
that KeyGuard is using.
Fixed the lifecycle of InputChannels that are managed by the IME
framework. We now return a duplicate of the channel to the application
and then take care to dispose of the duplicate when necessary.
In particular, InputBindResult disposes its InputChannel automatically
when returned through Binder (using PARCELABLE_WRITE_RETURN_VALUE).
Bug: 8493879
Change-Id: I08ec3d13268c76f3b56706b4523508bcefa3be79
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: I08e677faf2ebb418ef131d0a8008e01037db0e50
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
Since emulated external storage paths differ based on execution
context, carefully fix up paths for various use-cases:
1. When sending paths to DefaultContainerService, always scope
OBB paths as belonging to USER_OWNER.
2. When sending paths to vold, always build emulated storage paths
visible to root.
3. Always use the original untouched path when talking with apps.
Mount OBB containers using shared app GID, so that an app can read
the mount point across users.
Handle legacy paths like "/sdcard" by resolving the canonical path
before sending to MountService. Move tests to servicestests, and
add tests for new path generation logic.
Bug: 7212801
Change-Id: I078c52879cd08d9c8a52cc8c83ac7ced1e8035e7
The input system needs to know about the window that has
focus, even if it is on a secondary display. So now we
send it the list of all windows and indicate which display
they are on. We filter the list of windows as necessary
when delivering touch events.
To keep things simple, monitor input channels and input
filters are not supported except on the main display.
We also do not pass the display id to applications; it is
only used inside the input system for now.
Properly scale touch coordinates based on the viewport.
This will be needed to ensure that touch works on external
display as well as when the internal display is being used
to simulate a different resolution.
Change-Id: I1815579a52fcc852c519b5391fc7ab8767c2dc59
Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.
Added JNI for all of the new surface flinger display API calls.
Enforced the requirement that all Surfaces created by
the window manager be named.
Updated the display manager service to use the new methods.
Change-Id: I2a658f1bfd0437e1c6f9d22df8d4ffcce7284ca2
Moved some duplicate code from SearchPanelView and LockScreen
over to SearchManager to avoid creating yet another copy of it
in PhoneWindowManager.
Bug: 6594275
Change-Id: Ib4ebcd6817639d17548952ab2ce7cb876c05777c
For comparison purposes, port the legacy velocity tracker
algorithm as it behaved prior to ICS.
Bug: 6413587
Change-Id: I7e8e56584dcdb1a3c660ca9d8f9c5bd5d868e449
This algorithm better tolerates certain kinds of errors in the
touch input than the least squares strategy but it may underestimate
the velocity of accelerating movements. This algorithm is
mainly of interest as a baseline for testing and comparison with the
least squares algorithm, which remains the default.
Bug: 6413587
Change-Id: I8ddb50084e44875e234717907e5b06d03f59788c
This change is very useful for testing purposes because it makes it
easy to compare different implementations to see how they behave.
There is no change to the current default strategy.
Bug: 6413587
Change-Id: I4d8567aa4160571ba9fa397ce419882cd9366749
The fix is to track when we issue GL drawing commands, and to skip the
call to eglSwapBuffers() when a DisplayList does not result in
any actual rendering calls to GL.
Issue #6364143 QuickMuni list items and buttons flicker instead of fade
Change-Id: I60a02c61a58c32d92481a1e814b4c8a49c6a37a3
Some input devices do not generate ACTION_MOVE events while all
pointers have stopped, thereby lulling the VelocityTracker into
a false sense of complacency. Before handling the following sample,
reset the VelocityTracker state so as not to be influenced by
earlier samples before the pointer stopped. The velocity after
stopping is assumed to be discontinuous.
Bug: 6413587
Change-Id: I6387bc036ff141d083d3d17a89e37eeaa3188349
Fixed a few bugs related to the id-to-index mapping for
pointer coordinates.
Tightened the bounds on the resampling time interval to
avoid predicting too far into the future.
Only lerp X and Y components of motion events.
Alter the future to satisfy past predictions. (Rewrite touch
events to conceal obvious discontinuities.)
Added a system property to control whether resampling is enabled
for debugging purposes.
Bug: 6375101
Change-Id: I35972d63278bc4e78148053a4125ad9abeebfedb
If a fallback key is generated using a key plus a modifier,
then it's possible we might get a different fallback key
generated if the modifier has changed. PhoneWindowManager
needs to remember which fallback is last generated for a
given key code so that it can apply the same fallback action.
When generating cancellation events, it's important to have
preserved the policyFlags of the original event. Otherwise
we may not dispatch the cancellation properly. For example,
some actions are not performed if the POLICY_FLAG_TRUSTED
is not specified.
Remember the metaState associated with a key event so we can
include it when canceled.
Tell the policy when a fallback is being cancelled so that it
can clean up its state.
After a SEARCH shortcut is invoked, clear the flag indicating
that a shortcut is pending. This is to prevent SEARCH from
getting stuck down in the case where we might forget to send
the up. (Shouldn't happen anymore after the prior fixes.)
Bug: 5616255
Change-Id: I68f0a9679c7af464eaf31c099f2aa50b53fecf1f
