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: Ib4435f0794740d545c1e640087849215e6844802
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
For storing pointers, long is used in MTP 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: I67805547251722e7b77611d47d0bb632a64d3e6d
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 VideoEditor
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: Ifff3a28f2ab6774ee89d31770ad63451c8726431
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>
For storing pointers, long is used in AudioEffect
and Visualizer 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: Ief49bbe5baef663e268c7f6d70ac33a4df45621c
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 AmrInputStream
class, as native pointers can be 64-bit.
Change-Id: I78fff3eb54fc7101746b0d693cbc4e923c2bad08
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>
Code that expected a single top level element in an XML file
was doing something like :
while (type != START_TAG) { next(); }
This would loop forever when the XML being parsed was empty,
where each call to XmlPullParser.next() would return END_DOCUMENT.
bug: https://code.google.com/p/android/issues/detail?id=64173
Change-Id: I7543203e976a8999ae471a6c2d629249a87011bb
Both readThisValueXml & writeThisValueXml have been
implemented to handle values with "null" names.
Change readThisMapXml to allow such names as well, and
map them to the null key in the resulting HashMap.
readThisListXml and readThisSetXml already support
null names.
bug: https://code.google.com/p/android/issues/detail?id=63463
Change-Id: I1c93976656e45e7733113eb67d29b6bad5d25f1f
If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.
Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
If a query call was cancelled, the cursor adaptor might leak. The
adaptor is now closed if any exception is thrown during query.
Change-Id: Ic4c2edeaf2fcef56b4ef59484a36d3233aa12dbc
A reference leak was found in the subtitle usecase that also
applies to android_media_MediaDrm.cpp
(Code taken from the similar fix in android_media_MediaPlayer.cpp)
Change-Id: Icc4b25e4adc9a600ff4ac99a7a8478bb55a6e348
If the exclusionList was null in updateProxyConfig the VM would
crash when converting it to a UTF8 string. Avoid this by adding a
null check.
Change-Id: I0d8106fd54385bd9ae9c652a6c67d459a119cf2b
https://code.google.com/p/android/issues/detail?id=61547
This variable is shadowing the outer "ptr" declaration, resulting in a
potential NULL pointer being passed to the message API.
Change-Id: If96bfae8d5e874e12597182678a180ba137b78da
When unregistering MountService listeners, their Binder proxy
objects were compared to registered listeners instead of their
backing objects.
Change-Id: Ie98a686b1d17544f1eda59fb3eb0dc02d836c1b2
Interface of Surface class changed.
To reflect the change for EGL14, add producerControlledByApp flag.
Similar change can be seen in 0fa257fe53bf520bdde93996a1901ce6bc3e1788
Change-Id: Ic8911d3131e033747cfdabe59ac2fea1e90bb4a0
In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.
TaskRecord task may be set to null when no resumed activity remain.
Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.
The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.
Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.
To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.
Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.
Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
On devices without /dev/alarm, use the settimeofday() syscall and the
standard RTC_SET_TIME ioctl (which are collectively equivalent to the
ANDROID_ALARM_SET_RTC ioctl).
Change-Id: I3c1d741099e253186e43c9369b62603b214b9c9a
Signed-off-by: Greg Hackmann <ghackmann@google.com>
On devices without /dev/alarm, use a new backend based on timerfd.
timerfd has near-equivalent syscalls for the /dev/alarm ioctls we care
about, with two key differences:
1) /dev/alarm uses one fd for all clocks, while timerfd needs one fd per
clock type.
AlarmManagerService addresses this by replacing the fd (int) with an
opaque pointer (long) to the backend-specific state.
2) When the RTC changes, the /dev/alarm WAIT ioctl always returns, while
timerfd cancels (and signals events) only on specially-flagged RTC
timerfds.
The timerfd backend masks this by creating an extraneous RTC timerfd,
specifically so there's always something to signal on RTC changes.
Change-Id: I5aef867748298610347f6e1479dd8bf569495832
Signed-off-by: Greg Hackmann <ghackmann@google.com>
