Bug: 135133301
Test: No change in behavior, no new tests
Along with Id5d039761054cf8e7fb906624a277714c21156de, which does the
rename in the header, this does the rename in the impl.
Change-Id: I27244df241a8141b0fd39e02e778eef2975f4dc0
Bug: 135133301
Test: I32e9a257a63382629b25f64d1d0abe9682ddec70
Make sure the Bitmap is valid before trying to read its data space.
Change-Id: I0d075197ddc548143a4e4845cc5cc5d3b10d87c7
Bug: 135133301
Test: I2c1e58c41e49c72fb4bdbc64989da103885d34bf
_getInfo now sets a bit in AndroidBitmapInfo.flags to indicate whether
the Bitmap has Config.HARDWARE.
For a HARDWARE Bitmap, its AHardwareBuffer can now be retrieved with
AndroidBitmap_getHardwareBuffer. Call AHardwareBuffer_acquire on the
buffer so it will not be deleted while the client is using it.
Change-Id: I9240c1928c1478053ecf7c252443a33dbd6fd6db
Bug: 135133301
Test: Ifbcb41388a48afc64bb22623bb7e981b288b2457
Refactor the bulk of Bitmap_compress into hwui/Bitmap::compress, so that
it can be shared by the new API. Update its enum to match the proper
style. Also make the enum a class so it does not need to have a special
return value for a bad parameter, which is now handled by the caller.
Add ABitmap_compress, which implements the new API by calling
hwui/Bitmap::compress.
Change-Id: Ia8ba4c17b517a05b664c6e317e235836473fd7f6
Originally reviewed in Ie05a45da32b2fd670abdae35626cd6548cfb102c
(and reverted in I0b06312f6583f766512cc771a35d3d735debcce1)
Bug: 135133301
Test: I7a5fcb726fba0c832bbb86a424d7534a7cfa35b6
This supplements AndroidBitmap_getInfo, allowing NDK clients to know how
to interpret the colors in an android.graphics.Bitmap.
Only build android_bitmap.cpp on Android so that it can rely on
libnativewindow (which is Android-only) for data_space.h
Change-Id: I4b23c68c7e62ed733e95af6f76c47fecbc2c5747
Bug: 135133301
Test: I7a5fcb726fba0c832bbb86a424d7534a7cfa35b6
This supplements AndroidBitmap_getInfo, allowing NDK clients to know how
to interpret the colors in an android.graphics.Bitmap.
Depends on I8e06071060ab19b103900ff04d60f1c3d3fccda9
Change-Id: Ie05a45da32b2fd670abdae35626cd6548cfb102c
the NDK APIs are implemented in terms of the APEX APIs to
reduce the number of different implementations serving the
same fundamental purpose.
Bug: 137655431
Test: CtsGraphicsTestCases
Change-Id: Idc7b85403a7e546843b9c1d822acc0a1e740059a
Also kills off one user of GraphicsJNI.h!
Change-Id: Icbf979e485b3b6ec2f37e18ff654b8ff1e44fb35
Fixes: 34712423
Test: cts CtsGraphicsTestCases --test android.graphics.cts.BitmapTest#testNdkAccessAfterRecycle passes
Bug: 18928352
Also fix an issue around re-configure not properly handling
mPinnedCount in android::Bitmap
Change-Id: I1815b121f1474ad931060771bb1d52ef31d2aac7
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Attempt #2 to land this, original issue was in getSkBitmap
and should be fixed
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
Fix a bunch of places where mNativeBitmap was being
poked at directly, switch them either to the NDK API
or to GraphicsJNI where it made sense
Change-Id: I6b3df3712d6497cba828c2d3012e725cb4ebb64d
Without this call, the NDK bitmap methods don't work in
hardware-accelerated mode ( http://b/5017848 ).
Change-Id: Icae6975757c9c9e83c0e9fc132161aa3004f8f28
