It is important that the char buffers for options do
not go out of scope as the mOptions.add() does not copy
the buffer. This moves all the buffers to the top
level scope of the function to prevent accidental
overwriting when they go out of scope.
Bug: 13448497
Change-Id: I5a97ddd32ff34f237915927906e1e1f833ff036e
This was brought back by a bad merge conflict resolution
in change 0efbd9a463c848118c7685f4bfc8765a82caa761.
Change-Id: I0c7cbe8ee396293619eabf4d0a3c2f06c76bdd6e
The Res_png_9patch struct had several pointer members
whose size differed between 32 and 64 bit platforms.
These members have been replaced by uint32_t offsets
to serialized data. The serialized form for 9patches
places a Res_png_9patch object at the beginning of
serialized data, followed by int32_t arrays of xDivs,
yDivs and colors.
Note that these offsets are not strictly required,
since they can be computed from the values of numXDivs,
numYDivs & numColors, however they are called in tight
loops so having them computed once is a beneficial.
This change also removed the unused patch_equals function
from aapt's Image.cpp.
Change-Id: I3b9ac8ae5c05510d41377cae4dff1c69b40c2531
This is a change to add args to some of the profiler related
functions, including installd commands.
Also read properties and set command line options for the runtime
profiling parameters.
Changed calls to isDexOptNeeded() to isDexOptNeededInternal(). This
needs additional arguments passed for profiles.
Bug: 12877748
Change-Id: I1a426c9309d760bac0cf92daa298defee62287c1
Conflicts:
core/jni/AndroidRuntime.cpp
Note that files changed in this patch have been automatically
generated by running frameworks/native/opengl/tools/glgen/gen
script
This will allow eglGetDisplay(int) to work on both 32-bit and
64-bit systems when EGL_DEFAULT_DISPLAY is passed as a parameter.
Change-Id: Idf27d6e00d623d331bb2d4d7f85fa450e0db26c9
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Note that files changed in this patch have been automatically
generated by running frameworks/native/opengl/tools/glgen/gen script
This patch updates EGL classes in frameworks/base to support
64-bit platforms. Key changes in the EGL classes include
[x] EGLObjectHandle class - EGLObjectHandle class has two public
methods (constructor and getHandle) that assume handles are
32-bit. They have not been changed. Instead, two new hidden
methods (EGLObjectHandle(long) and getNativeHandle) have been
added.
[x] EG14 class - Two public methods eglGetDisplay and
eglCreatePbufferFromClientBuffer assume that handles are 32-bit.
They have been changed to throw unsupported operation exception
on non 32-bit machines. Two new methods eglGetDisplay(long)
and eglCreatePbufferFromClientBuffer(...long buffer..) have
been added to support 64-bit handles.
Change-Id: I9e0f064e5b33700eb0baa2e1841a21f931f7a765
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Note that files changed in this patch have been generated
by running frameworks/native/opengl/tools/glgen/gen script.
Change-Id: Iff3ac2e804af41b9a6ec073fd65019c6806fe821
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
* changes:
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
On devices using /dev/rtc instead of /dev/alarm, updating the
time-of-day clock and RTC are separate syscalls. Hence the clock and
RTC could be left in inconsistent states if two threads called
SystemClock.setCurrentTimeMillis() simultaneously.
By moving this code into AlarmManagerService, we can put a global lock
around AlarmManagerService.setTime() and prevent the race condition.
Note that access to SystemClock.setCurrentTimeMillis() is now gated by
android.permission.SET_TIME, where before it was gated by filesystem
permissions (i.e., could the process write to /dev/alarm or /dev/rtc).
Change-Id: Ia34899a4cde983656305fd2ef466dfe908ed23c8
Signed-off-by: Greg Hackmann <ghackmann@google.com>
JNITest class is no longer actively used. This patch
removes the class (java and jni) files.
JNI interfaces and calls are extensively tested in
the art unit tests (art/tests) and in cts (see
CtsJniTestCases).
Change-Id: I62f7c72deb5d206fa3f545ae39a9cb9011110d0a
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
We claim these functions want jlong as input (8 bytes wide)
but the definitions use pointer types or jints
(4 bytes wide for 32 bit).
bug: 12890271
(cherry picked from 017546e65280a3389b6167f5fc3b5d1c3001154a)
Change-Id: Iede02be90e6a3c9a2db1fe04dcd0db99abe37097
Changes in this patch include
[x] Long(64-bit) is used to store native pointers in
AssetAtlasService and related classes 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)
Change-Id: Ib4c77c134e3ad5b21732e20cde9a54a0b16bdab1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
This value is overridden by the framework anyway
(see ActivityThread.handleBindApplication). Besides,
it doesn't seem like a great idea to let tools clutter
/sdcard/ with temp files.
Change-Id: I26c710cbea7397f89e6103e54a73044a87da95b1
libselinux selinux_android_restorecon API is changing to the more
general interface with flags and dropping the older variants.
Also get rid of the old, no longer used selinux_android_setfilecon API
and rename selinux_android_setfilecon2 to it as it is the only API in use.
Change-Id: I1e71ec398ccdc24cac4ec76f1b858d0f680f4925
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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>
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>
For storing pointers, long is used in
android/graphics/Camera class, 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: Ic05ebf2051a225a1638a43f476bab6176c0b5c38
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@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>
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
The main bug was that the AutoJavaFloatArray autoSrc was not passing in
read only. This meant that the destructor overwrote the data which
the autoDst AutoJavaFloatArray had written in it's destructor.
This case only happened if src == dest and the arrays were copies.
Also improved performance by passing in read only a few other places.
Bug: 12570144
Change-Id: Idc8764087dc165433c584b87a0f9d4ed0ec795e8
