This change consolidates the copy paths to Object based.
The runtime now uses reflection to identify the type of
array present. This adds support for long/double and reduces
the amount of code present. We could also support arrays of vectors
or objects in the future with this mechanism.
Change-Id: I2297c1c01fbe6a64c375d6368f25d7db781ea788
We do not support higher order bound allocations. The
stride is not available to the script so they cannot
walk the allocation correctly.
Change-Id: I9447a5d43c3ae1b88fc9522628a17bd5a317ffc6
This changes BaseObj to support 64-bit IDs. There are a few caveats:
1. Since it is deprecated, RSG will not support 64-bit.
2. Currently, methods that pass arrays of IDs to the driver are not supported in 64-bit. This will be fixed in a later CL.
bug 11332320
Change-Id: If0dbecc8b285e260f767e441e05088b6a1b749a2
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>
Also change the order of parameters in ResTable constructors
to avoid ambiguity.
(cherry picked from commit 00b314436f4fdfada4bbf1e79ec12e9fa38aeaf1)
Change-Id: I874c5d03c134dc3c331fba423b5280366296287c
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>
