Collect related initialized users and start
them on boot and user switch.
Update list users command to show whether a
user is running or not.
Change-Id: Ib3d5debcb01ec55a07d93450b988b0180fc63263
It shouldn't tell the window manager to lock or freeze the
screen when starting a user in the background.
Change-Id: I24c6c19a20c360ecbed7d28e1d7249c025a463b9
This may mean that secondary networks have bad network settings,
but currently default settings are overriden by secondary nets
which seems worse.
bug:13211589
Change-Id: I3ef1a17ccde05306d786729c4369a31f78b2ebcf
Also add new API for determining whether the current data network
is active, and thus better scheduling network operations. This
API is designed to not be tied to a mobile network -- regardless
of the network, apps can use it to determine whether they should
initiate activity or wait. On non-mobile networks, it simply always
reports as the network being active.
This changed involved reworking how the idle timers are done so
that we only register an idle timer with the current default
network. This way, we can know whether we currently expect to
get callbacks about the network being active, or should just always
report that it is active. (Ultimately we need to be getting this
radio active data from the radio itself.)
Change-Id: Iaf6cc91a960d7542a70b72f87a7db26d12c4ea8e
This fixes the logic on the death handlers for notification listeners,
and doesn't unbind from the listener services so that the system will
bring them back up again.
Bug: 12587702
Change-Id: I44ce250e0e1c2583836dc823d9a333dabec51df9
The power manager sends SCREEN_ON and SCREEN_OFF broadcasts
purely based on the current wakefulness state. In particular,
when the system is awake, we consider the screen to be on even
if the screen may actually be off due to the proximity sensor
or some other condition. Likewise when the system is dozing
or asleep, we consider the screen to be off although technically
it may still be on and dozing.
This behavior is maintained for compatibility with applications
that interpret screen on / off as an indicator of user presence.
As it happened, the value of PowerManager.isScreenOn() did not
always match the state indicated by the broadcasts under certain
situations. Instead, it was based on the desired screen state.
These states used to be closely correlated but the addition
of doze mode causes them to diverge in meaning.
One consequence is that wake events from input devices might not
always wake the device from sleep unless the display's power
state was actually DOZING or OFF even if the power manager's
wakefulness was already DOZING or ASLEEP. This is now fixed.
Change-Id: Ie819c6d2c5a9ffaaf3101c5dee93ff72e9bc9f30
Added UsbConfiguration class, as well as accessors to UsbDevice to get configuration list
Added methods to UsbDeviceConnection to select configurations and alternate interfaces.
Also added accessors for USB descriptor name strings and fixed some memory leaks in the JNI code.
Bug: 12425052
Change-Id: Idb990f4d5c054a8cb997eb3f440f6da9f83bce05
- New global zen mode setting with three values:
ZEN_MODE_OFF, ZEN_MODE_LIMITED, ZEN_MODE_FULL
- Status bar icon (on lhs) when in _LIMITED / _FULL
- Rules are hardcoded for now:
_LIMITED = intercept all notifications except calls/alarms
_FULL = intercept everything
- UI affordance in shade to set mode
- Only one exit condition: "Until you delete this"
- Intercepted notifications:
- appear darker in the shade
- do not cause sound/vibration
- do not fire fullScreenIntents
- do not contribute an icon to the status bar
Change-Id: Ic36c95982b483432006bf9dab102a31370382aa9
The libskia target exports all of its public includes directories so
redefining them here is redundant. Also this cleans up and makes it
obvious where the framework is making using of private Skia headers.
Change-Id: Ie7ecc9ddd3df780bed6b9af54ba58ca58274e043
A deadlock sometimes happened in CreateRelatedUser of UserManagerService.
A lock was kept when it should have been released.
Change-Id: I15444c0b5d0d5d1e14e7bf29c2115aa954b7dfc0
We now compute radio active time per application, by distributing
the active time across all applications each time the radio goes
down, weighting it by the number of packets transferred.
Per-app radio power use is now computed using this radio active
time.
This also gives us a new metric "ms per packet", which give an
idea of how effectively an application is using the radio. This
is collected and reported as a new set of stats in the human-
readable checkin. (It can be computed from the raw checkin data).
Also improve sync reporting to include the sync source as used
in wake locks, not just the component name.
Change-Id: I0b0185fadd1e47ae749090ed36728ab78ac24c5e
Note that eventually VideoPlaneView should not inherit from SurfaceView.
Remove a few trailing spaces too.
Change-Id: Ia0a461169d560435a827861be2cc15f1e3ee68fa
- Add events for sync.
- Add more descriptive tags for wake events.
- Fix battery reset.
- Fix tracking of wifi data.
Change-Id: Ic07f2a86a5ed33e7da57eb1108c31c777ecd801f
Remove the recently added RIL_REQUEST_SET_RADIO_MODE command and update
the definition of the RIL_REQUEST_NV_RESET_CONFIG parameter.
Also remove some accidentally added debug log lines.
Bug: 12864208
Change-Id: I6f035d6900c9fcb1427bad62057d7b4a1d3cd99c
This optimizes the path for battery stats to collect
per-uid network usage. It now collects wifi and mobile
usage separately, with a path that allows it to recycle
all data structures and filter out stats it isn't
interested in before they come back to java.
This is setting us up for the actual goal, to collect
mobile stats independently each time the mobile radio
goes down, allowing us to distribute mobile radio usage
across uids based on the number of packets they transferred
during a session.
Change-Id: I21a0f517cf087ea5aa8b8dd535e20b46e361a52b
