Changes in this patch include
[x] Use %zu for size_t, %zd for ssize_t
[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: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
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>
* commit '68d43e275efae8f7b83388ea6fdebbcf5cd1504f':
add the JD docs for the Android Wear docs (delte the HTML versions) This depends on the following CL that makes this all work with template changes: I848f442b3bc66ee2fb87db8200df370d13762d29
* commit 'b5e754dd4d8accd0c1500008aa1a6dbf178d33d7':
add the JD docs for the Android Wear docs (delte the HTML versions) This depends on the following CL that makes this all work with template changes: I848f442b3bc66ee2fb87db8200df370d13762d29
* commit '8ea583a71aef2f21f833c003a948ca7b1dc32915':
add the JD docs for the Android Wear docs (delte the HTML versions) This depends on the following CL that makes this all work with template changes: I848f442b3bc66ee2fb87db8200df370d13762d29
* commit 'f9943d0ecf4d3360064a4cec0b1ffd6767db5612':
add the JD docs for the Android Wear docs (delte the HTML versions) This depends on the following CL that makes this all work with template changes: I848f442b3bc66ee2fb87db8200df370d13762d29
When ensureActivitiesVisibleLocked goes through foreground activity
stack and reaches non-fullscreen activity, it sets showHomeBehindStack
variable to true.
If there is a fullscreen activity behind, showHomeBehindStack remains
unchanged, which causes Home application to be displayed anyway.
In this case user will see a fullscreen activity and Home activity
simultaneously.
To fix the issue we set showHomeBehindStack to false when we reach
fullscreen activity in the activity stack.
This was made visible by the following commit:
446ef1de8d373c1b017df8d19ebf9a47811fb402
Change-Id: I535c1283a4e26f5cf606375b837d4b7195324af0
Allows applications to advertise to the system an Activity
where the user can configure the app's notifications. Will
be used by the Settings app.
Change-Id: Iafe7de79e20046d5655fda3f3a3cba9f5db059c4
This depends on the following CL that makes this all work with template changes:
I848f442b3bc66ee2fb87db8200df370d13762d29
Change-Id: I6b17db774de6fa8be0bf944516a44ba73b10cabb
After being bound to, a NotificationListenerService could
make a call into NotificationManagerService before having been
added to the list of active services.
Bug: 13644375
Change-Id: I4ed920d165f46d009f91e28ca13c3926563cd110
It saves us from having to add numerous native methods to HdmiCecService.
A new native method that reports physical address was added in consequence
to be able to build the message in Java side.
Other changes:
- Substituted more concrete type (cec_device_type_t) to int.
- Fixed the issue about byte endianness in handling physical
address/vendor id. The bytes of variable mPhysicalAddress in native
service were being reversed previously but still worked because they
were reversed again when copied out to outgoing messages. Vendor id
had a bug of bytes being reversed. In order to fix the issue, the way
they are copied to byte array was changed so that it becomes
independent to byte endianness.
- CL's for header/HAL implementation changes are:
https://googleplex-android-review.git.corp.google.com/#/c/437667https://googleplex-android-review.git.corp.google.com/#/c/437668
Change-Id: Id1ac683fe54597a2c707f30492c7f86e5392504d
Copied the documentation from other similar actions that have the
same behavior.
AudioService.java has
intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
for this action.
Change-Id: I79736f8146bd6b72d01034be428e83b5841c73fa
Also change MotionEvent.PointerCoords bit packing and unpacking
methods to be consistent with BitSets which are now used on the
native PointerCoords object.
Bug: 11480300
Change-Id: Ib18c99b94ac555104c69eac526860aa501e89e03
A host can have an 'instance' the other end of which is still
unlinked to a concrete provider. Don't crash when we hit those.
Bug 13651057
Change-Id: I5a29afb0e6a7ab30976862aee04bd33f609543fa
