This commit removes a couple of apostrophes from the word "UEvents" as
the apostrophes would only be needed if something that belongs to the
UEvent was being talked about. Instead, the UEvents are being talked
about themselves - as a bunch.
Change-Id: I6a7908c6b73c0739102b632d2499e0f1e3c2d47f
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
Bug: 17420540
We need to be able to shutdown some of wearable devices programatically.
We should be able to do it by connecting to PowerManagerService directly,
but it would be nice to go through the official interface.
Change-Id: Id0cf3b36c03447356fc60fb90cbb2f4b47d8265e
--classpath hasn't been properly supported or used for as long as
git history exists, and the non --runtime-init classpath is useless
without it.
Also, forking and exec' a bare dalvikvm instance from the zygote seems
somewhat pointless since we might as well just execute it directly.
Change-Id: Ib07d822d448e7b431d7564381f9cd11735fd1113
The name wasn't chosen without much thought and is intended
to be a temporary fix to keep devices booting while a better
name is decided upon.
bug: 18335678
Change-Id: Ic3451255d870f3395cfbcaa08a7764d93defc350
Introduces new module that provides network-related features for
the StrictMode developer API. The first feature offers to detect
sockets sending data not wrapped inside a layer of SSL/TLS
encryption.
When a developer enables, we ask netd to watch all outgoing traffic
from our UID, and penalize us accordingly if cleartext sockets are
detected. When enabled, netd captures the offending packet and
passes it back to the owning process to aid investigations. When
death penalty is requested, all future traffic on the socket is
blocked, which usually results in a useful stacktrace before the
app is actually killed.
Bug: 18335678
Change-Id: I3adbc974efd8d3766b4b1a23257563bb82d53c29
Issue #18983662: API Reivew: clarify Intent docs for URI_ANDROID_APP_SCHEME
Issue #19019830: Bump up battery stats checkin version
Change-Id: I0bd8f32b9d8d5978bd01d421ea2232d20def340a
Specify which restrictions are not relevant or behave differently
for managed profiles.
Bug: 18768578
Change-Id: Iac1435c5b931cbb889902a9b9e427bc0e0778bf2
...an intent with invalid or null package uri
Also tweak battery stats to record in the history when we shut
down, to understand when restarts are due to clean shutdowns or
crashes.
Change-Id: I6443dafc23e356be9f569906f6081152d4f92d2b
Due to popular demand the methods putBoolean(), getBoolean(),
putBooleanArray() and getBooleanArray() have been added to
PersistableBundle.
Fixes bug 18390436.
Change-Id: Id133ba902aca774f98529e36ce560e873b88ad5b
You can now do "adb shell dumpsys procstats --start-testing" to
enable high frequency pss sampling.
Also improved the low on RAM mem reporting to separate out RAM
from memtrack, in case the data we are getting from that is bad.
And fixed meminfo --oom to work correctly again.
Change-Id: I7af17eab110a82298bd7b0ce381f8fa5c96c1f6a
- Now aggregate number of times each process has crashed and ANRed.
- Now aggregate total number of connectivity changes.
- Now record connectivity changes in the history.
Crash and ANR counts are new entries at the end of "pr" in checkin.
Connectivity change counts is a new entry at the end of "m" in checkin.
Connectivity changes in the history checkin are Ecn and include the
type of connection and its state.
Change-Id: I0c01186446034cf6c3fb97d45f5e3b5c69a0438a
When creating or renaming files on external storage, sanitize the
requested display names to be valid FAT filenames. This also fixes
a handful of directory traversal bugs.
Also relax logic around generating display names to allow any
extension which maps to the requested MIME type. Tests to verify.
Bug: 18512473, 18504132
Change-Id: I89e632019ee145f53d9d9d2050932f8939a756af
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
