Corrected typo when checking InputStream methods

Corrected a small typo where Java InputStream methods are
incorrectly checked when creating a JNI InputStream adaptor.

Change-Id: I5f14897e0d5ddceb4b2af6be46769713f0487624
 Fix preload classname for phone policy.

	PhoneWindow$ContextMenuCallback is renamed to PhoneWindow$DialogMenuCallback
	from commit 4267534d1c42af847ed0cefd1c88c99f66b36571
	    "Action Bar now supports submenus as popups."

Change-Id: Ie9165d9458358dabe03b499862fcced690845e6f
Fix wrong condition.

Should check width and height, not width and width.

Change-Id: Ie84d3605b2a7a0f4776adb876608ea92f56817c4
Wipe the user data out in any case.

When the external storage is not mounted, the android system won't
wipe out the user data (i.e. "/data") if wipeData() is called with
the flag WIPE_EXTERNAL_STORAGE.

We think that the user data should be wiped out in any options and
also wipeData(int) method currently supports also for a external
storage. So we will also change the API reference comment.

If we should care about backward compatibility of this method behavior
with the option WIPE_EXTERNAL_STORAGE, then we would add an another
bitmask something like a ALWAYS_RESET.

Change-Id: Id7bf673c722bacc0480d32e46553b9a348513879
stagefright aacenc: Fix reading out of bounds in pow2_xy

This fixes cases where x was a large number, causing fPart to
exceed the 32 bit signed integer range (while fitting in an
unsigned 32 bit integer), making the table index a negative
number.

Change-Id: I674047db65f89148a93d218c138b42cd8305f80e
Added mpga as valid MediaFile extension

Added mpga as a valid media file extension, it is treated as mp3.

Change-Id: Ie39036d61b6ca50439861fa10be0d824dcc65ed3
MountService: unlink death notification when unregistering listeners

Change-Id: I09045cfe67f7da84bc68a50fc5440ea2c6b754e5
frameworks/base: release references of UriPermissionOwner

Change-Id: I72e2310458de15f18e6f2c67f383bbb5c8f60ae2
Fix Force Close when enable airplane mode

In GSMPhone handler for message EVENT_RADIO_OFF_OR_NOT_AVAILABLE,
the for loop was trying to remove all pending MMI code starting
from the index 0 of the ArrayList mPendingMMIs. When mPendingMMIs
has more than 1 item in the list, after the 1st one in the list was
removed, the rest in the list were shifted. The 2nd one became 1st.
Assume the list size is 2, if now the for loop goes to index 1,
access to mPendingMMIs.get(1) will result a null pointer access,
and cause a Force Close.

To fix it, make the for loop to begin with the last one in the
ArrayList mPendingMMIs.

Change-Id: I3e60086186851b1d6c10fefdb086aa0ae3e16048
stagefright aacenc: Move system headers before local headers

This avoids issues with the encoder's own definition of __inline,
which conflicts with headers brought in by string.h in glibc.

Change-Id: I9e3fbf8d892529940ea67a46e67a9abe71d9c5fa
Adds documentation to CdmaCellLocation get lat/long methods

Adds better documentation to the getBaseStationLatitude() and
getBaseStationLongitude() methods to indicate the units for latitude
and longitude in CdmaCellLocation. Unlike the Android Location API
methods, latitude and longitude in CdmaCellLocation are not in decimal
degrees but instead in 0.25 seconds due to a more obscure 3GPP standard
underlying the Telephony API.  The current Javadocs on the Android
developer page (http://goo.gl/hvWo6) do not indicate the units for
latitude and longitude in CdmaCellLocation, making it very difficult
for developers to interpret the output of these methods, especially
since 0.25 seconds is not a commonly used unit for latitude and longitude
in application-level code.  This patch adds clear documentation to
these methods so developers can clearly understand the units for
latitude and longitude without having to dig through the Android
platform source code.

Change-Id: I259bfe3b68e3999804877821680fb99a22937651
Signed-off-by: Sean Barbeau <sjbarbeau@gmail.com>
Adds utility method to convert 0.25 secs to decimal degrees

This patch adds a utility method that converts latitude and longitude
in quarter seconds units to decimal degrees units.  The Telephony API
returns CDMA base station latitude and longitude in quarter seconds
due to a 3GPP telecom standard, while the Android Location API, and
the vast majority of application-level code, uses decimal degrees.

For example, to measure the distance from the user's current location
to the base station using the Location API Location.distanceBetween()
method (http://goo.gl/YjO8O), the base station lat and long would need
to be converted to decimal degrees first.

Since most application developers will likely never use lat/long information
in quarter seconds units, and instead will need this information in decimal
degrees, this utility method will frequently be used by anyone querying
base station location data from CdmaCellLocation.

Sample values to test conversion:

0.25 seconds: lat = 399491, long = -1189145
is equivalent to
decimal degrees: lat = 27.742430555555554, long = -82.57951388888888

Change-Id: If03e741f5035a37519f50d4fb2fb3e3eef2505da
Signed-off-by: Sean Barbeau <sjbarbeau@gmail.com>
ApplicationThread: Check interface before invoking scheduleLowMemory

Change-Id: I51317386e1729366d19f7e3a1747b05170b9305a
SystemServer: Looper's getMainLooper to return ServerThread

Fix to ensure Context.getMainLooper and Looper.getMainLooper
returns ServerThread for system_server. Currently, Looper's
getMainLooper returns null.

Change-Id: I5324a1cc00e27a79ba97836a9377a584e6f76b15
Parcel compRequired flag correctly.

This should fix a couple of cases (e.g. SET_UP_MENU responses for Dual
SIM adapters) whether a command response would be rejected due to a
compRequired flag mismatch between the command sent to the Stk app and
the response received from it.

The problem was:
- STK service received command without compRequired flag set
- it passes it to the STK app, which sees compRequired set
- STK app passes back the response with the user selection
- STK service gets the response, which has compRequired set
- it discards the response, as the command details don't match
  (CatService.java:646)
Fix issue #13366. Take account of stackFromBottom in
computeVerticalScrollOffset().

Change-Id: I743708ef1ac05e358840f37010de36b7d0c6a346
Signed-off-by: Pieter-Jan Vandormael <ezelspinguin@gmail.com>
Fix SurfaceView notifies on invalid surfaces.

SurfaceView notifies registered callbacks on invalid
Surfaces.

Change-Id: Iddc9a5cd073fb73a0e7e9b9ca64ff4fac0777ca7