When user collapsed QSPanel at non-first page, QuickQS always remained
View.Visible. When user canceled collapsing, QQS remained clickable
although invisible to user(alpha = 0).
QQS must be non-clickable when user cancels collapsing at non-first page.
Test: QSPanel > 2nd page > Cancel collapsing while collapse QSPanel
> Verify invisible QQS is non-clickable
Change-Id: I4c1f195a3faec8e89bb073443f6345f4faddf781
When users try to open panel, initialization of accessibility is called
in Main Thread by this callstack.
at android.view.ViewGroup.buildOrderedChildList
at android.view.View.populateAccessibilityNodeInfoDrawingOrderInParent
at android.view.View.onInitializeAccessibilityNodeInfoInternal
at android.view.View.onInitializeAccessibilityNodeInfo
at android.view.View.createAccessibilityNodeInfoInternal
at android.view.View.createAccessibilityNodeInfo
at android.view.accessibility.AccessibilityRecord.setSource
...
at android.view.View.setFlags
at android.view.View.setVisibility
at com.android.systemui.qs.QSContainer.updateQsState
at com.android.systemui.qs.QSContainer.setExpanded
at com.android.systemui.statusbar.phone.NotificationPanelView.updateQsState
And another initialization is tried in QSTileHost Thread by this callstack.
at android.view.ViewGroup.buildOrderedChildList
at android.view.View.populateAccessibilityNodeInfoDrawingOrderInParent
at android.view.View.onInitializeAccessibilityNodeInfoInternal
at android.view.ViewGroup.onInitializeAccessibilityNodeInfoInternal
at android.view.View.onInitializeAccessibilityNodeInfo
at android.view.View.createAccessibilityNodeInfoInternal
at android.view.View.createAccessibilityNodeInfo
at android.view.accessibility.AccessibilityRecord.setSource
...
at android.view.View.announceForAccessibility
at com.android.systemui.qs.QSPanel.onAnnouncementRequested
at com.android.systemui.qs.QSTile.handleStateChanged
This race condition can cause crashes, because the same ArrayList
(mPreSortedChildren or mTempArrayList in ViewGroup) is modified by two
different thread.
Test : manual
Change-Id: I9e0ad1fef4be7dc378463c06d10854e0e4c5b3d6
This makes the policy for mixed HTTP/HTTPS content match Chrome.
This allows us to display login pages where unimportant
subresources are HTTP.
Bug: 32171569
(cherry picked from commit 625166377b2d7c5f09d1e7617b3eac3a464fba53)
Change-Id: Ia82958192d978280715442e182c34f9da5c88c66
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
