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 91447d88f2)
Change-Id: I1b43086860661012f949fb8e5deb7df44519b854
Treat arrays other than actual Object arrays (i.e. those whose component type
is actually Object) and the primitive arrays already handled specially by
Parcel as Serializable's.
Issue: 64583
Change-Id: I3ff797f3262e77e4de27f35709bceee5410d1ed4
For storing pointers, long is used in SurfaceSession class,
as native pointers can be 64-bit.
Change-Id: I1535a488dfffaddd20e3beac57e558035d715cbf
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
Following changes have been done:
[x] Long is used to store native pointers as pointers can be
64-bit.
[x] AssetManager openAsset native function returned -1 if
file name was empty and java function considered any
non-zero value as success. This has been fixed by native
function throwing Illegal Argument Exception as well.
[x] AssetManager incRefsLocked and decRefsLocked now accept
long as input to support 64-bit native references.
[x] AssetManager incRefsLocked method incorrecly used
'this.hashCode()' instead of the passed parameter id.
This has been fixed.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: I095b9f900d49e51f43ad6afc47cbc23116a6a64a
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
The method handleMessage(Message msg) from mHandler variable was
not checking if the timer was cancelled, so
sendMessageDelayed(obtainMessage(MSG), delay) was keeping the
timer alive. The patch simply adds a boolean and checks if the
CountDownTimer was cancelled before calling
sendMessageDelayed(obtainMessage(MSG), delay)
bug: https://code.google.com/p/android/issues/detail?id=58668
Change-Id: Ic6bbb9d33a3616f8503db222513cc14ad2270cb8
Signed-off-by: jl1990 <jlcarrasco1990@gmail.com>
Long is used in PropertyValuesHolder class to store native pointers
as they can be 64-bit. Note that jmethodID, a pointer to structures,
is also carried in long rather than int to support 64-bit system.
Change-Id: Ifb514fc8473d7c41c0d6194fc6eb85d4816b2cd9
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Changes include
[x] Long is used to store native pointers
[x] Added new method obtain(long obj) to Parcel. Binder
uses this method instead of obtain(int obj).
[x] obtain(int) has been changed to throw unsupported
operation exception.
Change-Id: I408e0f2a24deb28c9277d86670653a51eb314266
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
* changes:
AArch64: Use long for pointers in BitmapRegionDecoder
AArch64: Use long for pointers in Movie class
AArch64: Add AssetInputStream.getNativeAsset
For storing pointers, long is used in speech/srec classes,
as native pointers can be 64-bit.
Note corresponding JNI files are in the external/srec project
under srec_jni directory.
Change-Id: Iacd10840e81f5acc3eb202424f83b49ae4eb23ab
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
This patch adds AssetInputStream.getNativeAsset. This function
returns asset pointer, which can then be passed to JNI functions.
Note that this function is hidden and not part of Android API.
This function will eventually replace getAssetInt,
once all the classes that use getAssetInt are changed
to use getNativeAsset instead.
Change-Id: I2a2b2e6864f1f57ae2b3a10c45559b3635266ed5
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
It returns a pointer to a private data structure, so there's
no sensible use for it. Also, the emergence of 64 bit processors
means that the return value isn't wide enough to represent
values in the native heap.
(cherry picked from commit f8f09a15a4)
Change-Id: I9c9b5bae6db8638e65dda60f924aa3dddd06813a
Long is used in android/os/MessageQueue class to store
pointers as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I7e901b8515a5b5e3afe1dadaaf3e5c186955c2a0
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Long is used in android/os/MemoryFile class to store
pointers as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I07afc010524c16b5c852273b89becb0c08ff27d7
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in view/input classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Iafda9f4653c023bcba95b873637d935d0b569f5d
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in VelocityTracker class,
as native pointers can be 64-bit.
Change-Id: I8c454663a97745c7440bb6f99ef49d28e9026876
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
For storing pointers, long is used in MotionEvent class,
as native pointers can be 64-bit.
Change-Id: I88ebfef26070b7f49c14945cad37aa3db209ec90
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in KeyCharacterMap class,
as native pointers can be 64-bit.
Change-Id: Idc1b39874202e96b9231d7801e6707003787659b
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Null values were being written out as <null /> elements in the
XML prefs file (as expected). This allowed the getFoo() functions
to work correctly because they treated null values as missing mappings
but containsKey would fail.
bug: https://code.google.com/p/android/issues/detail?id=64563
Change-Id: I1f466d01db96bf26e208d4fed3a6f257228bea5d
For storing pointers, long is used, as
native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I7aee49dc26cf6c86af8f1d882e9cd1cc145a1977
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in CursorWindow
and SQLiteConnection classes as native pointers can
be 64-bit.
Change-Id: Ia686006a7b8bdc7b95e5de0d0a294b155034a921
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in hardware classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Icdeb67f9273fb2d8f6d88ca68d7f7d0950796fc1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used as
native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I3c0855373c0e4bedc172adb82b103586de9219dc
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
