1. Change calls to java.lang.System.log* since they don't exist on the
host.
2. Clean up method rewrite mechanism in ReplaceMethodCallsAdapter.
3. Stub out creation of uninitialized GregorianCalendar.
4. Memory map the time zone data base file and provide a custom
implementation of BufferIterator for use by ZoneInfoDB
5. Delete unused Time_Delegate
Also fixed a comment in BridgeAssetManager and an error message in
FontFamily_Delegate.
Bug: http://b.android.com/79160
Change-Id: Iae5ef65678f0e6c7c5af520c45bd15980ce3fa55
The current heuristics depend on devices being alive at midnight+ in
order to run periodic background fstrim operations. This unfortunately
means that people who routinely turn their devices off overnight wind
up with their devices *never* running fstrim, and this causes major
performance and disk-life problems.
We now backstop this very-friendly schedule with an increasingly
aggressive one. If the device goes a defined time without a background
fstrim, we then force the fstrim at the next reboot. Once the
device hits the midnight+ idle fstrim request time, then we already
aggressively attempt to fstrim at the first available moment
thereafter, even if it's days/weeks later without a reboot.
'Available' here means charging + device idle. If the device never
becomes idle then we can't do much without rendering an in-use device
inoperable for some number of minutes -- but we have no evidence of
devices ever failing to run fstrim due to this usage pattern.
A new Settings.Global element (type 'long', called
"fstrim_mandatory_interval") is the source of the backstop time. If
this element is zero or negative, no mandatory boot-time fstrim will
ever be performed. If the element is not supplied on a given device,
the default backstop is 3 days.
Adds a new string to display in the upgrading dialog when doing
the fstrim. Note it is too late for this to be localized, but since
this operation can take a long time it is probably better to have
it show *something* even if not localized, rather than just sit there.
Bug 18486922
Change-Id: I5b265ca0a65570fb8931251aa1ac37b530635a2c
This change is to start Mountservice before starting
performBootDexOpt, as in one case, in performBootDexOpt
when system upgrade happens, StorageManager will be started to
get the low threshold of DataDir. But, at this point, as
Mountservice is still not up, StorageManager will end up
having a null object of Mountservice.
Change-Id: If2b5e1b58e7d2a72c6313f196e98a68738295ec6
* commit '77283ec981fc022cd26ced1e44ad21cdc0b2e4ae':
Fixed NullPointerException due to null Bundle, changed time interval from ms to seconds as per method documentation
* commit 'fd117ff2a4a8edd570ccaedd0cd769613ad4ef74':
Doc change: zh-cn translation of Android L overviews. cherrypick from I56d1ce58e10b83d10d0077cc9dfbeb04f090b861
- Chinese pages are showing Japanese (not good)
- Chinese resource page is not rendering because of bad video links
Change-Id: Ia4508c2db85b9cbd5bdad34ae8bedc411df98360
ProxyInfo.getPacFileUrl() can not be null. It will be equal to
Uri.EMPTY. Checking for null was causing global proxies to never be
disabled. Or more accurately, global proxies would be disabled, but
would reappear after a reboot.
ProxyInfo.getExclusionListByString() can be null. If no
exclusion list was specified, the proxy settings would not be
successfully saved, they would disappear after reboot.
Bug: 18453223
Change-Id: I1c27e5dca5b9664bb7468ea909bff489fa110a07
The "one" case should always include %d. Say so, and fix our examples.
Also make it clear that developers should always provide exactly "one"
and "other".
Bug: 18429565
(cherry picked from commit 1fe7d496db1ddc73289e6aae11f4dd4a970141d5)
Change-Id: I89656c74b7dfd91584e1bb6d0a3f2da1dda81079
Fixeds the gradle dependency line. Also added in Javadoc links for the
various support classes and methods, and other minor cleanup. See
first comment for doc stage location.
bug: 18439090
Change-Id: I7ccc892f38a644d68abc6d56d8d4377df5f864b0
If the restriction UserManager.DISALLOW_DEBUGGING_FEATURES is enforced,
then any attempt to set ADB_ENABLED will result in a SecurityException.
This can result in the device not being able to boot.
Bug: 18433477
Change-Id: I21e4b406ad0fa89b7d4b678eac1baf212a3c7acd
