Don't automatically grant all normal/dangerous permissions. Instead,
check the value of requestedPermissionsRequired to see if it's required.
If the permission is not required, then only grant it if the permission
was previously granted to the application.
Change-Id: I86b1fae530c006d353f9fa22137598bc88253805
Using sendMessageAtFrontofQueue() causes issues here since there can be a start
that is deferred and it basically has no effect. Use defer which is more clean
and obvious here.
Bug: 8410547
Change-Id: I4fbf299283847e7c3009b87a81cb56e765b0e1e1
ListView child views with transientState (setHasTransientState(true)) are not
handled correctly when the data set changes, such as when an item is added
or removed. The problem is that the transient views are cached by their
position, but this position is out of sync between the ListView and the adapter
until the ListView layout process is complete.
A better way, which unfortunately only works on ListViews with stable IDs, is
to cache the views by their itemID instead, and to use that ID to determine when
and where to reuse/retrieve a transient view during the ListView layout.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I2fc25e71ed6655af30b9c3f47fdf014e9b667616
The root cause is:
There is a defect in window manager service: When a new
activity that can be ime target is added into window manager
but the Z order of input method window don't need to be
changed, then the target app token of input method window
would not be updated to new one. This defect may cause that
the layer of input method window is calculated incorrectly.
The solution:
Correct the target app token for input method window.
Change-Id: I008311e3c9b1cf5fc320b614d8675c183c506d50
Currently, NetworkManagementService only catches RemoteExceptions
when calling the BaseNetworkObserver notification methods (e.g.,
interfaceStatusChanged). However, if the observer is in the same
process, unchecked exceptions can occur as well.
When this happens, finishBroadcast does not get called, and no
further notifications can be sent, because any attempt to do so
fails with a "beginBroadcast() called while already in a
broadcast" exception.
Fix this by catching RuntimeException as well.
Bug: 8397534
Bug: 8276725
Change-Id: Icd6f32128707244978943c48a9ea3a2b952a2957
bug:8401910
This avoids leaving the renderer in a state with stale pointers (to,
e.g., shaders or color filters)
Change-Id: Idf8b63657041352e70e34e91ea416fe4385d4bc2
Removes mMultipliedAlpha, using the snapshot alpha for all
non-overlapping display list alpha control.
Additionally, fixes opacity issues where children of
hasOverlappingRendering=false displaylists (both hw layer sublists and
other sublists with hasOverlappingRendering=false)
Change-Id: I6adc16da855835f9f518f8967628e5d0135c789b
It is useful, particularly in animations, to be able to add a view, or at
least some graphics, on top of a view. For example, to have a child of a layout
fade away, we might want to remove the child from that layout and then fade it out
gradually. Meanwhile, we have to have a place to put that view where it will be
drawn. We could do this in the content container sometimes, but this is not a
reliable workaround in the general case, and may obscure other siblings/parents of
the layout/view in the hierarchy. A better approach would be to place a view/graphic
temporarily in the layout itself.
This feature adds the ability to add one or more Views and Drawables to an "overlay"
layer, after which the view will handle drawing that extra content when it redraws itself.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I70bf78c46ee3db8bd87ea1cdc2ecb5c0747ccbf9
