Channel connection / disconnection was handled as boolean,
doesn't capture all the values. Also make it asynchronous
instead of the dbus call being synchronous.
Change-Id: If30177b9f93b7c83f162fbbc1233edf3e46dbfea
Bug: 5244396
Code was acquiring the char array twice for FIELD_TYPE_INTEGER
or FIELD_TYPE_FLOAT but only releasing it once.
Removed the redundant calls to GetCharArrayElements.
Change-Id: If767d3295d5a663a823e5ca0cd979379a3ccd024
Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
Added Surface.setPosition(float, float) which allows to set a surface's
position in float.
Bug: 5239859
Change-Id: I903aef4ad5b5999142202fb8ea30fe216d805711
We now (a) use the right Class getName() method, and (b) look it
up once at setup time rather than doing that lookup every time we
want to emit the warning. Verified to work properly and no longer
crash or throw or otherwise complain.
Change-Id: If0767f8845588ba7f34bac21474f4e2ad5c111d6
If the native-side bookkeeping still has strong references to VM-side
DeathRecipient objects at the time when it's being torn down, that
suggests that the app is doing unwholesome. Log a warning to that
effect, with the class name of the objects to try to help the developer
figure out what they're mishandling.
Fixes bug 5202777 -- in particular, it no longer logs in the
working-as-intended case following delivery of the death notices,
when we've got the existing list shell but the weak refs have properly
cleared. Also step down from "error" to "warning" logging as befits
the nature of the actual situation now being described.
This new patch fixes the JNI bug present in the earlier version.
Change-Id: I095862777a8d0e3905cb7f416af658878280041d
If the native-side bookkeeping still has strong references to VM-side
DeathRecipient objects at the time when it's being torn down, that
suggests that the app is doing unwholesome. Log a warning to that
effect, with the class name of the objects to try to help the developer
figure out what they're mishandling.
Fixes bug 5202777 -- in particular, it no longer logs in the
working-as-intended case following delivery of the death notices,
when we've got the existing list shell but the weak refs have properly
cleared. Also step down from "error" to "warning" logging as befits
the nature of the actual situation now being described.
Change-Id: Ic393560824800fbd912a6e69692c65be4fcc7544
Health device channel deletion was looking at the
wrong dbus interface.
Reported by: Sungjun<sj222.choi@samsung.com>
Change-Id: I48e7c464fdcdd8bd47dc8cc9cd55b14ba8ea6bbf
The native-side death recipient object holds a global reference
to the DVM-side DeathRecipient instance. This is necessary so
that the DeathRecipient isn't GC'd early in the case when the
caller of linkToDeath() doesn't retain their own reference to
the recipient instance.
However, that global reference was never being released in
association with the delivery of the actual binderDied() event.
In that case, if the death recipient did not explicitly call
unlinkToDeath() themselves, the hard global reference was
maintained and a hard-reference cycle was perpetuated, crossing
the native <-> DVM boundary. This was visible as a gradual
leakage of DVM-side DeathRecipient and BinderProxy instances.
The one problematic constraint is that it needs to be valid to
call unlinkToDeath() cleanly *after* binderDied() is delivered
to the given recipient; that requires that we have the hard reference
linkage described above. The fix is to replace the hard global
reference with a weak reference to the DVM-side DeathRecipient
after we deliver binderDied() to that recipient. In the case
where the caller has retained their own reference to the instance
(i.e. they might still call unlinkToDeath() on it later), the
weak reference stays live and everything works cleanly (and is
reaped explicitly by unlinkToDeath() as usual). In the case where
the caller has *not* retained the instance to call unlinkToDeath()
themselves, demoting to a weak DeathRecipient reference allows
the DeathRecipient to be GC'd, which in turn frees the DVM-side
BinderProxy it's tied to, and so on around the chain to free
all of the associated allocations.
Fixes bug 5174537
Change-Id: Ia4ad76e667140cc2a1b74508bbba652ab31ab876
- revert back to old working code where the script was setup for Harfbuzz\
depending of the direction of the run
Change-Id: I7ec740732b51ccf05b6744b7f9d2fcb35555478d
On some occasions when the event loop thread and a binder thread are
both waiting for a message from dbus, both threads are not woken up
when a message is received. This causes applications not receiving
responses or events. This happens because both threads are listening
to same socket and both threads are not guaranteed to wake up when
there is data to read. To fix this we subscribe to callback to wake
the eventloop when an message is added to incoming queue.
To reproduce the issue:
1. Activate BT
2. Make phone Discoverable
3. Clock is ticking down from 120s
4. At 20s tap the setting again
5. Crash due to keyDispatchingTimedOut
6. Not possible to scan for other devices or making your phone discoverable again
7. Restart necessary
Tell tale sign:
07-25 16:37:12.240 E/ActivityManager( 262): ANR in com.android.settings
(com.android.settings/.bluetooth.BluetoothSettings)
07-25 16:37:12.240 E/ActivityManager( 262): Reason: keyDispatchingTimedOut
Test case to verify this patch:
android.bluetooth.BluetoothStressTest#testDiscoverable
Change-Id: I7696b5722805e85cd0204ce2597e91594cbe6789
This removes the ParcelSurfaceTexture class since that functionality has been
folded into Surface.java. The change also updates the MediaPlayer to get rid
of setParcelSurfaceTexture() and modifies setTexture() to use the new Surface
functionality in order to simplify the code.
Change-Id: Iafa75ea3188263928128325d8a726786971b4de4
Bluetooth fails to turn on after 64 iterations.
When setUpEventLoop is called, Adapter is not ready yet.
However, we have already added the Dbus match rules. These match
rules are not deleted and we hit the dbus limit.
Change-Id: If207d4d33574685520a852b53a641adfbeb45d43
Author: hyungseoung.yoo <hyungseoung.yoo@samsung.com>
- better check parameters consistency
- return calls as soon as possible (when null or empty text)
Change-Id: I46744e517b04e3fba0ec37132d7de400177f214b
Make sure that files that don't exist aren't returning bogus 'out of
space' error codes.
Add some Javadoc so I can remember what each thing does in an IDE.
Add copyright header to NativeLibraryHelper
Bug: 3375299
Change-Id: Iac46019160921daca65b21d38897e5165063316e
The Harfbuzz script setting was wired to HB_Script_Common for left-
to-right text and HB_Script_Arabic for right-to-left. This change
selects from additional scripts using some utility APIs from
Harfbuzz.
Change-Id: I34a6f1e0407c8d122bc968443948e7863d1f91ed
