can get location updates too frequently by repeatedly calling getLastKnownLocation
or by registering/unregistering location updates frequently.
Change-Id: Ibd9ce28b0401372b995a0dbfb2f0a984dd11c0b1
Adding a view to an overlay usually entails removing the
view from its current parent, if it has one. ViewOverlay.add() will
do this automatically. At the same time, it will check to see whether
the parent view is in a different global location than the overlay's
host view, and will adjust the added view accordingly. This enables
the caller to simply toss a view into an overlay and have it end up
at the same global position on the screen.
the problem is that the current code doesn't bother to check whether
the old parent is attached. If that parent has been removed from the
view hierarchy before this overlay operation, then it will show up as
being at (0,0) in the window, not its old location. This results in the
view being mis-positioned in the overaly.
Fix is simple: if the view's old parent is not attached, simply remove
it from that parent before adding it to the overlay; don't try to compensate
for its position which is based on wrong information.
Issue #8620319 Overlay should only use relative window locations for onscreen parents
Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
Merge simple bitmap draw operations and text operations to avoid
issuing individual gl draws for each operation. Merging other ops to
be done eventually.
The methods are different - the bitmap merging generates a single
mesh for reused, unclipped images (esp. repeated images in a listview)
The text approach queries just defers the normal font rendering until
the last drawText in the sequence that can share the same shader.
Patches are sorted and merged, but don't yet have a multiDraw
implementation. For now, the pretending-to-merge gives better sorting
behavior by keeping similar patches together.
Change-Id: Ic300cdab0a53814cf7b09c58bf54b1bf0f58ccd6
Anyway they need to request account access and user will be asked to approve access to the account
at runtime.
Bug: 8617168
Change-Id: I31de852b9bb25f496becc3e6470265b5c330e6ad
Add the encrypted flag for the KeyPairGenerator and the KeyStore so that
applications can choose to allow entries when there is no lockscreen.
(partial cherry pick from commit 2eeda7286f3c7cb79f7eb71ae6464cad213d12a3)
Bug: 8122243
Change-Id: I5ecd9251ec79ec53a3b68c0fff8dfba10873e36e
On eng builds we have an event consistency verifier to log any
inconsistent event stream states due to mishandling of intercepted
events by an accessibility service. On non-eng builds this verifier
is null and a null check was lacking.
bug:8616711
Change-Id: Ib083a405dfa8340025090a65e50155eb10526a90
If the connected service is not entirely setup when calling the method for
handling a change in the current user state we get a potential NPE since
the management method may have discarded the service, thus nullifying the
connection to it. Now the service is fully configured before calling the
state change management method.
bug:8600489
Change-Id: Ib0bf7c6d575e15c620da419d43ece22f4187fd34
This covers all useful data from the basic Builder as well
as each of the Styles that is not otherwise captured on the
Notification object itself.
Extras are now prettyprinted in dump() output.
Bug: 8270485
Change-Id: I47fc50860dab6409793f57e904cc60296310d5cf
In order to let apps use keystore more productively, make the blob
encryption optional. As more hardware-assisted keystores (i.e., hardware
that has a Keymaster HAL) come around, encrypting blobs start to make
less sense since the thing it's encrypting is usually a token and not
any raw key material.
(cherry picked from commit a3788b00bb221e20abdd42f747d2af419e0a088c)
Bug: 8122243
Change-Id: Ifc1c64743651b23a4eace208ade0176af47ea989
