Using reinterpret_cast allows conversions between pointer types
and integers which don't have the same size. The corresponding
flags is -Wint-to-pointer-cast.
Change-Id: I8ff0c79d235fa6d07b8d9305edc185d946d5133d
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
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
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
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>
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
For positioning of glyphs within a bitmap, roundf(int + float) is used,
where the float is the glyph position and the int is the text position.
When the text position is varied, this may lead to the sum being rounded
in different directions, due to floating point rounding, caused by that
floating point numbers have different precision in different ranges.
This may therefore lead to slightly different positioning for glyphs and
therefore slightly different widths and heights for text strings,
depending on the position they are rendered at.
The solution in this patch is to use int + (int) roundf(float), which
has consistent rounding, and also enables us to use the full range of
ints.
Change-Id: Id1143cdfcbdfa9915ced878ae04df589a3e03cee
mBitmap and mTexture is not initialized to NULL which causes
illegal address access when it fails to be created from
oversized bitmap.
Change-Id: Iea54bec8788bc5f3a10040fdb43f416c0d41a14c
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
Fixes: This patch makes sure that the layer's alpha value is
up-to-date and does not reflect the previous view's alpha value.
it fixes the square block on marquee fading edge when text view
is applied transparency.
Change-Id: I110649db72a75fecc02ba56c201a05773f80328c
bug:10863163
This fixes two issues
The check for pure translation was incorrect. It was fixed and renamed
for clarity.
Certain matrix paths weren't setting kTypePositiveScale. For
simplicity (and because positive scale is simple to check) removed
flag in favor of dynamic checking.
Change-Id: Ic5ce235653ef49a68b8b242bd89fc2e95874ecc9
I guess we don't want to overwrite the last line in every RGBA glyph
with our one-line texture atlas spacer?
Bug: 10841207
Change-Id: Ief85ca58650c731e9d21dbf90942b7b44670abcc
bug:10761696
Avoids a case where a rect with top coordinate of (e.g.) 0.51f is
assumed to not draw in the first row of pixels, which leads to it not
being clipped. Since rounding can cause it to render in this first
pixel anyway, we very slightly expand geometry bounds.
Now, in ambiguous cases, the geometry bounds are expanded so clipping
is more likely to happen.
Change-Id: I119b7c7720de07bac1634549724ffb63935567fc
bug:9969358
Instead of storing DeferredDisplayState within an op (thus forcing ops
to be tied to a single state instance), associate each op with a new
state at DeferredDisplayList insertion time.
Now, DisplayLists (and the ops within) can be reused in a single
DeferredDisplayList draw call, as ops will use different state
instances at different points in the frame.
Change-Id: I525ab2abe0c3883679f2fa00b219b293e9ec53d9
Reconcile the difference between ZipFileRO and java.util.ZipFile to have
the same behavior.
Bug: 10424836
Change-Id: I6bde1bad7e20065ee650945fd43a913c05ce5ac7
Reconcile the difference between ZipFileRO and java.util.ZipFile to have
the same behavior.
Bug: 10424836
Change-Id: Iff159c9e1a91b59f6c5346dc0278cb9e4bbc1a39
Bug: 10677765
enableScissor() must precede setScissorFromClip() as
otherwise setScissorFromClip() doesn't do anything.
Also make sure to call setScissorFromClip() if
enableScissor() returns true as enableScissor() calls
resetScissor() if the scissor state has changed.
Change-Id: I9226b20bb256c92066aae344e4e6407540b6eae9
Bug #10347089
If an app clears its path cache before stopping background tasks, it could
get into an infinite loop in PathCache::trim().
Change-Id: Ieb865b762e7b00aebaba0c023769c2db286a94f5
Oops! kBW_Format was omitted from a couple of switch statements,
resulting in glyphs in that format being invisible.
Bug: 10206452
Change-Id: Ib2aa52250aeeecc0de1b1b78e3d0f568f368c73e
