This can be used to move a surface offscreen to avoid the cost of compositing it.
This preserves the window and therefore the OpenGL context when used in h/w
accelerated apps.
Change-Id: I280295376601b17989d0fc8a271af66650016f09
On branch fix_sdk
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: core/java/android/app/KeyguardManager.java
Change-Id: I56848db098822536f0ac32efc8f0eb1d725bf6f9
This fix disables KeyguardManager's enable/disable API when any
device policy admin requests a policy that enforces a password.
Change-Id: Idb1da16b14ed8963142f7b1f62d2b060d84ffa65
The preboot upgrade handling was bringing up the acore process with a default
application object, then the normal "start the HOME app" code was bringing up
Launcher2 [hosted in acore] in anticipation of boot completion... but then it
saw that the host process was alive and continued with Launcher2's init.
Launcher2 depends on a custom application object, however, so it crashed
immediately.
This change ensures that the HOME app is not actually initted at that level
until after boot has completed, at which point its proper application class
can be instantiated.
Fixes bug #2732250
Change-Id: I1a15384e2c0d50e14300df0c0db236bd7b1a187c
The kernel threads are appended to the usual /data/anr/traces.txt file
and dropboxed along with the usual Dalvik stack dumps.
Change-Id: I120f1f5ee54c965efe9ac0c7f40fdef56385f1fa
NOTE: this change depends on the kernel publishing /proc/$PID/stack
Rather than come out of the user-modifiable APN DB, the DUN APN data will
come first from a built-in resource and then potentially overriden by a secure
setting (which is gservices upgradable).
Also made the "require-dun" setting secure-setting overridable.
bug:2736390
Change-Id: I1e4644c3839f06c977b83797641f3948785146a2
This gives us a snapshot of what the system process was doing after 30 seconds
of apparent inactivity as well as after 1 minute, to help distinguishing actual
deadlocks from too-slow progress, livelock, etc.
Change-Id: I19758861d1b25f298e88788e8f1c7ec7bf828823
The Javadoc had a missing close <code> tag and also failed to mention
the "start" parameter in the doc.
Change-Id: I861d6646e82e1d49f23a09de8b68a61f81689f83
They're designed to handle one time upgrade code, which may
take a significant amount of time. Third party code cannot
receive this broadcast so the timing should be able to be
kept under control.
Bug: 2713849
Change-Id: I3733b6530198bebd9b8c2ba6f9f27a7999336b8d
