Add policy controls to NetworkStateTracker which are combined with
other user preference and internal flags to decide if data connection
should be established. Better locking around enabled flags.
When data network would be over limit, proactively disable data on
that network. Enable when policy is snoozed or when cycle resets.
Track and dismiss notifications from now-stale policies.
Bug: 4587023, 5178147
Change-Id: Ibfcc9f73cda7c369209af701b46eddd3d1943f2d
The new specification calls for LED to continue blinking until the user
pulls down the notification shade in the status bar.
Bug: 5143247
Change-Id: Id004cc3d1d9d76108329e57c6fbd8a8100068e0a
Signed-off-by: Mike Lockwood <lockwood@android.com>
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
This introduces a new facility for code during the boot process
to display messages to the user through a progress dialog. This
is only for use when performing longer-than-usual post-upgrade
operations such as running dexopt on applications or upgrading
databases.
Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
This fixes a crash caused by permission problems when we try to update
the password history and discover there's no password salt. The code
attempts to create the salt, which triggers the exception.
This could be fixed by wrapping the call with a clearCallingIdentity()/
restoreCallingIdentity(ident). However, while looking at it, it occurred to me
that this can cause unexpected failures if the DPM tries to set the
password twice or happens to set it to something in the password history.
Instead, we should *always* allow the DPM to reset the password to whatever it wants,
provided it passes the minimum password criteria.
Change-Id: I1505b24f9c097ee5c2c44e4bf378ba90095b113b
Using the same convention in system_init.cpp, you can disable these
services by setting system properties:
system_init.startaudioservice=0
system_init.startmountservice=0
Change-Id: Ie6c0225bf6e204b0b5e3280b29c7d493d08b8a5c
Signed-off-by: Mike Lockwood <lockwood@android.com>
cryptfs has long-running operations that cause the Watchdog to fire
reliably when encrypting the filesystem. Disable Watchdog on
MountService for this reason.
Change-Id: Id03f5f60c704dcd74a8696ad9f32b5fba5381731
When restricting background data, show ongoing notification to give
easy access to re-enable. Deprecate getBackgroundDataSetting() API
to always return true, since NetworkInfo.isConnected() is new source
of truth. Handle upgrade path by reading from existing secure value,
and kick one last broadcast when changing value. Remove background
data code from ConnectivityService.
Remove warning alerts, since they push ifaces into restricted list;
should only happen when iface has limit.
Bug: 5163559, 5129421
Change-Id: I0064d9d643656a4d32aaae51d4a58bce49fe295f
There turn out to be two distinct bugs leading to runtime restarts.
The first, dating from at least Android 3.1, is that following certain kinds
of app crashes we properly clean up the drag-state bookkeeping, but aren't
prepared in the case of the drag-target timeout clock firing with a now-
null drag state in effect. We now catch that edge condition and don't NPE
(and note that there was already similar code around the separate timeout
when an app is *starting* the drag process).
The second bug is that some new-in-ICS code in the input channel management
wasn't prepared for certain cases where the current touch window could have
become unusable and its input channel torn down summarily in the case of the
aforesaid app crash during drag. The code now makes sure that there really
is an input channel that needs to be flushed / cancelled prior to attempting
that operation.
Fixes bug 5173534
Change-Id: Idaae158ecfb4b93456ab1425769b669962893c00
to avoid ID collisions with other system services.
Bug: 5161005
Change-Id: I069fbc40a8764bc85cceeacd04264abd32b62668
Signed-off-by: Mike Lockwood <lockwood@android.com>
