Call out specifically that each helper must only consume the
prior-state data that it produced in the first place, not reading
beyond its own part of the state file.
Bug 25473872
Change-Id: I1f24a5738a799eb21d966510372a0f3852436166
The disk-friendly use of BufferedInputStream in state parsing was
actually breaking the state management system when multiple helpers
are involved in backup. The BufferedInputStream would blithely
pre-fetch 8K from the state file -- but that would consume some
state data that the dispatcher and subsequent helpers needed to see
in order to properly evaluate prior state themselves. The contract
here is that when using the helper mechanism, state-data consumption
must *only* consume as much data as the helper originally stored
into the file.
Switching to a direct-read stream instead fixes the problem by
avoiding read overrun. The rest of the changes are expanded
debugging output that made diagnosis possible.
Bug 25473872
Change-Id: I91de38dfec96f589700479f41ac26f144ba4463c
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
Helps make the code easier to follow since we are no longer checking
multiple stack ids at various decision points.
Bug: 25282299
Change-Id: Ifa6864a1ef56ce2eca4c94f87a4e0b993de987cd
The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time. The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered. If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped. This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.
The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method. There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.
An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler. If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
There are two improvements in reporting size configurations:
1) duplicates are removed;
2) smallest width is reported separately;
Change-Id: I8f8235c99e6eefcae178e8d61e79ad0c4d6f1144
- 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
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
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
* 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
