- need a copy constructor for the key as the GenerationCache we are using
is actually a KeyedVector<K, sp<Entry<K, V> > >
- use the getText() API to access the text in the cache key
Change-Id: I5b60ebc062b62308ed7ac1284cfe2a9f28e2b8b1
- makes TextLayoutCache not carring about start/count. Basically he will cache the result for
the full string and gives back the "chunk" corresponding to start/count
- changed the TextLayoutCacheValue API to take start/count parameters
- added the Harfbuzz LogClusters in TextLayoutCacheValue as it is needed for extracting the start/count "chunk"
- fix potential issue of cache key leaking
Change-Id: I9276f9bec744e8de36349acfba8429f7c6f83394
* Instead of javaland trying to write commands to
/proc/net/xt_qtaguid/ctrl
use the libcutils/qtaguid.c support via JNI.
* Get rid of tagToKernel() handled by qtaguid library.
Requires libcutils changes from c/132538/
Change-Id: I9de5b3fa4a596c56835024c6d376769a0eea7db1
...mode cuts off screen rendering
The code for limiting application window sizes to not include the
navigation bar was dead. Now it is back.
Change-Id: Ic0bde56e3300fd0d9d225e19d8de2766d07e8780
Bug: 5265529
Rewrote the velocity tracker to fit a polynomial curve
to pointer movements using least squares linear regression.
The velocity is simply the first derivative of this polynomial.
Clients can also obtain an Estimator that describes the
complete terms of the estimating polynomial including
the coefficient of determination which provides a measure
of the quality of the fit (confidence).
Enhanced PointerLocation to display the movement curve predicted
by the estimator in addition to the velocity vector.
By default, the algorithm computes a 2nd degree (quadratic)
polynomial based on a 100ms recent history horizon.
Change-Id: Id377bef44117fce68fee2c41f90134ce3224d3a1
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
