See build/soong/README.md for more information.
Test: m -j
Change-Id: If302f63276fa815423f50df0f12c1700975dbc43
Merged-In: If302f63276fa815423f50df0f12c1700975dbc43
(cherry picked from commit 02a8657837321c12ec81207bf43e3ace61b3962f)
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