More detail back to kill toast
prevent policy from spamming logs

Change-Id: I948881c304a380da6b3f5a497670aafc34b7818c
Correct the target app token for input method window

The root cause is:
There is a defect in window manager service: When a new
activity that can be ime target is added into window manager
but the Z order of input method window don't need to be
changed, then the target app token of input method window
would not be updated to new one. This defect may cause that
the layer of input method window is calculated incorrectly.

The solution:
Correct the target app token for input method window.

Change-Id: I008311e3c9b1cf5fc320b614d8675c183c506d50
Fix race condition in ActivityThread.completeRemoveProvider()

This should solve the problem when exceptions like below are thrown:
java.lang.IllegalStateException: unstableCount < 0: -1
android.os.Parcel.readException()
android.os.Parcel.readException()
android.app.ActivityManagerProxy.refContentProvider()
android.app.ActivityThread.releaseProvider()

Change-Id: I97ca9f7f0b57221bc3aa41727936292cc79b92c9
new Memory size toggle
Little fix ram memory tile
extend PreferenceActivity for title text on a single pane mode

startPreferencePanel() ignores titleText on a single pane mode
this commits extends PreferenceActivity by adding EXTRA_SHOW_FRAGMENT_TITLE_TEXT to intent

ported from CM9, http://review.cyanogenmod.org/#/c/14919
AOSP part verified, but not merged

Change-Id: Ie0702dc20b17504148f4da9cc83a6d7865d95423
Decrease lag generated by autorotation on

There are different issues from what I understand:

1) Discarding of events too close to each others is broken
as mAccelerationTimestampNanos is conditionned by isAccelerating()
on TF101 no events are discarded anymore, and so it creates an update every ~50ms
filing up the android notification message queue quite a bit for nothing and so generating lag.
2) isAccelerating seems incorrect to me too, the code means more that it's accelerating "out of range" and should be discarded in that case.

=> Discard the sample if outOfRange and don't condition the update of mAccelerationTimestampNanos that way next time we come back "too soon"
the sample will be properly discarded.

3) with events being discarded properly on the WindowOrientationListener
the SensorManager can now update every 20ms instead of 50ms
but that is definitely overkill.
=> add SystemProperty sensor.loop.minms with a default value of 50ms to throttle the notifications.
That way the thread sleeps properly instead of sending events as fast as it can.

(increasing up to 100ms can be ok depending if you want faster response or not.)
This can be positionned on a per device prop too.

4) Add 2 SystemProperties:
one on the SystemSensor side: sensor.magnitude.threshold with a default 0 value(doesn't change the behavior)
one on the WindowOrientationListener: orientation.magnitude.threshold with a 200 (0.2G) default value
These allows to discard the sample if it is too close to STANDARD_GRAVITY (ie not accelerating much)
These can be set on a per device or use the default values.
On the TF101 200 works most of the time. But weirdly when docked the reported gravity seems to have an additionnal offsert of -0.2
maybe some magnetic interference from the dock...

For the moment the 0.2G threshold is positionned on the Orientation code.
Once the cpp sensor poll crazy loop is solved it could be better to use the sensor.magnitude.threshold instead.

That should take care of most of the lag generated by autorotation.

Change-Id: I093227f539050a6bad8e6e8d9f533eff7bddd0d6
fix hover events consume issue

View#onHoverEvent() would always consume hover events over the view
if an application window has the clickable view/widget on it.
That's happened even if accessibility/talkback is disabled.
So those events will not dispatch to activity#onGenericMotionEvent().

The onHoverEvent method should return a real consumed state.

Change-Id: I9cac13b82866e5cdda0b03befb0de752a0a2e741
Clear loaders array after they are destroyed.

See change Ia577caecbacb226a3ce525a01a66283efb6ba754 for details.

Change-Id: I9f07eeceaa3829f71008e6f6a38ab849095bd69c
Signed-off-by: Roman Mazur <mazur.roman@gmail.com>
add reply.writeNoException() for quick response

In case of SET_ACTIVITY_CONTROLLER_TRANSACTION, there is no reply transaction.
So makes same to other transactions.

Change-Id: I3b9527682662a12f78cc96b6084904f18178fee7
AudioService: Don't adjust volume when vol-downing to vibrate or silent

Pressing vol-down to vibrate or silent would (previously) still adjust the
stream volume, setting the last audible volume to 0, which is not allowed
for voice-capable devices.  Thus, the last audible volume would reset to
default on reboot if on vibrate/silent or the lowest volume setting.

By not adjusting volume when vol-downing to vibrate or silent on
voice-capable devices, the last audible volume is always preserved across
reboot.
Prevent audio players starting on startup.

Previously, (at least) Apollo was started on startup (in that it
appeared in the notification bar) because it listens to the AUDIO_BECOMING_NOISY
intent to silence itself in that case. This intent is broadcast by
AudioService when there's a user switch to silence any potential audio
players for the old user. As the system also sends around a
USER_SWITCHED intent on startup, this led to the aforementioned player
startup.
As the intent of AudioService was to act on a user backgrounding anyway,
send out AUDIO_BECOMING_NOISY as reaction to a USER_BACKGROUND intent
instead of the USER_SWITCHED intent.

Change-Id: Iba35844a1274c9dd195f104068304e6a7ffa809e
Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter

Fix for Issue ID 18316. Make isEmpty() return false when getCount() returns a non-zero value. So that the list cannot be considered empty when a header or footer is present.

https://code.google.com/p/android/issues/detail?id=18316

Change-Id: Ib69201e9d5ef3efcbb68ea298b8cc8ca6e027246
Signed-off-by: Emma Sajic <esajic@effectivelateralsolutions.co.uk>
Audio continue to played even if paused manually

Currently, audio will resume playing after a phone call
or notification even if the user had manually paused playback.

This patch addresses that by introducing a new player state
to distinguish the user pausing playback and the browser
losing audio focus for some other reason. Audio will only
 resume if the browser temporarily lost audio focus and
not when the user has manually paused playback.

Change-Id: I9e8beaedb0fcc5afe920068297ed9c387eab2ac8
Signed-off-by: Roger Chen <cxr514033970@gmail.com>
Fix EventLog string class problem in onOptionMenuSelected

EventLog function can handle string,integer class and long class. (in android_util_EventLog.cpp)
If menu title string are used bold tag(like <b>test</b>), it'll be android.text.SpannedString.
In onOptionMenuSelected, it is using item.getTitleCondensed() function for writing event log.
therefore any android activity using tag menu string(like <b></b>) can be crashed by IllegalArgumentException.

I found this crash on GMS Application.
change locale chinese -> launch Google+ -> hangout -> menu key -> Invite(expressed chinese) click -> Google+ crash

Change-Id: I0437be81699925e29bf4510eb615ef2424432763
Fix NullpointException problem in onMenuItemSelected

If both title and condensed title is null,
item.getTitleCondensed() could be return null value
in onMenuItemSelected. therefore need to check
whether retun value is null or not.

Change-Id: Ib08f52b949a794aa7bd6cc25414041e820f62969
Fix DateUtils.formatElapsedTime.

More reuse of StringBuilders, less broken home-grown formatting code.

Long-term, we should hand this over to icu4c, but they're not ready yet.

Bug: http://code.google.com/p/android/issues/detail?id=41401
Bug: 7736688
Change-Id: Ib3c1e1aad05827df646aa18645cce19dffb7551f
Redesign memory usage in recent apps

Signed-off-by: htchoi1995 <htchoi1995@gmail.com>
Recents Lag Fix From PA

Signed-off-by: htchoi1995 <htchoi1995@gmail.com>