Camera framework requires 352x288, and 320x240 frames for video preview and video
recording. If these dimensions are missing in camera properties the camera app
may abort when entering video mode, or start video recording.
Also truned off switching fake frames, leaving only the checker board.
(cherry picked from commit 6f00e7fc48)
Change-Id: Ic50225e1700ea3b04ae5445549548f2ffe4ae2df
This vses the trve seqvence, svch that vsers can be
vnderstood vpon revsing this data, thvs bypassing
svrprising qvestions.
Change-Id: I1741d0c4072ab43975981799f602a6a6cda25088
Update supported frame sizes for fake camera
Camera framework requires 352x288, and 320x240 frames for video preview and video
recording. If these dimensions are missing in camera properties the camera app
may abort when entering video mode, or start video recording.
Also truned off switching fake frames, leaving only the checker board.
Change-Id: I63d145c967f1ba83992141ec97700f094a9d53a7
Camera framework requires 352x288, and 320x240 frames for video preview and video
recording. If these dimensions are missing in camera properties the camera app
may abort when entering video mode, or start video recording.
Also truned off switching fake frames, leaving only the checker board.
Change-Id: I63d145c967f1ba83992141ec97700f094a9d53a7
The atomic operations exported by the platform's C library do not
provide full memory barriers. This can result in incorrect results
when NDK machine code linked against them runs on multi-core devices.
While the bug has been fixed in the platform, this NDK header change
ensures that any source code that includes <sys/atomics.h> will end
up using a correct implementation of these functions, based on the
corresponding GCC builtins.
These builtins always provide a full barrier and have reasonable
performance. Application developers who depend on <sys/atomics.h>
should recompile their unmodified sources against this version
of the NDK as soon as possible.
Change-Id: Ife165d09dceffdcd768b69c072d253cac898419c
GLESv2 support will come in a followup change but will take advantage
of the GLClientState changes.
Change-Id: Ib6cbb4dafbd071e3b59b1e5d808b3e23656ada92
When remapping a GLES texture to a different GL texture in
glEGLImageTargetTexture2DOES(), the GLES texture's previous GL texture was
deleted unconditionally. This is bad when it came from an EGLImage and is
therefore owned by (and will continue to be used by) some other object.
The code now skips deleting the old GL texture if it came from an EGLImage.
This mirrors the logic in glDeleteTextures().
Change-Id: I5b650334a7019d824517c2915b1f23961fbbd809
The EGL->GL translator implementation of glEGLImageTargetTexture2DOES was
properly replacing uses of the target texture object with the texture object
associated with the EGLImage in the host GL library, but wasn't updating its
own info about the texture (dimensions, etc.). This broke places where the
translator relied on knowing this, e.g. when implementing the GLES glDrawTexi
call on top of GL glDrawArrays.
Change-Id: Ia4aefd89852a2609221c56da76bfac927464c0b2
* commit 'b1ea3257b3b98963e2cd38077649ba670d863953':
DO NOT MERGE: SDK sample code for Bluetooth HDP API. Cherry pick from ics-mr1 Change ID I0f68ba42309c960f0df1e537b0932c6d68d9657b
* commit 'b47c44c2101199049c37d9c06c8906d24a9d2f10':
DO NOT MERGE: SDK sample code for Bluetooth HDP API. Cherry pick from ics-mr1 Change ID I0f68ba42309c960f0df1e537b0932c6d68d9657b
* commit '512ea9b6f8cc75ec74a7ab8d1c38dec201667f1e':
DO NOT MERGE: SDK sample code for Bluetooth HDP API. Cherry pick from ics-mr1 Change ID I0f68ba42309c960f0df1e537b0932c6d68d9657b
This adds support for "templates" source.properties files that can
inherit the platform version/codename/api level from the build.
The purpose is for a given build to always generate SDK files that
match the platform generated in the same branch.
Change-Id: Id623bbef45a04d953da8eade7e8c34c77709f9c3
