Currently test harnesses depends on this flag to determine when
the system is fully booted, and start dismissing keyguard, launch
tests etc. However, the flag is usually set when the boot animation
is still running, and typically about 5 seconds before keyguard is
up etc. Moving to to when BOOT_COMPLETE broadcast is sent makes it
work more reliable.
We also discussed about using sys.boot_completed instead,
unfortunately this flag is not in all platform and we still have
backwards compatibility to maintain in order to drive unbundled
tests.
Change-Id: I99b084cd70d8e4bcfe490ddeca868136d32712e2
Report non-monotonic NetworkStats through an observer interface
instead of throwing, since those events are still recoverable.
Change-Id: Ic0749f4634b0ac05dbe90e95ca490957ec8b2f23
Fix 5783857: Device Policy Manager doesn't allow Face Unlock
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
Ensure that all requests to read the list of installed packages
go through the PackageManager directly. Don't allow non-system
program to directly read the raw package list files.
Change-Id: Id083e6b3de4dd9173abfdc741ebf3f60997a1052
- Add wimax related code in handleSetMobileData to disable wimax when Moblie data is disabled (Settings -> Wireless & Networks - More -> Mobile Networks ->Data Enabled)
Change-Id: Ibf2d9da2eb90d161128005f26ac4b3e991526af4
Signed-off-by: tk.mun <tk.mun@samsung.com>
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
This was broken in commit dd519fac9b79f36a27909149a90fce4321ed1c20
(certainly by mistake), in which Integer.parseInt(tokens[1]) was
errornously replaced with event.getCode().
Change-Id: Ic5af5a2ec5f321da21a4a5db25f6908462f6cae8
The idea is that this is a device which is more-or-less headless. It
might have some limited interaction capabilities, but it's not something
that you want to rely on having.
Change-Id: Ib92f53a120bf83de781728011721a4859def7d9f
This separates the definition of "metered network" and "network with
limit." For now, all mobile networks are considered metered.
Bug: 5571454
Change-Id: I394cd385bd33add75e53bfc9cf2fefd06a00208a
This is similar to the existing dump() facility for services.
ContentProviders can now implement dump() and that info will be shown
when running "dumpsys activity provider" and when taking a bugreport.
Change-Id: I33b3b132e3c4f920153355cc368eda2f725a715f
-------------------------------------------------------
MCC detection fixes for CountryDetector
- Don't get and cache phone tpe at the initialization time. At this point
TelephonyManager is probably not ready yet.
- Refresh MCC whenever we get the service state changed callback, even when
the state hasn't actually changed, in order to make sure we get refresh
country properly when MCC changes.
- Also remove the initialization of mPhoneStateListener, which prevented us from
registering phone state listener properly.
- Also fix tests which were already failing.
Bug 5670680
-------------------------------------------------------
Add logging to country detector logic
This is for debugging purposes to verify the effects of
change Id45abeba1b1e843053ac2c946861b439ca568de4.
Bug: 5670680
Change-Id: I238d953484e2c8135f7dac70fce8662c8300a286
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
This is for debugging purposes to verify the effects of
change Id45abeba1b1e843053ac2c946861b439ca568de4.
Bug: 5670680
Change-Id: Ia065dec6ba651e7e77205f812b7606b15eebdc17
- Add delayed disk write in WifiConfigStore
- Remove synchronization and keep all access to config store
throught the state machine thread
Change-Id: I53768a17895e48da7b99542ac95c6c2fddbcb021
- Don't get and cache phone tpe at the initialization time. At this point
TelephonyManager is probably not ready yet.
- Refresh MCC whenever we get the service state changed callback, even when
the state hasn't actually changed, in order to make sure we get refresh
country properly when MCC changes.
- Also remove the initialization of mPhoneStateListener, which prevented us from
registering phone state listener properly.
- Also fix tests which were already failing.
Bug 5670680
Change-Id: Id45abeba1b1e843053ac2c946861b439ca568de4
This fixes a complaint from carriers (that we used 8.8.8.8), but also
fixes the case where there is only room for one live radio
connection: the secondary connection (tethering) doesn't have a
default route to prevent on-device traffic from slipping out on the
tethering connection, but tethered dns is proxied through dnsmasq, so
it is appearing as on-device traffic and is unroutable. By switching
to the carrier-indicated dns servers we can use the host-routes
already set for those and kill two bugs with one fix.
bug:5525764
bug:3045311
Change-Id: Ib1ccea81e0c0ed2d1462dc9721c2647124a790da
