On binder incalls, the handler thread is given the caller's priority by the
driver, but not the caller's cgroup. We have explicit code that sets the
handler's cgroup to match the caller's, *except* that the system process
explicitly disables this behavior. This led to a siuation in which we were
running binder incalls to the system process at nice=10 but cgroup=fg.
That's fine as far as it goes, except that if a GC happened in the handler
thread, it would be promoted to foreground priority and cgroup both, to avoid
having the GC take forever. Then, when GC finished, the original priority
is reset, and the cgroup set *based on that priority*. This would push the
handler thread into nice=10 cgroup=bg_non_interactive -- which matches the
caller, but is supposed to be impossible in the system process.
The end result of this was that we could be running "lengthy" operations in
the system process in the background. Unfortunately, some of the operations
that wound up like this would hold important global system locks for up to
twenty seconds as a result, making the entire device unresponsive to input
for that period.
This CL fixes the binder incall setup to ensure that within the system process,
a binder incall is always begun from the normal foreground priority as well
as cgroup. In practice now the device still becomes laggy/sluggish when the
offending lock-holding time-consuming incall occurs, but since it still runs
as a foreground task it is able to proceed to completion within a short time
rather than taking 20 seconds.
Fixes bug #2403717
Change-Id: Id046aeabd0e80c48eef94accc37842835eab308d
When the surface view scrolls off the screen it stops drawing, so
we stop moving it. Add an observer to scrolls so we can continue
to update its position.
Change-Id: I2604cbbecd3e72be1a2a6bc5794e3e1c19317b9e
AlertDialog's docs now refer to the id android.R.id.custom, the
correct method addView, and android.R.id.custom has been exported as a
public id.
Change-Id: Ide43a03b702f0b36326130909f9a864872ec93fb
For the UTF8/UTF16 switch code, we needed to know what was the
minSdkVersion specified as early as possible. Unfortunately, this threw
warnings when the SDK was compiling since we always set this field in
the Bundle.
This splits out the field used by the initial AndroidManifest.xml scan
to a separate one that we won't attempt to re-insert into the
AndroidManifest.xml This also switches the logic to better reflect the
preference of UTF-8 over UTF-16; previously UTF-16 was the default.
Change-Id: Ia81f6b21047043ebb711eb24c2c3718534979ef6
We now return the initial configuration for a window when it is
added to the window manager. The view hierarchy would check to
see if it was different than the last one, and not dispatch a
configuration change down itself if not. However, when
ActivityThread received it, it would always dispatch a config
change even if it is the same.
The solution is to only do this in ActivityThread if the config
is actually different; otherwise, we continue to rely only on
the activity manager explicitly telling us when to do a config
change.
Change-Id: I8a6e3565776dd2723c8b791496bb6041463d4b67
