When QS was open while the we started with expansion, we
immediately notified about expansion finsihed again, which led to all
kinds of weird states. The change that introduced these bugs was to
fix another bug in which onExpandingFinished was not call. Make sure
to call in exactly that case and no other case to not risk
regressions.
Bug: 22806817
Bug: 22807359
Bug: 22807372
Change-Id: Id7daf37ef4a772f724971bf79c61084ff4279f31
Make sure to reset the keyguard drawn state in the correct place,
so we don't return early in finishKeyguardDrawn() because
mKeyguardDrawComplete is still true.
Bug: 22808662
Change-Id: I7e18e91c412c6cac7fe253837949602f76b7f270
Using View.post was really dangerous because when the view wasn't
attached, it got posted on the run queue of the *calling* thread.
However, that run queue was never executed until power down, and
then it was executed from the PowerManagerService thread, because
that was the calling thread when we posted it. Work around this by
using a solid Handler.
Bug: 22820787
Change-Id: Id60e49e859558993256fae0403236f2e4b6f1075
The current stack we are proccessing can be deleted as part of
the clean-up process, so the size of the stack list is reduced
by one.
Bug: 22822743
Change-Id: I6a6af5d8d811e231f345f01dd2aa4a61510c8d2b
changes)
AppOpsManager:
Changed the default operating mode for WRITE_SETTINGS to MODE_DEFAULT from
MODE_ALLOWED.
packages/SettingsProvider:
We no longer do static permission checks for WRITE_SETTINGS in early checks and
defer that to app op when MODE_DEFAULT is returned. For some operations,
checking against WRITE_SECURE_SETTINGS is sufficient.
ActivityManagerService & PowerManagerService:
Incorporated app op checks and handled the MODE_DEFAULT case.
provider/Settings:
Added helper function to do checks on whether app ops protected operations
can be performed by a caller. This includes checks for WRITE_SETTINGS and
SYSTEM_ALERT_WINDOW.
Also added a public API (with javadocs) for apps to query if they can modify
system settings.
Changed the javadocs description for ACTION_MANAGE_WRITE_SETTINGS and
ACTION_MANAGE_OVERLAY_PERMISSION.
Added public API (with javadocs) for apps to query whether they can draw overlays or not,
and also javadocs description on how to use that check.
Change-Id: I7b651fe8af836c2074defdbd6acfec3f32acdbe9
The problem is that, for 12-hour locales, we cut the "a"
part of the time format out to show it in a separate
TextView so it can be animated independently of the actual
time. Unfortunately, while TTS is smart enough to pronounce
"1:15 AM" as /wʌn fɪftin eɪ ɛm/, "AM" on its own looks like
the English word "am" and is pronounced /æm/.
To fix this, a TextClock must be able to accept separate
formats for its content description than its presentation.
With this capability we can place the complete 12-hour time
format (including am/pm) in one of the views and suppress
the other one, so that the utterance creates an identical
experience to visual inspection: "1:15 AM" for all users.
Bug: 21718000
Change-Id: Ic9920d71ae4d4ad41ba86d7bd96f9a19b07e2108
- remove the content description in Keyguard
- only show virtual views when pattern is in progress
- add a content description when the pattern is not in progress
Bug: 22646748
Change-Id: Id32a37c4c74c82b547cee8861b2856fa0a08c41c
If there is an app on the system image that gets default
grants but it is updated with a version that does not use
all permissions the version on the system image does, we
would wrongly try to grant a permission to the updated app
that it does not request and crash as a result. Now we
default grant permission that are requested by the system
version of the app regardless if it is updated but only if
the system app is not updated or the update also uses these
permissions.
bug:22800767
Change-Id: Ic22b62ba4976367420a56bdadc8e3824b0b9104f
Previously, excess space was added to existing measured dimensions.
This consistently resulted in incorrect allocation of excess space,
since the delta already included the height of any measured children
rather than just the excess space itself.
This CL ensures that excess space is always distributed according to the
layout weights.
Bug: 22810327
Change-Id: I482a553c469169769cc40ab3d88b4a44023f3eb5
DynamicLayout reuses a StaticLayout.Builder object to avoid having to
allocate. There is a "finish" method that releases any expensive
internal state of the builder object, but it didn't release a
reference to the text object (which in turn may contain references to
lots of other things, especially if it's a Spannable).
This patch releases the text, as well as a few other arrays, at time
of finish.
Bug: 22822416
Change-Id: Icc8b6cd41a9a2d11689df7bd1b9f524c6524f706
Now that we're relying more heavily on Uri permission grants between
apps, we should always return content:// Uris.
Bug: 22820206
Change-Id: Ie9603da09944dc594ea5dde2db04455f57d6f103
My previous change overtightened which permission flags can be changed
by a non-system caller. This took away the capability of the package
installer to set policy flags which it needs to implement the auto
grant/deny behavior.
bug:22776149
Change-Id: Ic2a82bedc413fc91360c3bcec355fac456f0fccf
