When the navigation bar was originally introduced to phones
(in change Ic613a335) we wanted it to stick to the same spot
on the display so that it felt as much as possible like a
physical button array; pressing the same fingertip-sized
spot on the glass should always invoke BACK, etc. This meant
flipping the nav bar to a vertical orientation when the
phone was in landscape, and then juggling around the window
insets and other system windows to make room for it.
For reasons that are now lost to time, in that original
implementation we made the vertical navigation bar narrower:
42dp (versus 48dp for the horizontal navigation bar, which
incidentally is always horizontal on tablet-type devices).
Nobody really noticed (except app developers looking to
hardcode this value instead of just using fitSystemWindows
or the new WindowInsets).
Here we finally make the navigation bars match perfectly in
portrait and landscape.
Bug: 23724209
Change-Id: I861be84b41c6a227d269469686c8c66a32029f1d
When 2 notifications were posted as the summary of the same
group, then the system would eventually crash.
Bug: 23676310
Change-Id: Ia8f95e624f3f43d1b55169dd8102e3c89427dc76
The typedArray depends on the current context (more specifically, the
themes set on the context). The fact was ignored in the caching of the
typedArray and caused the android:theme attribute to be ignored in
certain cases.
Change-Id: If095580919474f12c0eb4e1f8fb7f076cf3c4ed0
Move SUPL CONNECTIVITY_ACTION bcasts to a different, hidden intent
to reduce the churn of apps when SUPL comes/goes.
Short term hack until SUPL moves to use the new APIs and there's
no bcast.
bug:23350688
Change-Id: I3dc14b42afa72465260aa41ccedfe1df27baabd9
An intent broadcaster can specify which permissions should be
held by a receiver to get the broadcast. These permissions may
have corresponding app ops and if this is the case we also
check the app ops. There is a bug in broadcast queue where if
a permission does not have an app op we still try to check this
app op and get an exception as the app op does not exist. This
did not manifest often because the broadcast API takes an
optional app op against which is compared the app op for each
permission and if they differ the app op for the permission is
checked.
bug:23725305
Change-Id: Iec56ee354bbc11e7bc245134cf3afd2c11eecbc4
In order to prevent sendind a CONNECTIVITY_CHANGED broadcast for SUPL
connection changes, which can cause many apps to wake up, as a
work-around use a separate action.
Bug: 22729462
Change-Id: I9847603ae56ab90d0f230cdcdc046c710397a553
Looks like the phonenumber util can figure out the country code of a
phone number to format from the localization data even if it is not
explicitly present in the phone number string. So, adding an explicit
check to make sure that the country code(+82) was fetched from the
original number string which was the intention of the fix for
b/22862845.
BUG: 23661668
Change-Id: I26ba03d759e0ec35a195ba51bf60d09eff8de090
When we detach the stack from the display we are in an inconsistent
state. We need to finish that operation, before we start laying out
things again. Otherwise we will encounter subtle bugs, where stack is
partially closed, but still used during the layout.
Display detachment was already doing the right thing and scheduling a
layout after it finishes the display detach. However, removing the
stack's windows was triggering immediate relayout and causing a crash.
This CL also adds some missing synchronization around
WindowManagerService.mStackIdToStack, which is in most cases protected by
mWindowMap.
Bug: 22191609
Bug: 23615329
Change-Id: I1e2fc42e1a5b673be808acdec473f85f138d7062
The SIGCHLD handler can set the errno, which can change the errno found
on the thread on which the signal handler is invoked. Most of the time
this is harmless, but it's possible that if the main thread was making
a system call, and allows certain failures based on errno, that logic
can fail. The fix is to save/restore errno in the handler.
Bug: 23572286
Bug: 23689391
Change-Id: I4542fd60cc1398ce0a8902d8df98a3d089fb6efe
