The battery service just implements the existing commands that
are available through dump.
The activity service implements the small set of commands that
are available through dump (not the rest of the dump commands),
and also introduces some of the simple "am" shell commands as
a proof-of-concept of moving those into the service implementation.
Change-Id: If5ff80930dde787703e2682e43c36ce1dab05d69
Doing this while dragging is really necessary for System UI shelf.
Also, not forgetting to remove the child from the "interested" set when
the child is removed.
Bug: 25231591
Change-Id: I26f5086a0a842868b2d7e9809f7483152098f314
(cherry picked from commit a82c8709f0914064f4b00262f1d411594bab467f)
This is needed in order to allow implementations of the HFP HF side to
define when audio can be routed to the device. This allows for calls dialed
from an AG to be kept on the AG if desired.
Bug: 25332357
Change-Id: I35a554cfc53f88c7dd3059bf52df5c69df9c7415
The new version provides more information about the origin of
the load, which helps making more secure decision on how to proceed
with it.
Bug: 22346196
Change-Id: I27f591bf5e846bde14335a2c929758a2b48d0763
- 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
Also shows anchored menu on D-Pad long press and uses the center of the
view as the anchor point. This is how we already handle hotspot feedback
when there is no explicit center, so there's no visual change there; it's
just more obvious from the View side of things what the result will be.
Bug: 25215353
Change-Id: I930c3aeffc993b7c553ffb626d1b5103c6cb1267
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
The javadoc for CameraManager.AvailabilityCallback was missing an "#".
This causes the link to registerAvailabilityCallback not being generated
correctly.
Once the "#" was added the link shows up correctly.
Change-Id: I3da3aa737a6af487f117eccbeee5c682c003b7e2
