- This allows us to remove an extraneous system call when starting
overview, and also allows us to easily check for freeform windows.
Change-Id: I4449dad7bf870f528f671f6e7cb1f9b5f1bc9c1c
- Now DPMS remembers user restrictions set by DO / PO in their ActiveAdmin.
- User restrictions set by DO/PO will no longer be saved by UserManger. Instead,
when needed, UMS will consult DPMS to build "effective" user restrictions.
- UM.getUserRestrictions() will now always return "effective" user restrictions.
- DPMS migrates existing user restrictions per the eng spec.
- Also now UM.setUserRestrictions() will crash. UMS.setUserRestrictions() has
been removed.
This was needed because UM.setUserRestrctions(UM.getUserRestrictions()) will no
longer be a valid use like it used to be.
- Also introduced a fined-grained lock for user restrictions in UM to avoid
deadlock between DPMS and also for better performance.
Bug 23902097
Change-Id: If0e1e49344e2f3e9226532d00777976d1eaa7df3
Added GET_DEFAULT_IMES flag to AppsQueryHelper. Default system IMEs are now
enabled for system user.
Bug: 25276229
Change-Id: I38d74903951200e2207e1864bb3a815f8f2d572f
When docking from recents we would move the task to the docked stack,
but we wouldn't run the resizing code that forces the task to be within
the stack bounds. We need to perform both operations and we can achieve
that using a more general method of moving tasks.
This also adds the passing of creation mode in the activity options, so
the task will be docked in the right spot.
Change-Id: Ia7f94a7e3677ed60ca2f4d889e548d80a3bc3df1
Add a development setting to force all activites to be
resizable. Currently, a restart is required after changing
this setting. Also remove all the code that forced a single
task to be resizable, as we have a global option now.
Bug: 24815256
Change-Id: I3237c9b6ce96ff9aa9819592ab0c2807fde88dc4
Builder now stores its parameters directly in the
Notification object itself, reducing the amount of copying
needed to construct the final Notification as well as
converging the two data structures. All Builder data is now
captured in Notification, so it is easy to reconstruct
a Builder for any Notification object.
This obviates all stripping/unstripping operations because
all Notification objects start life "stripped" of their
RemoteViews, which must be constructed explicitly by clients
(presumably listeners wishing to show the notification to
the user in its conventional form).
Note: While contentView, bigContentView, and
headsUpContentView are being @Deprecated in this CL,
specifying custom RemoteViews is definitely still supported!
You just have to use Builder methods to do so.
Bug: 20153922
Change-Id: I81f8ffed0eb76084b2f2b25b97e325858f0a1d05
While it makes sense to be able to resize most activities types
in multi-window mode. It only makes sense to put specific types
of activities in Picture-in-Picture (PiP) form of multi-window.
For example, activities that play video will be good candidates
while the Settings activity isn't.
The new flag allows the system to differentiate between resizeable
activities that can go into PiP mode and those that can't.
Bug: 25006507
Change-Id: I8ac518cec2fa3c8fb88be40c266b3751fb88f1ce
* AMS.moveTopStackActivityToPinnedStack can be used to move the top
activity in a stack to the pinned stack and also specify the bounds
the pinned stack should be sized to.
* 'am stack move-top-activity-to-pinned-stack' command for testing
AMS.moveTopStackActivityToPinnedStack API
Bug: 25006507
Change-Id: I8392b4c39d8542153e691be7a627b7f35fd44884
f3a62fbc58bbc7f081a53248cae48a8951294e8f added support for drawing
the background draweable when resizing an activity window.
However, after some additional discussion we decided that
R.styleable.Window_windowResizingBackground and
R.integer.config_windowResizingBackgroundColorARGB are not needed.
We use R.styleable.Window_windowBackground for the background
drawable and fallback to using R.styleable.Window_windowBackgroundFallback
which is now public if the first isn't set.
Bug: 24534744
Change-Id: Ia0507e25a1893ea941d259f1d4e88ce500dda154
A recent change in how the handler is created in KeyboardView
caused the password change flow to crash in ChooseLockPassword.
Change-Id: Id5fcb256f9a09b75bf91c5c79614d8abfc29747f
We will allow apps to disable Share, Web Search, and text
processing related menu actions.
The default actions like cut, copy, paste cannot be disabled.
BUG: 22772178
Change-Id: I8429454f71f74a99298f412862cd32d8fba93784
Also, compute LocaleList's string representation at construction.
This is to further push the cost of doing costly operations related
to LocaleLists to construction time.
Change-Id: Ia55b8ce66b1088ff54cb42eb1e11149b5bd10f17
Also enlarges the touch targets for the AM/PM buttons by redirecting
unhandled touches within the containing view group.
Bug: 20257430
Change-Id: I28e8d8894a4702116bb68cc6a6d4115e5aa87a69
