The msg is now constructed to try to bin these reports in
interesting ways. We'll see. Also change the tag name from
watchdog to lowmem, since sharkey is kindly taking care of
the back-end to handle this.
Improve how we put processes into low memory states to better
poke things like home and the previous app.
Also clean up some debug output, and add a few new am comment
options for controlling the current debug app.
Change-Id: I562a931a95244a2727bb7a6e1fd80dec259cdae2
- getting rid of blue glow (5529032)
- moving app icon position
- show message if there are no recent apps (5533332)
- fixing rare IllegalStateException on orientation change (5584344)
Change-Id: I2210e584957869c8f02339e6841daf39364a9dad
Instead of trusting NTP time alone, use the most-conservative of
system clock and NTP.
Bug: 5584564
Change-Id: I5dd87fc009959b1cf0a7d660e385a0b1a8be238b
...the "Complete action using" dialog
I have never been able to reproduce this consistently, but here is
another stab in the twilight. It looks like during boot we have
a potential race where we could reset the config sequence number after
we had gone through a config change, causing ActivityThread to ignore
a following config change. Maybe this change will help.
Change-Id: I4b731df5fd5c63894ca2e9bd34693b31ab1c0565
This came up from bug #5601885: Memory increase (leak?) in system_server
Stingray MR1
This isn't *really* a leak in the system process -- it is a leak in an
application process that is causing the system process to keep around
a bunch of ActivityRecord objects longer than it should, until that app
process is ultimately killed.
Unfortunately these days leaking an ActivityRecord also often means
leaking a thumbnail, which is a big slab of memory.
So make the activity manager better about this, using a weak reference
from the handle the object has so we can still clean away most of the
state associated with the ActivityRecord even if the client side leaks
its own reference.
Change-Id: Idbab45e09749cdfb54899203da7981e7b3576e25
If it's configured with a defined network but can't create a network state tracker
for it, it would NPE and restart the framework whenever a default network
disconnects.
bug:5603268
Change-Id: I816c4f522d766e0353a713623f6635b03395b01e
* commit 'cb0db0306b5849a35d3d99eea1b34ce019c6f0d8':
Make the overridden ImageView#setVisibility remotable
Clamp non-monotonic stats instead of dropping.
DO NOT MERGE. Fix leak in LayoutTransition
Fix lastVisible/global rects
Fix Wimax-less build.
Fix leak in LayoutTransition
Deferring wallpaper update to improve workspace scrolling (issue 5506959)
Terminate EGL when an app goes in the background
boot animation is dithered and scaled
Fix NdefRecord byte-stream constructor.
PopupWindow dismiss() can get into a recursive loop.
Fold WiMAX state into the mobile RSSI.
Remove dedicated wimax icon to fix RSSI layout.
When encountering non-monotonic stats rows, recover remaining data by
clamping to 0. In particular, this avoids edge-case where persisting
threshold checks would never trigger. Also recover when tethering
snapshots are missing.
Bug: 5600785, 5433871, 5600678
Change-Id: I1871954ce3955cc4ac8846f9841bae0066176ffe
A build with the wimax network type defined but wimax disabled
causes an NPE in ConnectivityService's constructor.
bug:5237167
Change-Id: I929eac217e1afa0e61346fdbc3e96a7d3ad09a54
...should not be restarted when rotating screen on xoom
This was a side-effect of a previous fix to compute the screen layout
config class based on the actual space available to the application, not
the raw display size. On a device like Xoom, the system bar causes us
to switch between LONG and NOTLONG depending on whether the system bar
is on the short or long side of the screen.
To fix this, we now compute the screen layout class the same way
"smallest width" is computed: looking at all of the possible rotations
and using the smallest of them all. In addition to preventing the device
from toggling between long and notlong on a Xoom-like screen, this will
also avoid other possible undersireable behavior like changing screen
layout size when rotating.
This does mean that Xoom is no longer considered a long screen even when
in landscape, because it is not a long screen in portrait.
Change-Id: I85f90a16294ef5a7de94d5b9231abbc6f914fe90
Previously, the input dispatch rate was capped by default to 55.
This worked fine for systems with a refresh rate of 55 or lower. But on
devices with a higher frame rate (such as stingray at 60 fps), we do not
receive events as fast as the rendering system wants to redraw the frames, so
we would occasionally miss events between frames, resulting in a visual
stutter during drag operations where the dragged object would essentially
stay still for a frame.
This fix increases the default rate to 90, or 1.5 times the highest typical
refresh rate of our devices.
Change-Id: Id8622185b3da93f9f6505157d2e6f3f33e36bd04
