- Max 250 notifications preserved (was 1000)
- Known heavyweight extras are removed
- print some of 'em out in dumpstate, while we're at it
Bug: 8280039
Bug: 8537938
Change-Id: I9239128c32a1d9f5ef4e0dc62dc2d23e190871e9
It is possible that an accessibility service's package was force stopped
during whose handling the death recipient is unlinked and still get a call
on binderDied since the call was made before we unlink but was waiting on
the lock we held during the force stop handling. Added a check whether the
service is already disconnected and if so do nothing.
bug:8600388
Change-Id: I4a9ca305b9863d986b930a7c1ec8f9006b16a333
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
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
