The original rationale is obsolete, since contexts are now almost
always shared.
This call was unbalanced; there was no corresponding
freeNativeAllocation call. Thus, in the rare cases in which this
actually makes a difference, it's likely to lead to perpetually
increasing native allocation counts, which is more likely to be
confusing than helpful to the garbage collector.
(Discussed with Tim and Jean-Luc, and concluded that it was best
just to remove the code.)
Test: Treehugger
Bug: 181351667
Change-Id: I376a16732231aad0fdacd022de301464e5ac71dd
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
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
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
Bug: 28053769
These objects are tiny and unlikely to cause memory issues.
In addition, llvm-rs-cc auto-generated code contains such objects, which are
not visibible to developers and impossible to manually destroy, leaving
distracting warnings in Strict Mode.
Test: RsTest with StrictMode on and CTS tests
Change-Id: Iec68cca4f1259124b9f503a230c1a28b97ede1f3
Bug: 23159764
Bug: 26862970
- Add detailed description of AutoPadding
- Add comments to all the copy related APIs.
- Fix typos in the comments.
Change-Id: I2d045e0d90efd94f1407f88d3e35bcd42ea93fb9
Bug: 28242626
Bug: 27972184
Bug: 27973681
This is resolving issues in ScriptGroup (V1) again.
In ScriptGroup.destroy(), we also need to consider the old API where
mClosures is not initialized.
Also cleaned up the finalizer for ScriptGroup and Allocation:
Since BaseObj.finalize() calls BaseObj.helpDestroy(), instead of
BaseObj.destroy(), there is no possibility that the finalizers of
child objects may race their parents finalizers. Note that
helpDestroy() does not try to recurse on child objects.
Change-Id: I9dbb2b60f8478f656f8a418c2b5fc8d6848aeef0
Bug: 28242626
ScriptGroup finalizer clears out the list of closures, which is
uninitialized for the old API.
Need to check null first, before accessing the list.
Change-Id: Ibf914e17a0878c8c561f823c5f6f6f6619594de1
(cherry picked from commit 07837d6dab331b1693aa3689223b4012012a7fad)
am: ecf094a
* commit 'ecf094ae9d715ac3cff6213fae4c904f9dd791e8':
Fixed ScriptGroup finalizer for old API
Change-Id: Ia673958b883634197077b69aebd8af293088fef0
Bug: 28242626
ScriptGroup finalizer clears out the list of closures, which is
uninitialized for the old API.
Need to check null first, before accessing the list.
Change-Id: Ibf914e17a0878c8c561f823c5f6f6f6619594de1
am: cc24885
* commit 'cc248853c361588eb5429aee5921acbcc1900c8a':
Destroy Type created by Allocation.createSized()
Change-Id: Ic79bbf7fbf1a3f9d8f49fdb3a3950b0383bc4dcb
