base: properly check that quickboot is enabled

Change-Id: I0c9e54ee2cdf4efb5097cd101a0fa274f493d816
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
base: don't show global actions if shutdown sequence was started

Change-Id: Icd77aa7529faf438dcc80e45434826465a11aab8
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
accounts: don't remove accounts while device is in safe mode

Userspace apps are not available in safe mode, so authenticators are not available when
the system starts and checks all accounts. Just ignore these accounts and not add them
to the list of accounts.

JIRA: CYAN-4074
Issue: https://jira.cyanogenmod.org/browse/CYAN-4074
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
Change-Id: I9cac5084c29fe33a0215ab4a9e693f58712438ac
Themes: Theme immersive mode cling.

Change-Id: I5521b93f69e859c40cfd62eb4a367562200074e9
Fix the bug in replacing a fragment with itself.

Summary:

We are facing a bug that some fragments in our app got removed
randomly. We debugged the app and it seems there is a bug in
the fragment API.

When we we are trying to replace a fragment with itself. We will
try to make the operation a null op, then both `op.fragment` and
`f` will be reset to null.

  op.fragment = f = null;

But since it's inside a loop, if the list `mAdded` still have
items to be visited, the code will continue to the next
iteration. Then it will compare the fragment with null, and
reach the line:

  mManager.removeFragment(old, mTransition, mTransitionStyle);

Eventually it will delete all left fragments in the list `mAdded`.

This diff adds a break to abort the searching after we null
the operation.

Test Plan:

1) Tested with our app. No fragment is randomly removed.

Revert Plan:

Change-Id: I5dc2c07a1bb1d1da1b0fd4e5610d970d55a81e86
Tags:
Signed-off-by: Kang Zhang <kangzhang.cn@gmail.com>
Merge remote-tracking branch 'upstream/android-4.4' into android-4.4

Solved conflicts:
	core/java/android/view/WindowManagerPolicy.java
	services/java/com/android/server/wm/WindowManagerService.java