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'
Merged-In: I853372f3c6fef905553bb31be4f1bb48df735f7a
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 dc01e938c2)
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.
AllocationGetSurface driver implementation change.
- AllocationGetSurface now returns opaque handle to ANativeWindow*,
instead of IGraphicBufferProducer*, as IGraphicBufferProducer is not
part of NDK. So the JNI side need to change accordingly.
Bug: 34396220
Test: mm, CTS tests pass.
Change-Id: If9b6a733202d29bc40c0e0b87c4fb48db092cbe5
from Java Surface.
- ANativeWindow_fromSurface and ANativeWindow_release has to be used in
pairs to avoid leaks.
Bug: 34396220
Test: mm, CTS tests pass.
Change-Id: Id67fd005a056df4d496a48f705d445a2d8c45232
