This feature can be enabled in carrier config XML. When enabled, the user will not see
ETWS/CMAS enable/disable option in emergency broadcast preference menu.
bug: 22396039
Change-Id: I6ad6fa39852d3b13faeef968a1963b3e0a4a6e61
This causes various problems with our testing infrastructure.
This reverts commit b210026e3d5c955628ca8b8b9191ade08891e9ef.
Bug: 22447614
Bug: 21429947
Change-Id: I57623e3d993e65b6ad89e7a7d28e9575cf638994
With lots of usage stats files, the log gets spammy
when the time changes and we are moving files around.
Bug:22549399
Change-Id: I9da39399b090066d52568dea6fc5b59aba063c5a
There was a mistake in the code that was supposed to recover from the
initial time on a new device being bad until the real time ultimately
gets set, which was causing us to update the start clock time every time
there was a time change (instead of just when the original start time
appears bad).
Rework all of this, so we now count the start time as bad if it is more
than one year before the current time, only modifying it in that case.
Also when modifying it, adjust the time we set it to take in to account
how much realtime has actually elapsed so far in the battery stats.
Change-Id: If74bd711d9b7618c8f6148a9935c452aaaa7e257
We weren't correctly handling the root view of the window --
we were just pushing it on to the stack, but that means it got
written at the end. Instead, we now immediately write it
after the window and let things follow from there.
Change-Id: I070c96bd2443f312a7c6f495d1bf72fa19c614d6
Delay updating the user switcher until the
switch is complete, so we aren't showing
an intermediate state while the screen is
frozen.
Also pokes the UserInfoController to update
the user avatar while the screen is still frozen
so it is ready by thawing time.
Bug: 22557684
Change-Id: I020b8c1ad42c03ab9162ed384ecfe54ed12f998d
Not sure how useful this is, since renames should be atomic. If the filesystem
is corrupt I'm sure other parts of the system will break. Good to be safe though!
Bug:22172659
Change-Id: Iad339be2869d170bcf736c59feb93830a51905e1
When querying for ringtones, only look for ringtones on external
storage when the caller has READ_EXTERNAL_STORAGE.
Document this behavior in the javadoc of the affected methods.
Bug 22545684
Change-Id: Iae9c9a4ccaf635da8af2ac289b6b4df1b16c5d11
Don't check for external storage access rights from MountService
for system server. Otherwise there's a case where AppOpsService
is locked and PackageManagerService calls into AppOps with its
own lock held and is unable to do an AppOps check via this path.
Bug: 22522725
Change-Id: Ib4cf914638905de391384aa5122e691c5a7140ec
Bug: 22558805
Change a039182d6157bc0487df4ad8e373685c9dd7d662 reduced
the size of an entry from 4 fields to 3, but failed to
update the constant that determined the size of the java long[].
Because the long[] is blindly passed down through to native, this
will result in reading past the end of the array as the size
is no longer a multiple of the number of fields being read so
the loop will not terminate until 1 iteration past the end.
Change-Id: I2f8e26cec9a60b3a74739a3763203296be5f1fd6
As discussed in b/21429947 (commit
674019065bceb4150190bfb1aa63cda9de0a8560), MTP must always be
enabled, even if access to the underlying MTP data is disabled.
Otherwise, Android will not enumerate on the USB bus, and won't
receive notifications from the kernel about USB state changes. This
effectively prevents using MTP functionality on user builds, or
on userdebug/eng builds with adb turned off.
Always ensure that MTP is the default driver mode.
Get rid of one use of the persistent property. The persistent property
was already pulled from a number of devices, and as explained in
commit fcf10f7c12cb3107bdfedce6f76a8c866d154f3c, the intent was that
the persistent property would only hold the persistent adb state.
Bug: 22447614
Bug: 21429947
Change-Id: I8b3690a1bafb7cea0d5a69d73c1065c7fc64c653
