A lot of calling framework code expects a null value on failure,
and didn't catch the previous exception. There were some strange
corner cases where previously a null value was not checked for
in framework code, allowing the null Resources object to be
returned to the caller. Introducing an exception changed the
semantics and can crash certain apps.
Bug:30422475
Change-Id: I51d34ae43c9ec605a8790989c56cf85b815ff5b8
According to the Bluetooth Core specification v4.2, Vol 3, Part G,
section 4.12.3: "The Attribute Protocol WRITE REQUEST is used
for this sub-procedure".
Change-Id: I141dd24ed5911d5d485b52a1b661835b9960921a
Prior to N, our widgets were not converting MarginLayoutParams
properly between ViewGroups. The fix intrudced some issues in
older apps as the broken conversion code would hide developer
errors. This CL guards the change with a target API check so
that we don't affect older apps.
Bug: 30378230
Change-Id: I215281d261b553c3b4cedcd29ea0a861df809471
Bug: 30587465
Someday maybe the technology will exist to
allow sharing a simple constant between
Java and C++, but today is not that day.
Change-Id: I17694746cb8712058133cd5ea10c47b9909f740b
When "handling" an uncaught exception, make an attempt to stop
profiling. In case profiling was active, this will avoid losing
the profiling buffer.
This change is required as a base in order for
https://android-review.googlesource.com/#/c/249721/
to merge cleanly.
(Cherry picked from commit 4c79fea9ef)
Bug: 26291225
Change-Id: I35f352e5f28eafe4702da9eae587c3b65c360b3a
Changes in alpha only matter if they affect visibility,
so only 0 <-> nonzero changes are worth reporting. Report
them as subtree changes, as visibility affects subviews.
Not reporting every change greatly reduces the number of
event reported when alpha is animated.
Bug: 30183085
Change-Id: I905d53aa81ca8248b3aed86a91842ef499f303a8
Previously AbsSeekBar always rounded up, which resulted in poor handling
of touches near the edge of a progress value. We fixed this but forgot
to adjust RatingBar for the new behavior.
Bug: 30558586
Change-Id: I634fa7a0b98568093e16279ef5a80abe08d2e2fe
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Icc8f8dbd060762ae1a7b1720e96c5afdb8aff3fd
