The update is that Downtime is obsolete. Replaced by the
ability to define multiple named schedule calendars.
- Make changes to ZenModeConfig to properly model manual
and automatic rules.
- Refactor the zen mode helper (and supporting classes) to
properly handle / report multiple claims on zen mode.
The "manual" rule (specified by the user in the UI) vs
one or more automatic rules.
- Automatic rules are still backed by condition providers,
but the layering is now cleaner. ConditionProviders is now
completely generic, has no ties to zen mode.
- Specifically, the new layering for zen mode (below noman) is:
ZenModeHelper: Source of truth for zen state
ZenModeFiltering: Subhelper dedicated to filtering rules.
ZenModeConditions: Subhelper dedicated to managing automatic rules.
ConditionProviders: Underlying engine for reporting named boolean state.
- Migration story for users with existing downtime config, migrated
to a single new calendar named downtime.
- For users with no existing downtime, two default calendars are created
for weeknights + weekends (icu4j for all locales will be done in a followup).
- Remove obsolete DowntimeConditionProvider/NextAlarmConditionProvider and tracking.
- Clean up obsolete resources.
- Add common zen summary description string computation.
- Add proper noman wrappers for the new model.
- Change the semantics of the global zen setting. It is now read-only. Setters
must call noman, added a "reason" to all calls for better attribution.
- Update zenmodepanel + volumedialog to the new model.
- Display the one or more automatic rules in the new zen footer summary.
- "Snooze" the automatic rules when the user explicitly turns zen off.
Bug: 20064962
Change-Id: Idd9deb865a6035ad0cfae660198dccb517e6d7cc
- relax a bit Intent resolution. We should still include Apps that
do not support Web domains :-) so in that context add in the result
list the Apps that are with a status INTENT_FILTER_DOMAIN_VERIFICATION_STATUS_UNDEFINED
Change-Id: Ibad7b7f577552ac75bba256bb387a75b83524958
- add domain verification priming at boot when the PackageManagerService
singleton is created. This will mainly set the domain verification status
to INTENT_FILTER_DOMAIN_VERIFICATION_STATUS_ALWAYS for all Apps that
have an IntentFilter with action VIEW and data scheme HTTP or HTTPS.
- also optimize Intent resolution by taking into account Browser Apps
Change-Id: Id8e66c9759a99e79b07051595ca89a168dc5ae0e
We don't want to continue trying to start the service if the service
appliction is dead. This will lead to an NPE later on since we have
set ServiceRecord.app to null in the finally block.
Bug: 5227987
Change-Id: I3ee5111f4a20d9455fedbf41ac54d41c43aa8d76
The original logic lets windows be able to freeze screen again (by
setting win.mOrientationChanging=true) after WINDOW_FREEZE_TIMEOUT is
triggered before mInnerFields.mOrientationChangeComplete is set to
true. In this case, we would lose the protection of
WINDOW_FREEZE_TIMEOUT. If the app never finishes drawing the window,
the screen would keep freezing that the user cannot operate the
device.
Change-Id: I45a0a9e4b3f8d5b0b0043229bfa4890236ae8ab2
Symptom:
In some scenario, the mPausingActivity may be replaced by other
activity. When previous activity paused, the completePausedLocked()
won't be invoked because it is no longer the mPausingActivity. If
the activity is also pending to finish, it would never be done
because the activity kept in PAUSING state. Since the activity's
window also remain visible and is above on Wallpaper, user would
see it when back to home.
Solution:
Finish the failed-to-pause activity if the activity is pending to
finish.
A Real Case:
(1) Screen turn off
(2) The top activity T1 crashed
(3) When finish activity T1, the next top activity T2 will be
scheduled to resume and pause (due to screen off).
(4) The activity T2 is also set to finishing due to T1 crashed.
(5) Before T2 paused and before paused timeout occurs, there has
a new process started which brings up the next top activity T3
to resume and pause. So the pausing activity is now replaced.
(6) When activity T2 paused, it cannot completed the pause operation
T2 will remain in PAUSING and finishing state with its window
visible. The process won't be killed because the oomadj stays
at 1 (Visible).
Change-Id: Ib10fded891b21c774b26a93071c717fa50516e22
- add private API PackageManager.getAllIntentFilters(String)
for getting all IntentFilters from a given package
- update IntentFilterVerificationInfo to use an ArrayList<String>
for domains instead of a String[]
- if you make an App a default domain handler then make the
others as non default
- create an IntentVerificationInfo even if the App IntentFilters
do not need to be verified. This would be done only if the App
has some domain URLs defined and would allow to make it the
default handler for a domain
- a few code optimizations here and there
Change-Id: I4535372a0bb1a2c8e662e1485be8ca700003e9b3
Currently a 'touch modal' window grabs drag events
from the entire screen. Since 'touch modal' is the
default, this makes dragging between apps impossible.
This change allows such grabbing behavior only for
events that are still over the same activity stack.
Bug:19548858
Change-Id: I7d48b58e7fcb620521361e17cb70914913afae03
For heapdump functionality, there's no need to give apps
readable/writable file descriptors. An append-only file descriptor
is sufficient.
Bug: 20073185
Change-Id: Ib2c42a72b2704db5f1b919c24e33609f7a45e57a
When relaunching a parent activity we finish all its children and set
a 2sec timeout to clean up their tasks/stacks/displays if we don't
hear anything back. This time might not be sufficient for the client
activity to respond back in time depending on what else is happening
on the system and we might end-up prematurely removing its display
which will cause it to crash. In this specfic case, the client
activity which wasn't the focus activity was been relaunched with a
bunch of other activities due to a configuration change.
Instead of having a timeout for the clean-up we now let the activity
go through the normal clean-up process that occurs as it changes
states which will eventually clean-up the right states in a max.
time of 10secs (on destroy timeout) or sooner. This is in line with
activity cycle expections.
Bug: 17702043
Change-Id: I484124e07ad32b9056f75ec41af1dd7718488335
When VideoView calls setFixedSize(), the SurfaceControl.setSize()
gets called from WindowStateAnimator.setSurfaceBoundariesLocked,
but setSurfaceBoundariesLocked only updates the size, not the
transform matrix/scaling factor.
The after some time, SurfaceControl.setMatrix gets called by
WindowStateAnimator.prepareSurfaceLocked. It updates both size and
matrix (size update is skipped since it's already updated by
setSurfaceBoundariesLocked earlier). This corrects the transform
matrix, and restores video rendering.
We now call setMatrix() in setSurfaceBoundariesLocked() to avoid
the glitch.
Bug: 18773834
Change-Id: I5e8de38495fabe54eefa8bd3003627d11392c0f1
When a new package is created, installNewPackageLI does not need to call
dexopt, since it has already been made.
Bug: 19550105
Bug: 20087446
Change-Id: If6b05bea590eea5f95efebb22a67ccd8cdf632c2
Currently worker threads in computeBestConfiguration may NOT completely
finish before timeout. But the code will start using the result while
the worker threads are still working on the same object. This may
cause exceptions.
b/19966623
Change-Id: I62ffcb796d648891ee339b6a978f575ebad8352b
In order to check the DevicePolicyManagerService locktask whitelist
the activity manager had to release its lock preserving internal
state. That is undesirable and not scalable now that we need to check
the whitelist at startup for bug 19995702.
This change causes DPMS to update activity manager with the whitelist
whenever it changes so that activity manager can check the whitelist
without releasing the acitivty manager lock.
Change-Id: I3ed6eb5ceae2cd7e7ae3280abd708d5ce43a2851
When an activity stops drawing following a rotation the rotation
screenshot would become stuck on top of all the other windows. The
timeout was being acknowledged but mWindowsFreezingScreen was set to
true which kept stopFreezingDisplayLocked() from dismissing the
screen rotation animation.
By changing mWindowsFreezingScreen from a two state variable to a
three state variable, including a timeout state we allow
stopFreezingDisplayLocked() to continue and dismiss the screen
rotation animtion.
This change also reduces the APP_FREEZING_TIMOEOUT from 5 seconds to
2 seconds.
Bug: 15664090
Change-Id: Ida5aca002a82ec8fe1ea99f0ced814c5c8f01a95
