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
Bug: 27719830
To turn on warnings, apps have to add to their Activity.onCreate() method
the following code.
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedClosableObjects()
.penaltyLog()
.build());
For Slang generated ScriptC derived classes, we assume their
constructors won't throw exceptions after calling the ScriptC
constructor. In addition, ScriptIntrinsic derived classes do not seem
to throw exceptions in their constructors either. Therefore, we can
leave the guard.open() call in the Script constructor. This may be
only an approximation, but allows us to add CloseGuard for script
objects without making changes to slang.
Change-Id: I77ed45239a60b85af5c811dee6c124fb53da9060
(cherry picked from commit eb4dd08ec132f83745b8b28fa7da58eb4478b5b9)
Bug: 27439261
Script Group needs to know the code cache path before it can call bcc to
merge kernels. However, before this change, the code cache path has been
initialized by the ScriptC class.
In the case where a script group (or even the entire app) does not contain any
regular script but only intrinsics, the code cache would remain uninitialized.
Fixed this by initializing the code cache path in the RenderScript class
the first time when the accessor method is called.
Change-Id: I87f9e62e0f3b479f94e43daa3e9695a5b38710db
(cherry picked from commit 689f63770048589e1001ce99faf1d2eaf9780a80)
Bug: 25602504
1) Passing floating point values into a script group was broken,
since they were casted to long values. Fixed that in the frameworks
implementation by taking the raw bits instead.
2) Passing 64-bit values into a script group was broken on 32-bit
platforms, since they were casted to pointer-sized integers
(uintptr_t) in the JNI code. Fixed that by casting to int64_t
instead.
3) Setting global variables of Allocation type in a script group was
broken. The special size value -1 was used to indicate the value is an
Allocation. However, size was casted to size_t in the JNI code.
Fixed that by using signed integers.
Change-Id: Ifff099a76be7707df7b67c388395f5a00f9cae66
b/21187932
Made it an opaque class, since there is no need for a user to
inspect its fields after creation.
Change-Id: I9101afdecc5e25bb484d060be2a08c470faa92e5
b/21187932
Dependency from one kernel to another kernel -- where one reads the
other's output to a global allocation -- was not handled correctly.
This CL fixed that. Needed to make a new CTS test pass.
Change-Id: I500f9cac9d89bcaec7c186e942ba4a7d413daadb
And mark existing methods and builder deprecated.
Removed ScriptGroup2 class.
Renamed nested class UnboundValue to Input.
Marked classes Closure, Future, and Input as final.
Change-Id: I362910c115e9d0173dc515674e08bf4878232879
