> On Sep 27, 2019, at 6:08 AM, Anton Lundin <[email protected]> wrote:
>>>
>>> So I didn't find an Android 5.0 devices (and I have so many devices, it's
>>> ridiculous), but I found a Nexus 10 with Android 5.1 and that happily syncs
>>> with the cloud... So yes, I'd love to see an actual log that shows us what's
>>> going wrong.
>>
>> You could always fire up a Android 5.0 in the emulator and test it
>> there. I'm currently flogging my laptop with testing ci-sytem changes
>> for work, but when i get some spare cycles I might test to spin up a
>> emulator and try it in that.
I haven't used the emulators in I don't know how long so I didn't even think
about this option. Oops.
> After quite a bit of 4kery i managed to build a
> subsurface-android-x86_64.apk and test it in a android 5.0 (api 21)
> emulator and here's where it crashed:
> E/AndroidRuntime( 3525): FATAL EXCEPTION: qtMainLoopThread
> E/AndroidRuntime( 3525): Process: org.subsurfacedivelog.mobile, PID: 3525
> E/AndroidRuntime( 3525): java.lang.UnsatisfiedLinkError: dlopen failed:
> cannot locate symbol "BIO_get_data" referenced by
> "/data/app/org.subsurfacedivelog.mobile-1/lib/x86_64/libssl.so"...
That's so strange. The way we build the libraries is designed to run on API 21
on newer. I need to check the build log one more time (there is some black
magic in there), but I was pretty sure that this hasn't been changed.
> E/AndroidRuntime( 3525): at java.lang.Runtime.load(Runtime.java:331)
> E/AndroidRuntime( 3525): at java.lang.System.load(System.java:982)
> E/AndroidRuntime( 3525): at
> org.qtproject.qt5.android.QtNative$3.run(QtNative.java:239)
> E/AndroidRuntime( 3525): at
> org.qtproject.qt5.android.QtThread$2.run(QtThread.java:87)
> E/AndroidRuntime( 3525): at
> org.qtproject.qt5.android.QtThread$1.run(QtThread.java:61)
> E/AndroidRuntime( 3525): at java.lang.Thread.run(Thread.java:818)
> W/ActivityManager( 1487): Force finishing activity
> org.subsurfacedivelog.mobile/.SubsurfaceMobileActivity
> I/WindowManager( 1487): Screenshot max retries 4 of Token{16028d3
> ActivityRecord{375c72c2 u0
> org.subsurfacedivelog.mobile/.SubsurfaceMobileActivity t5 f}}
> appWin=Window{1939df4b u0 Starting org.subsurfacedivelog.mobile} drawState=4
>
>
>
> On android-28, it expoded a bit differently:
> 09-27 15:02:59.288 4776 4776 W edivelog.mobil: Accessing hidden field
> Landroid/graphics/NinePatch;->mNativeChunk:J (light greylist, reflection)
> 09-27 15:02:59.288 4776 4776 E edivelog.mobil: No implementation found for
> int[] org.qtproject.qt5.android.ExtractStyle.extractNativeChunkInfo20(long)
> (tried Java_org_qt
> project_qt5_android_ExtractStyle_extractNativeChunkInfo20 and
> Java_org_qtproject_qt5_android_ExtractStyle_extractNativeChunkInfo20__J)
That's odd - I've never seen anything like this.
> Whats the take away? Don't know. Either I can't build subsurface-mobile
> for x86_64 or somethings broken.
I haven't tried an Android-x86_64 build - I think ever. I used to build x86 a
long time ago but stopped that as well.
I'll try the ARM7 Android 5.0 simulator to see if I can reproduce John's
problem - I realize that almost all my testing is on ARM64 these days - but my
Android 5.1 tablet is ARM7 as well, just as the device he produced the log from.
Thanks for your help tracking this down, Anton!
/D_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface