Also don't require LINUX to be defined, enable the MSVC typedefs
only within _MSC_VER.
This fixes a lot of warnings about dereferencing pointer 'winPtr'
breaking strict aliasing rules.
Change-Id: I4afbe0ed81295ebe6e5ee2c7f0fb0cc2dc83c89b
Currently, a pointer to a Word32 is used as a pointer to Word16, which
doesn't work as intended on big endian architectures.
This change needs to be analyzed and tested properly so that it doesn't
cause issues with overflows in these variables. Another solution would be
to change all the scf arrays to 32 bit instead.
Change-Id: I53d9eb83bdaf8d3b1530eb5064dd10b08bce737a
This reduces the amount of ifdefs needed, into something that
works on both gcc and MSVC. This removes one occurrance of the
LINUX ifdef, simplifying compiling on various platforms.
Change-Id: I1e2af6c2517410dc280197ba922df877cf7afbd5
This patch fixes the update of the extras Bundle in the Location object
each time the platform derives a new GPS location and passes it to
listening applications via LocationListener.onLocationChanged().
Sometime between Android 1.6 and 2.1 a bug was introduced that stopped
any extras calculated by the platform from being added into the Location
object, which means they were never passed up to any LocationListeners
for the GPS Provider. This manifested as an issue where the number of
satellites used to derive a fix always reported “0” when retrieved from
Location.getExtras() (Issue 4810 on the Android Issues page -
http://code.google.com/p/android/issues/detail?id=4810).
Sample code to be used within
LocationListener.onLocationChanged(Location location) which demonstrates
this problem:
Bundle extras = location.getExtras();
Int numSats = extras.getInt("satellites"); //This always reports “0”
//post 1.5, although in 1.5
//it properly reported the
//number of satellites used
//to derive this location
The “satellites” extra key/value pair for Locations is defined in
http://developer.android.com/reference/android/location/Location.html#getExtras()
This patch modifies GPSLocationProvider.java to properly update the
Location object with the extras Bundle before the Location object is
passed to any listening applications, and therefore the number of
satellites used to derive a fix can now be retrieved properly through
location.getExtras() (as shown in sample code above). Therefore, this
patch fixes Issue 4810.
Change-Id: Ief21056a3623269bb3149ec78ab92738a234f57f
Signed-off-by: Sean Barbeau <sjbarbeau@gmail.com>
This was applied in AOSP master earlier, in commit
b21611e5b0f1797e39e781d91ade023bac87637f, but when merged
into the Google internal tree in
88c2d4d26d79384f32a25bd775cf873cb678b12a, none of these
changes have been brought in. (The diff of this merge commit
and its first parent, d94b71d, is empty.)
Therefore, reapply the rest of these changes on the files
that still are present in the current version.
Change-Id: I645a9b9134769958a11808a06163123d28d83e46
This change makes SurfaceMediaSource request Gralloc buffers with the
HW_TEXTURE usage bit rather than the VIDEO_ENCODER bit. It is a
temporary workaround for what is likely a Gralloc bug.
Bug: 5771063
Change-Id: I9cce615e80fc14a1644fae27ba06970c262dd179
This change makes SurfaceMediaSource request Gralloc buffers with the
HW_TEXTURE usage bit rather than the VIDEO_ENCODER bit. It is a
temporary workaround for what is likely a Gralloc bug.
Bug: 5771063
Change-Id: I9cce615e80fc14a1644fae27ba06970c262dd179
This change makes SurfaceMediaSource request Gralloc buffers with the
HW_TEXTURE usage bit rather than the VIDEO_ENCODER bit. It is a
temporary workaround for what is likely a Gralloc bug.
Bug: 5771063
Change-Id: I9cce615e80fc14a1644fae27ba06970c262dd179
