Introduce a new concept of "B" services. All running services are
classified as either A or B. B services are later in the LRU list.
Their oom_adj is after the home app. This allows us to better pick
services to kill based on how long they have running, and should
reduce the amount that we end up killing the home app.
This temporarly turns on a debug log when the oom_adj of a process
is changed. Sorry, I know it is noisy. This is needed to try to
track down why some processes are being killed.
Also add a flag to the SyncManager's service binding to allow the
syncing process to be more aggressively killed if it has done UI.
This is to address cases we have seen where sync is causing an 80MB
gmail process to be kept around, preventing other process from running.
Now what will happen is that the syncing process will aggressively be
killed by the system, and can then be restarted in a much lighter-weight
state.
Do a little tweak in the power manager to allow us to still do smooth
brightness changes even when the fancy TV off animation is in use.
And get rid of a debug log in the window manager that was accidentally
left in.
Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
Swiping the home screen causes the WindowManagerService to do
a bunch of work to keep the wallpapers in sync. First, it lays out
and places all windows. Also, it notifies the SystemUI process that
the wallpaper position has changed.
The layout/place operation is too much work - we only need to set
the position values for the wallpaper, not relayout the whole system.
The notification mechanism must exist, but should be optional. Most
wallpapers don't care (especially static ImageWallpapers). So we'll
give them a new API (WallpaperService.Engine.setWantsOffsets()) to
allow wallpapers to opt out of this process and avoid the performance
overhead.
Change-Id: I66c38375438937f14f6f5550565b28eb204b1e06
Getting source-based routing working is too risk for this point
in the project but tethering is broken otherwise, so disable
the tethering option if DUN is required until we can get a real
fix in.
bug:5495862
Change-Id: I5e852bf30c887599024a8b61af86ffec1d5333af
Fix a few places where we would unfreeze the screen too early.
Now that we are no longer relying on surface flinger freezing, we
can't depend on it keeping the screen frozen until surfaces get
drawn.
Change-Id: Icb03bf30c9599a5e2016817bfa5ca6458adc7249
This is especially important when AGPS is disabled
Bug: 5355661
Change-Id: I072dbe1ddf43aa24c8fc39b750040504a1633c53
Signed-off-by: Mike Lockwood <lockwood@android.com>
Now the screen brightness will readjust to ambient lighting when toggling
auto-brightness on and off in Settings or the Power Widget.
Bug: 5486091
Change-Id: Ic98939fe1c59cb8def0f84266e48ca00329d6b30
Signed-off-by: Mike Lockwood <lockwood@android.com>
The correct behavior for the light sensor is to immediately report a value
when it is enabled, so this change should not be necessary.
Bug: 5426212
This reverts commit 5dca30affc517879315b3a928c78756cbc9cf689.
Two issues. A mcc/mnc-driven overlay means that the config at boot may not be
the config we wish to use - the sim card is read later which may switch the
config. Changed to read the configuration each time rather than once at boot.
Second, the secure-setting override was always trumping the resource config
as we weren't discriminating between a not-set default and a real setting.
This meant the config could never make DUN-required.
bug:5495862
Change-Id: Icd4e90ac1d32bbb704c0ff9cc69e954fb0a0b58c
...wallpaper first time IRK81.
We were monitoring for file creates when those are not needed, and
receiving the initial file create was causing us to be confused.
Change-Id: Iccd3b7492c82895dba87f25c4881c538f300d342
If an app takes the 5-second ANR timeout before responding to a
drop, but then recovers, we were inappropriately throwing an
exception back at it for having acknowledged the drop after we'd
abandoned the operation out from under it. Now we let such
responses slide without taking any punitive action: the app is
still okay, and the drag/drop operation was cleanly terminated
already anyway.
Bug 5045618
Change-Id: I0b7e76c61f0f8c97e41280b542a470a7d3c8d86f
This patch fixes the following warning:
W/Binder: The following Binder class should be static or
leaks might occur: com.android.server
.InputMethodManagerService.MethodCallback
...in hope of removing a possible memory leaks.
Bugs: 5481376, 5461066
Change-Id: I1764090a7059d9bf9e5d90683d7ac190c83415de
It is no longer sufficient to check the value of
internal.R.bool.config_showNavigationBar to determine if a
navigation bar (separate from the status bar) is shown on a
device, because the emulator needs to be able to override
this value (now possible by setting qemu.hw.mainkeys to "1"
or "0", for navbar or no navbar, respectively).
This logic is now contained in PhoneWindowManager, and any
clients wishing to know whether the system has a software
nav bar should consult the new hasNavigationBar() method.
Bug: 5404945
Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Make sure to call compositionComplete() after rendering into a FBO.
Bug: 5446982, 5467587, 5466259
Change-Id: I5d8a1b4c327f9973d950cd4f4c0bca7f62825cd4
The basic problem was that at some points during setup wizard, this would
happen:
1. The app's process is killed.
2. The app's process is restarted, but not to actually resume the
setup wizard activity, just to put it in the stopped state.
When doing this, the saved state is cleared but the app will
never provide a new one.
3. The app's process is killed again. At this point, because the
saved state is cleared, the activity is completely removed.
4. Eventually the entire activity stack becomes empty, and a new
setup wizard activity needs to be created as the home app.
There is a combination of bad stuff going on here.
First, why is the process being killed? At this point the setup
wizard is the home app, so it shouldn't be killed. There were two
reasons why this was happening:
- CryptKeeper still was not completely cleanly going away. To fix
this, I removed the check in the activity manager to not allow
an activity to finish if it is the only activity on the stack and
maybe-kindof looks like the home app. This really wasn't necessary
(we always take care of starting a new home activity if we find the
stack is empty), and outright dangerous with all of these things
purporting to be home but not.
- There was an issue in computing the oom_adj where the home app
would not be marked as "not hidden", and if we had to re-compute
its oom adj in the current sequence would then give it an
adjustment as a background process... and with all the processes
we spin through during boot, it quickly got down to background
#16 and killed.
Second, what is going on with the state? This is easier, the code
in the activity manager to create a new activity but put it in the
stopped state was still clearing the saved state. The saved state
should only be cleared when going in to the resumed state. When
going in to the stopped state, we can just keep holding the same
saved state.
Change-Id: I7d21cdcfa082d98ca70c79d9923e29605ee4353e
