This is needed since its no longer copied to /data/dontpanic by init.
Change-Id: I5217da73ec470653824b7fb9a31e093e263a8dc9
Signed-off-by: Dima Zavin <dima@android.com>
* changes:
Rename WebChromeClient.addMessageToConsole to WebChromeClient.onConsoleMessage. Do not merge.
Update JavaDoc for CacheManger.CacheResult, WebChromeClient.getDefaultVideoPoster and WebChromeClient.getVideoLoadingProgressView. Do not merge.
Improves documentation for GeolocationPermissions class. Do not merge.
In this case, as opposed to what was happening in 1977685, the focused view wasn't the one that was
directly removed, it was a child of the removed view.
...Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
The problem was that we weren't dealing well with the situation where we start a transition
from activity A to B, then transition back to A before B is shown (it finishes before being
shown), then transition from A to C. At this point we had some state showing that we
were in the process of showing A from it being hidden (due to the middle transition from
B to A), which would cause the layout pass to ensure its window is hidden before the
transition starts.
The solution is to detect the case where we are showing a token and it is already actually
shown, and in this case not do all of the token setup for it to wait for its windows to
be displayed before it is shown. This isn't needed, the windows are already displayed
or the token is already set up to wait for them to be displayed.
Change-Id: I16925b91e1e2449dd65ade162a5758173c6e2695
Also sets an explicit type for GeolocationPermissions.getOrigins.
This is a partial fix for bug http://b/issue?id=2271636
This has already been submitted to eclair-mr2.
Change-Id: I0c77eca94eb56d16c2a9a29a72eb221e4a7a52a6
This patch modifies the native binder interface to the metadata
retriever to pass the caller's thread group across the binder
interface. On the server side, the thread scheduler group is
set to the caller's scheduler group temporarily and restored
after the request has completed. This patch also reverts a
previous patch where the priority of the thread was forced to
a low priority foreground thread.
This should give apps more control over the priority of their
metadata retrieval, particularly allow background process to
run without hogging the CPU.
Merge commit '5e7f1fbe161d7015dde6e893351238749f906c8a' into eclair
* commit '5e7f1fbe161d7015dde6e893351238749f906c8a':
droiddoc change: add flag to offline docs build to signal
* changes:
droiddoc change: add flag to offline docs build to signal that we're building offline docs so that we do not generate all of the web pages for the sample apps source code.
If reenableKeyguard() is called before the previous disableKeyguard() call is processed,
then TokenWatcher.sendNotificationLocked() will cancel the request, resulting in neither
the TokenWatcher acquired() or released() methods being called.
In that case, reenableKeyguard() will hang waiting for released() to set
mWaitingUntilKeyguardReenabled to false. Now we only wait in reenableKeyguard()
if the TokenWatcher acquired() method is called and the keyguard has actually been disabled.
This should fix bug b/2270192
Change-Id: Id886fb28df607dbb4543124f2db6997121d6a682
Signed-off-by: Mike Lockwood <lockwood@android.com>
This change applies the fix -- originally by phanna in
https://android-git.corp.google.com/g/#change,33669 -- to
the com.android.internal.widget version of DigitalClock,
which is used by the keyguard and pattern lock screens.
Change-Id: I43f72dd144423e55f73ba52903d52163c8f65591
