Resurrect older Android compatibility

[0-8-15]

recently support for Android API versions less than 23 was dropped.

This breaks half of my test devices and whom else perfectly good gadgets too.

Can this be resurrected?

[mgorges]

This is not correct SETUP.template#L8 proposed 21, and while loaders/android/AndroidManifest.xml.in#L8 targets 28, as required to submit to the Google Play Store, this can be lowered if needed. In fact lowering it gets around some of the permission issues we are currently working on. There are a bunch of people, who target 21 routinely, and have no problems with this. In fact you can go even lower if you so desire - I tried 19, and while it stops building arm64 as that is not available, and is recovered and warned about in targets/android/host_linux_arm64, I didn't see any other problems?

Can you elaborate why you believe 23 is now required and lower versions are no longer supported?

[mgorges]

Purposefully picking an example that has a lot of dependencies:

 ~/Documents/Programming/parts %./configure WidgetDemo android-19
==> configured to build WidgetDemo for android [api-19] in normal mode
√ ~/Documents/Programming/parts %make; make install
[...]
==> creating android loader needed for WidgetDemo..
 == this SDK is gradle based, adjusting for ant build..
 => creating android project..
 => using target 1 [API 19]
[...]
 => compiling application..
 => transferring application..
 => signing application with keystore /Users/mg/.lambdanative/android.keystore
jar signed.
 => zipaligning..
 => cleaning up..
 == restoring gradle build.
=== /Users/mg/Library/Caches/lambdanative/android/arm-api19/WidgetDemo
==> making package..
=== /Users/mg/Library/Caches/lambdanative/packages/WidgetDemo-0.1-android-api19.apk
=== using profile PART BC Children's [/Users/mg/Documents/Programming/parts/PROFILE]..
=== configured to build WidgetDemo version 0.1 for android on macosx in normal mode

==> attempting to install android application WidgetDemo..

[0-8-15]

Am Sun, 18 Oct 2020 15:00:47 -0700 schrieb Matthias Görges <[email protected]>:

This is not correct [SETUP.template#L8](https://github.com/part-cw/lambdanative/blob/master/SETUP.template#L8) proposed **21**, and while [loaders/android/AndroidManifest.xml.in#L8](https://github.com/part-cw/lambdanative/blob/master/loaders/android/AndroidManifest.xml.in#L8) targets **28**, as required to submit to the Google Play Store, this can be lowered if needed. In fact lowering it gets around some of the permission issues we are currently working on. There are a bunch of people, who target **21** routinely, and have no problems with this. In fact you can go even lower if you so desire - I tried **19**, and while it stops building `arm64` as that is not available, and is recovered and warned about in [targets/android/host_linux_arm64](https://github.com/part-cw/lambdanative/blob/master/targets/android/host_linux_arm64),

Ah, OK, I miss-read the warning in android/build-binary line 60.

I didn't see any other problems? Can you elaborate why you believe **23** is now required and lower versions are no longer supported?

I have an app which runs with api26 and builds+installs with api19. But it does no longer starts on api19. It does in fact not even create the (system-directory) on the sdcard. I did so manually and a `log` subdirectory too. No logging output at all.

[mgorges]

Okay, for a start two questions:

1. Which API level are you targeting - 19, I assume? As in what is written to loaders/android/AndroidManifest.xml.in#L7
2. Anything useful in logcat - note even a NULL pointer exception?

[0-8-15]

Am Mon, 19 Oct 2020 01:31:22 -0700 schrieb Matthias Görges <[email protected]>:

Okay, for a start two questions: 1. Which API level are you targeting - 19, I assume? As in what is written to

Yes. Turned out that somehow the permission "write external storage" was off. (I did not touch that manually.)

[loaders/android/AndroidManifest.xml.in#L7](https://github.com/part-cw/lambdanative/blob/master/loaders/android/AndroidManifest.xml.in#L7) 2. Anything useful in `logcat` - note even a NULL pointer exception?

Not really useful. The log is full of "couldn't find task for AppWindowToken"

[0-8-15]

Looks like Android 10 has changed things wrt. JNI:
https://developer.android.com/distribute/best-practices/develop/restrictions-non-sdk-interfaces

So far no good idea. For a start this looks like a killer.

[mgorges]

Turned out that somehow the permission "write external storage" was off.

Okay, we need to add something to prompt a window or at least not die immediately. I think this is true when there is no sdcard active in the simulator and one uses EMBED right now too.

[mgorges]

So far no good idea. For a start this looks like a killer.

It says for 'some non-SDK methods and fields', and also some libraries that they consider private, so we may be okay but if they actually disable JNI we are obviously done with Android. Public libraries are listed at https://android-developers.googleblog.com/2016/06/improving-stability-with-private-cc.html. Finally, now that we target 28, and some of our devices running on 29 we might get lucky once the permission piece is sorted out?

[0-8-15]

I just got a first alternative working. We can avoid the JNI call altogether. Just checked into my repo.

Works for me with Android 8.1. Testing on Android 10 takes time: I can't attach the USB debugger. :-/ And how do I enable developer options in Android 10? Seems like the 7x Android-version easter egg is gone.

[0-8-15]

See PR #376 for my current situation.

This might make the questions regarding #338 (jScheme) more important. That one requires only three or so JNI calls to work.

I might have to turn client/server relationship upside down - no big deal, just takes time.

[mgorges]

And how do I enable developer options in Android 10? Seems like the 7x Android-version easter egg is gone.

https://developer.android.com/studio/debug/dev-options says it is still the same?

[0-8-15]

Am Mon, 19 Oct 2020 12:51:27 -0700 schrieb Matthias Görges <[email protected]>:

> And how do I enable developer options in Android 10? Seems like the > 7x Android-version easter egg is gone. https://developer.android.com/studio/debug/dev-options says it is still the same?

Maybe. Reading deeper I found that "some devices" might hide the "developer options" somewhere. That's not my phone and I don't want to take the time right now to learn where it might be hidden. Just now no `adb` and hence no `logcat` - make things harder. And I'll have to hand the phone back tomorrow. :-/

[ddunsmuir]

I have a Samsung phone with Android 10 and the Developer Mode is right on the main menu as per usual and was unlocked the same way, so I can confirm that at least for some devices, it has not changed.

[0-8-15]

I have a Samsung phone with Android 10 and the Developer Mode is right on the main menu as per usual and was unlocked the same way, so I can confirm that at least for some devices, it has not changed.

Managed to get adb working.

Warning: On Android19, likely arm64, watch for implicit declared C functions. Code working with those compiler warnings on Android 8.1 arm 32 bit segfaults for me.

Does anybody know where the shared libraries are under newer Android?

My app includes a command line program, which is included per old trick as libcmd.so . These libs used to be in lib subdirectory of the parent of the value returned by Androids getFilesDir(). No longer they are.