Status Update
Comments
vi...@google.com <vi...@google.com> #2
That's working as expected. Let's consult with Javier about his thoughts.
co...@zuricate.net <co...@zuricate.net> #3
Did we get any input from Javier for this?
co...@zuricate.net <co...@zuricate.net> #4
The current implementation after the fix is aligned with the foundation API AnchoredDraggable
- I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.
Let me know if you have different thoughts. : )
vi...@google.com <vi...@google.com> #5
I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.
That sounds reasonable to me. Is there a separate bug for that or should I file one?
One thing that I think will be weird is that the size of the panes can come from that anchor or from PaneScaffoldDirective defaultPanePreferredWidth (possibly influenced by the hinge?). In an ideal world, I think we would have the sizes all come from anchors, but that wouldn't work today with three panes visible. I'll add a note to the doc on this.
co...@zuricate.net <co...@zuricate.net> #6
We don't have a separate bug for that but it's already being supported via:
rememberPaneExpansionState(
...
initialAnchoredIndex = i,
)
You raised a very good point about having parallel ways to set up pane sizes.
To me it's sort of reasonable as there are actually referring to different use cases and have different priorities -
- Hinge policies always have the highest priority.
- Pane expansion (and its anchors) are associated with layout splits, but less with the "roles" of the panes that occupy those splits.
Modifier.preferredWidth
always has the lowest priority - more like a fallback default.
I guess we can have more detailed explanation in the doc if this can be confusing?
mi...@google.com <mi...@google.com> #7
Oh, it's in the remember call, perfect!
Yeah, it seems reasonable debating about the use cases, but I worry if it's reasonable for a developer who doesn't consider all that and just wants to show two panes? It's also even more nuanced since 2 only applies for two panes (e.g., if your app shows two panes in portrait on a Samsung Ultra tablet and three panes in landscape). Maybe in the kdoc we should have something similar to what you listed here and in DAC we can provide more context around these.
co...@zuricate.net <co...@zuricate.net> #8
Yeah that sounds good to me. I plan to have some time to refine our kdoc and samples no matter what. Let's maybe work on this in the upcoming alpha/beta period.
mi...@google.com <mi...@google.com> #9
co...@zuricate.net <co...@zuricate.net> #10
Good news. The new 32bit arm librsjni_androidx.so fixed the problem for HUAWEI HUAWEI Y530-U00 Android 4.3, API 18.
However, the same error (judging from the backtrace) still occurs when testing on an Android device with x64 instruction set. The crash log can be found here:
I can test, if you upload a cross compile of your librsjni_androidx.so for x64 also. I don't have a device with x86 instruction set, but the bug might be present there also?
mi...@google.com <mi...@google.com> #11
mi...@google.com <mi...@google.com> #12
co...@zuricate.net <co...@zuricate.net> #13
Btw, is
[Deleted User] <[Deleted User]> #14
When will the fixed version be distributed?
an...@google.com <an...@google.com> #15
mi...@google.com <mi...@google.com> #16
ha...@gmail.com <ha...@gmail.com> #17
[Deleted User] <[Deleted User]> #18
cc...@gmail.com <cc...@gmail.com> #19
4844xxms
حتوومي الحربي
na...@gmail.com <na...@gmail.com> #20
ma...@gmail.com <ma...@gmail.com> #21
cl...@gmail.com <cl...@gmail.com> #24
pe...@gmail.com <pe...@gmail.com> #25
Device: Motorola XT1058
OS: API 22 / 5.1
Crash stacktrace:
04-07 14:12:40.415 16319-16450/com.perracolabs.pixtica W/linker: librsjni_androidx.so: unused DT entry: type 0x6000000f arg 0xb404
04-07 14:12:40.415 16319-16450/com.perracolabs.pixtica W/linker: librsjni_androidx.so: unused DT entry: type 0x60000010 arg 0x35
04-07 14:12:40.415 16319-16450/com.perracolabs.pixtica W/linker: librsjni_androidx.so: unused DT entry: type 0x6ffffef5 arg 0xad78
04-07 14:12:40.416 16319-16450/com.perracolabs.pixtica W/linker: librsjni_androidx.so: unused DT entry: type 0x6ffffffe arg 0xad38
04-07 14:12:40.416 16319-16450/com.perracolabs.pixtica W/linker: librsjni_androidx.so: unused DT entry: type 0x6fffffff arg 0x2
--------- beginning of crash
04-07 14:12:40.420 16319-16450/com.perracolabs.pixtica A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 16450 (TaskFilter)
04-07 14:12:40.522 251-251/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-07 14:12:40.522 251-251/? I/DEBUG: Build fingerprint: 'motorola/ghost_att/ghost:5.1/LPAS23.12-21.7-1/1:user/release-keys'
04-07 14:12:40.522 251-251/? I/DEBUG: Revision: 'p300'
04-07 14:12:40.522 251-251/? I/DEBUG: ABI: 'arm'
04-07 14:12:40.522 251-251/? I/DEBUG: pid: 16319, tid: 16450, name: TaskFilter >>> com.perracolabs.pixtica <<<
04-07 14:12:40.522 251-251/? I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
04-07 14:12:40.546 251-251/? I/DEBUG: r0 b489d200 r1 a1e54144 r2 00010004 r3 00000001
04-07 14:12:40.546 251-251/? I/DEBUG: r4 00000043 r5 00000000 r6 00010004 r7 a1e47145
04-07 14:12:40.547 251-251/? I/DEBUG: r8 9f530000 r9 9f9c76d0 sl 9f9c76c0 fp b47faa6c
04-07 14:12:40.547 251-251/? I/DEBUG: ip b4838218 sp 9f9c74e8 lr b46d5665 pc a1e47156 cpsr 200b0030
04-07 14:12:40.547 251-251/? I/DEBUG: backtrace:
04-07 14:12:40.547 251-251/? I/DEBUG: #00 pc 00000156 /data/app/com.perracolabs.pixtica-2/lib/arm/librsjni_androidx.so (JNI_OnLoad+17)
04-07 14:12:40.547 251-251/? I/DEBUG: #01 pc 001e1663 /system/lib/libart.so (art::JavaVMExt::LoadNativeLibrary(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, art::Handle<art::mirror::ClassLoader>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)+1614)
04-07 14:12:40.547 251-251/? I/DEBUG: #02 pc 002081db /system/lib/libart.so (art::Runtime_nativeLoad(_JNIEnv*, _jclass*, _jstring*, _jobject*, _jstring*)+514)
04-07 14:12:40.547 251-251/? I/DEBUG: #03 pc 0007a925 /system/framework/arm/boot.oat
ba...@gmail.com <ba...@gmail.com> #26
cv...@gmail.com <cv...@gmail.com> #27
jo...@gmail.com <jo...@gmail.com> #28
jo...@gmail.com <jo...@gmail.com> #29
ma...@gmail.com <ma...@gmail.com> #30
Já tudo certo.eu estou com instabilidade nós equipamentos
Description
When androidx.renderscripot.RenderScript.create(context) is called, the application crashes with the following backtrace:
05-20 23:24:13.986 2898-2898/**** A/libc: Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 2898 (****)
05-20 23:24:14.096 291-291/? I/DEBUG: pid: 2898, tid: 2898, name: ****** >>> ****** <<<
05-20 23:24:14.506 291-291/? I/DEBUG: #00 pc 00000156 /data/app-lib/****/librsjni_androidx.so (JNI_OnLoad+17)
05-20 23:24:14.516 291-291/? I/DEBUG: bec93564 58001b14 /data/app-lib/****/librsjni_androidx.so
05-20 23:24:14.516 291-291/? I/DEBUG: bec93588 57ff7145 /data/app-lib/****/librsjni_androidx.so (JNI_OnLoad)
The crash was introduced by switching from android.support.v8.renderscript to androidx.renderscript. It occurs on
HUAWEI HUAWEI Y530-U00 Android 4.3, API 18
The crash does not occur when testing on other devices with a more recent Android version.
Build: 3.4.1, AI-183.6156.11.34.5522156, 201905012035,
AI-183.6156.11.34.5522156, JRE 1.8.0_152-release-1343-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.14.4, screens 1440x900; Retina
Android Gradle Plugin: 3.4.1
Gradle: 5.1.1
NDK: from local.properties: 20.0.5471264-beta3; latest from SDK: (not found);
LLDB: pinned revision 3.1 not found; latest from SDK: (package not found);
CMake: from local.properties: (not specified); latest from SDK: (not found); from PATH: (not found);
IMPORTANT: Please read