base: added national roaming info for Simyo in Spain

Users of Simyo in Spain (MCC214 MNC09 and MCC214 MNC19) can roam on Orange (MCC214 MNC03).
Change-Id: Ic821078314ebd36323a804f00036ccb89dffbf66
Fix visibility of multiple non-fullscreen activities.

Issue detail:
Assume X, Y are non-fullscreen activities.
 a.Home starts an activity X in task A in application stack.
 b.X starts an activity Y in <task A> or <new task B>
 c.Activity X will be invisible.

How to fix:
Because the function "isActivityOverHome" means an activity is able to see home.
But there may have many non-fullscreen activities between the top non-fullscreen activity and home.
If flag "behindFullscreen" is set, those middle activities will be invisible.
So it should only take care from who is adjacent to home.
Then check two flags frontOfTask(task root) and mOnTopOfHome for constraining the condition.

Change-Id: I60bcea304976414e44835a0a38675aae365e9e19
Missing break in switch statement

Change-Id: I462c0c5fec96a850032266b04419ec409ad02174
Fixed incorrect calculation of dirty invalidation area

Padding was already taken into consideration before calling
invalidateDrawable in ProgressBar.

Change-Id: I75f25b0b7ee87d394422c58888ed3a1cca5d06a8
ProcessList: use different polling interval when screen off

We are using the same time interval for both screen off and screen on.
For process on top: ActivityManager.PROCESS_STATE_TOP, we will poll PSS
information every 120 sec.
During polling PSS, we are grep /proc/%d/smaps which is a 10k lines file.
This cost quite a lot of CPU resource. But when screen off, we don't need to update
TOP process PSS so frequently since we are not operating it. Lower polling
circle to every 15min to reduce power.

Change-Id: Ia4cd26290d44d066f034d5270ce5523650a3c493
aapt: Support for mxmf file playback

mxmf files couldn't be played.
Added .mxmf file ext to kNoCompressExt array
CRs-Fixed: 465437

Change-Id: I4473380c0aa13f7c18b59aa48f07a87f7849a74c
Follow on seekbars new UI guideline for 4.4

google forgot some things.....seekbar is one example

Change-Id: I996062a978322c93694e360dff1e4f42dc589062
fb: correct seeker fb style for 4.4

based on this commit https://github.com/SlimRoms/frameworks_base/commit/a845169c128c19825a69a0ebdf2e4d366fdd67ad

the idea was good but bad done. A middle in the night action lol.
Problem is that holo light themed app cannot handle the white seekbar of course
So add the complete seekbar into the Holo.Light switch to support both cases

Holo: white seekbar
Holo.Light: drak gray seekbar

Change-Id: I82252d0cb30cd4af47d624a37ccc904cb7e9c1e6
fb: global menu follow new 4.4 UI

the sound indicator is still ICS blue...change it to white
In general we should consider to change all tab_selected
files into a Holo.Light switch due it is already defined in styles.xml

but thats work for our themer :p

Change-Id: I02b5331e223319517c5536522cd6bc419745ce3f
Update missing google UI changes for 4.4

thanks to kroz other things are now as well consistent to the new
google UI style

Change-Id: I604d29293b04bbcf279efd4d5bf2970ff8ee0c75

Conflicts:

	core/res/res/drawable-hdpi/switch_thumb_activated_holo_dark.9.png
	core/res/res/drawable-mdpi/switch_thumb_activated_holo_dark.9.png
	core/res/res/drawable-xhdpi/switch_thumb_activated_holo_dark.9.png
	core/res/res/drawable-xxhdpi/switch_thumb_activated_holo_dark.9.png
fb: changed all open forgoten UI from google into new UI

thanks kroz

Change-Id: Ibc32ad8e73617dd74c8cd313dc2e071962eec966
fb: change alert dialog to new 4.4 UI guidelines and add

Holo / Holo.Light switch to reflect it proper on the
different app styles

Change-Id: I0fb7cd06d19a8eef66551e9f0281d60f33b2efe6
core: added national roaming info for Spring Mobil in Sweden...

Spring Mobil users in Sweden (MCC 240, MNC 10)
can roam on Sweden 3G (MNC 05) and on Sweden 2G (MNC 24).

Change-Id: Ie27ad3561de32557a1713d4962fcc9ec52a8b7fe
Revert "power: Add CPU boosting interface"

This reverts commit 3ca9458aeecffc5e029656bb03ccf27a90cd6a53.
Keyguard: do not allow to delete the system widget if widgets are disabled

We overwrite the default widget with our own one. In this case it is detected
as a normal widget even though it widgets are disabled and starts listening to
longpress events

Whatever check if widgets are disabled. If this is the case do not allow any
longpress events

Change-Id: I471664bac6ca1f8e57efe4904a385904c40486db
Keyguard: fix not shown overlay widgets from system

google derp....due that if widgets are disabled current AOSP
code just add the default widget. Then checkAppWidgetConsistency()
detects a widget which was added and the complete method is non op.
Whatever lets handle the whole process over checkAppWidgetConsistency()
on widget disabled it tries to bind the default widget over overlay if
this is without sucess it falls back to the system one.
Safemode falls always to the system one

This fixes as well an issue that the saved default id in LockPatternUtils
is not reseted back to default if all widgets were deleted from the user.
Based on an old patch from Danesh. Thanks for the suggestion

Change-Id: I6b21d18346fed5accc72141097939c92ee9aaa3c
Keyguard: let the user drag the challenge down if widgets are disabled

for the system clock widget this does not make much sense
but since our system default is cLock it makes sense to
allow it to see more content.

Change-Id: I0365573c6fa88117a47b01ced81eb36f75324342
FLAG_PRIVILEGED disappears if privileged app is updated and rebooted

Since Kitkat, an app pre-loaded under /system/priv-app/ has
FLAG_PRIVILEGED. However, if the app updated and the device
rebooted, privileged flag is unset from pkgFlags. This patch
fix issue to assign privileged flag when scanning the updated
packages.

Bug: 12640283

Change-Id: Ic24b5882f65dabdfae9cc39da3d68661bed4fc31
Set Settings.Global.WIFI_SCAN_ALWAYS_AVAILABLE default value

To be able to customize the "WiFi scan always available"
setting we need to set a default value.

Change-Id: I3673f2613ab9b6a947aed7e29d4cc876140c2180

Conflicts:

	packages/SettingsProvider/res/values/defaults.xml
Only send storage intents after boot complete

It is not possible to send a broadcast before the system
boot is completed. If you do it anyway you will get an
IllegalStateException: Cannot broadcast before boot completed.

If a memory card is inserted or removed while the phone is
booting up, there is a risk that the MountService will try to
broadcast a storage intent too early, and cause the device
to crash.

Use FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT to avoid
problems with too early broadcasts.

Change-Id: Ied36a13d235df37c9788e45a35de40d919ae0cd0