This is a fix for http://code.google.com/p/android/issues/detail?id=907. Note that
that issue was declined without comment, but the bug (while incredibly minor)
does exist. This can be seen on the facebook app, as well as many third party apps.
Change-Id: I8f1449c47228f5f757a5baf389656e51c817b150
as 0dp and thus while checking for condition, it should be ORed and not ANDed.
It solves Android Issue: 939
http://code.google.com/p/android/issues/detail?id=939
Change-Id: Ic18fae769480972f763f634e7462c6ed3853220b
WindowManagerService (WMS) can wrongly report windows visibility due
to wrong handling of "starting windows".
"Starting windows" are special temporary windows that are displayed
while the application is starting.
Sometimes "starting windows" are considered when checking visibility
what leads to not reported or wrongly reported visibility status.
If visibility is not reported correctly some internal flows are
not executed and WMS internal state can be wrong.
Using close instead of shutdown on the file descriptors and only clear the file
descriptor that was closed. If both file descriptors are cleared the thread
will not be able to close it.
Several functions operate on variables to which access needs to be
synchronized. However, it happens that the functions in question
are only ever called from places which have already synchronized.
Therefore, nothing is really wrong, but the functions ought to
have 'Locked' appended to their names, to indicate that it is the
caller's responsibility to synchronize before calling them.
Change-Id: I44e7dc0dff6da9436677cb10908dce41ffeba195
The DatePickerDialog in the Settings application is not updated correctly if you follow
the following step-by-step:
1. Enter Date option in settings application
2. Modify the values of the date, then cancel the changes
3. Once again enter the date option
and you can see that the title in the dialog has not been updated correctly. This is
due to a missing call to onDateChanged callback in the DatePicker class. Solution was
to add the notify call when updateTime has been called.
When radio is powered off / airplane mode, memory status updates are
ignored by RIL. With this fix, pending memory status updates are sent
again when radio is powered back on.
There exists a race condition when starting a process that recently has died.
If the ActivityManager receives the death notification for the died process
after the new process has been started but before an application thread has
been attached to the new process will the newly created process be removed
during the cleanup of the died process. If this happens when sending a broadcast
could it result in an ANR.
This is solved by doing the clean up before starting a new process that uses
the same process record.
Fixes a memory leak when input methods are switched. Uses a variety of methods
to avoid holding a reference to the InputMethodService which created the binders,
which was leaking those InputMethodServices.
See http://code.google.com/p/android/issues/detail?id=6661 for reproduction steps.
widget/CheckedTextView.java: report if the item is checked or not.
widget/CompoundButton.java: report if the item is checked or not.
widget/ProgressBar.java: isIndeterminate(), getProgress(), getSecondaryProgress(), and getMax() report what
sliders and progress bars are showing
widget/TextView.java: report the current selection: getSelectionStart() and getSelectionEnd()
This change fixes a problem where an unwanted tone is generated by audio policy manager when a MT call is answered.
This is because of a policy that replaces high visibility system sounds (ringtones, alarms...) by a beep when in call.
There is a transitory phase while the call is being answered where the phone state is changed to IN_CALL but the
ringtone is still playing. The audio policy manager then mutes the end of the ringtone and starts playing a beep
in replacement because the ringtone is categorized as high visibility.
The fix consists in changing the ringtone stream type from high visibility to low visibility. This is not a problem as
the only actual use case where a ringtone would be generated while in call is if another call is received.
But in this case, the phone system does not generate a ringtone but a call waiting tone instead.
It is therefore not required to handle a ringtone as a high visibiltiy tone that must be somehow signaled to the user
while in call.
Merge commit 'ee3bbefd34fd5330ebbc59175a328197ab7526af' into eclair-plus-aosp
* commit 'ee3bbefd34fd5330ebbc59175a328197ab7526af':
Don't crash the system process when apps give us a bad foreground service notification.
Merge commit '00b17659bb4b2774580eea523c5f23b588105ab6' into eclair-plus-aosp
* commit '00b17659bb4b2774580eea523c5f23b588105ab6':
Manual merge of 40245 (ed5c973fc23a6733fd473ad13b4eb317e74e9bb5) DO NOT MERGE.
Merge commit '67e9e9df929aad9139f1dc776b15f6c5d64f424e' into eclair-plus-aosp
* commit '67e9e9df929aad9139f1dc776b15f6c5d64f424e':
Manual merge of 40170 (b4a107d8269d1a75b8f270e0516c1fa3b517f8f9) DO NOT MERGE
Merge commit '8368ef0b670f8193f3161671b119e78b1fb659a1' into eclair-plus-aosp
* commit '8368ef0b670f8193f3161671b119e78b1fb659a1':
Manual merge of 40080 DO NOT MERGE
This solves a race condition between the network type changing and
a signal strength changing. This could cause StatusBarPolicy to see
the -1 values for the evdo strength parameters and hence 0 bars would
be displayed.
Bug: 2419251
Change-Id: Iba0bdbd2023b6a5e49fc1f82c997ec3219158286
Merge commit '2be56ccbcff9d5f7b9b3cc0fed3825d4f037ff6a' into eclair-plus-aosp
* commit '2be56ccbcff9d5f7b9b3cc0fed3825d4f037ff6a':
Add --auto-add-overlay option to aapt. DO NOT MERGE
