Fixed stylus eraser being rejected by palm rejection

The stylus eraser appeared not to work, i.e. Android did not respond to
input from the eraser. It turned out that all input except stylus input
is rejected when palm rejection is activated. The problem was that the
eraser itself activates palm rejection when it hovers. The solution is
to allow the eraser during palm rejection. This solution makes sense
because the eraser input works in the exact same way as normal stylus
input.

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

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

Change-Id: I75f25b0b7ee87d394422c58888ed3a1cca5d06a8
Fix to NullPointerException on move back in ActivityStack.

In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.

TaskRecord task may be set to null when no resumed activity remain.

Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.

The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.

Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.

To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.

Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.

Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
Fix error checking in MemoryFile.

mmap returns MAP_FAILED on failures, not 0 (NULL).
Also, convert some C style casts to C++ since they
make intent clearer.

Change-Id: I367993c73e9ee576f11ebe76e530d2c2f27c662d
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

Conflicts:
	packages/Keyguard/src/com/android/keyguard/KeyguardHostView.java