Targets that will also be contained within the UI module
are allowed to access internal headers. All other targets
that depend on libhwui are restricted to using the APEX headers.
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: Id92e9874dafb98bd79839d45ab8f22ab999689de
This change removes usage of skia data structures and replaces
them with stable C APIs. It also removes two unused java APIs
that were missing their native components.
Test: CTS presubmit tests
Bug: 137655431
Change-Id: I18cbe0cf9dc731c4c6c1f645be0df2f462764118
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv \
git diff HEAD^ HEAD | grep '^[+-][^+-]' | grep -v '.import'
Change-Id: I853372f3c6fef905553bb31be4f1bb48df735f7a
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv \
git diff HEAD^ HEAD | grep '^[+-][^+-]' | grep -v '.import'
Change-Id: I087bb1cecbe59f1cf0c2e770c735d7a433722c6f
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases,
CtsRenderscriptTestCases
This is significantly faster than passing the Java object down and then
calling a JNI method to retrieve the pointer. See
https://buganizer.corp.google.com/issues/16656908#comment19
In some cases this changes what used to be native crashes (due to
android::BitmapWrapper:assertValid's LOG_ALWAYS_FATAL_IF) into
NullPointerExceptions (if a caller used a null Bitmap).
In addition:
- Remove unnecessary JNIEnv param from toBitmap(jlong)
- Change instances of toBitmap(JNIEnv*, jobject) to the above
- Replace calls to GraphicsJNI::getSkBitmap() to inline calls to
toBitmap/getSkBitmap
- make Canvas#nInitRaster @FastNative (FIXME: Could these be
@CriticalNative?)
Change-Id: I6194097be1b6e6952eba70e1e7052a5a250eed93
We're changing the argument type to long, since it should be roughly
large enough to hold a size_t everywhere.
Make style checker happy by reordering imports.
Test: Treehugger
Change-Id: Iccdc5fa592f56d448817f7762af1cff27b4fc2a8
For packages:
android.renderscript
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I016f6e720e79c48afe44f4690b5dd99fc81ae780
Merged-In: I1aa8ebca448547031b426a7b305c5c3d6fcf2652
For packages:
android.renderscript
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I1aa8ebca448547031b426a7b305c5c3d6fcf2652
This is a multiproject change as we need to both the libraries
themselves as well as those that had dependencies on libskia.so
Bug: 31971097
Test: compile only
Change-Id: Ie6ff1f4682d03289205f4d6048cde9f95c61a90f
libnativehelper exports headers under nativehelper. These were
available before incorrectly as global headers in order to give
access to jni.h.
Test: modules using frameworks/base find headers
Bug: 63762847
Change-Id: I0f9f231acdebe460f279135462f43d3e32eff64d
Bug: 28053584
Stop CloseGuarding for two reasons:
1) KernelID and FieldID objects are constructed in auto-generated
(RenderScript reflected) Java code. It would be impossible for a user to
explicitly call destroy() on them. Guarding them would leave a lot of
noisy warnings in logcat.
2) These KernelID and FieldID objects are not big compared to other
RenderScript objects, e.g. Allocations. They occupy almost no native
resources except for a native pointer. Leaving their destruction to Java
GC would be completely acceptable, since any delay in reclaiming them is
unlikely to cause memory pressure.
Test: CTS on x86_64 emulator
Change-Id: I587b5561a0b2bdbf0b2e95bf2995c20d5f5faf9d
Bug: 28053584
On destroying the intrinsic, destroy its contained Allocation right away.
Test: CTS on x86_64 emulator
Change-Id: I5ca0da33b620c3291b7cafda31a6cc83eb7461a0
Renderscript was depending on macros from android-base that were
transitively included from MQDescriptor.h
Test: links
Bug: 37791060
Change-Id: Ie34ddef67328c5fcc6b0122a32725b980615ff43
(cherry picked from commit dc01e938c2550390a540311b22e3e6c7603ed975)
Renderscript was depending on macros from android-base that were
transitively included from MQDescriptor.h
Test: links
Bug: 37791060
Change-Id: Ie34ddef67328c5fcc6b0122a32725b980615ff43
AllocationSetSurface.
Bug: 34334222
Test: mm, boot Sailfish, CTS pass and ImageProcessingJB works well.
Change-Id: I77e7fb69987a347862286299622343b4f7879ab0
android::IGraphicBufferProducer will now become a hybrid
interface on
top of the HIDL interface
android::hardware::graphics::bufferqueue::V1_0::IGraphicBufferProducer.
Test: With CtsMediaTestCases.apk installed,
adb shell am instrument -e size small -w
'android.media.cts/android.support.test.runner.AndroidJUnitRunner'
Bug: 33854657
Change-Id: Ia8914ea49d2acf3d43682982a164d7e10f7b8542
* changes:
[RenderScript] Update RenderScript JNI with the corresponding AllocationGetSurface driver implementation change.
[RenderScript] Use ANativeWindow_fromSurface to get ANativeWindow from Java Surface.
