8 ms·

Build Android apps without an Android SDK using PicoLisp

126 points by ducktective 4y ago

edf13 4y ago
So just a Lisp interpreter for Android? >The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.
- paskozdilar 4y ago
  So we have a Java Virtual Machine that runs a PicoLisp Virtual Machine which runs PicoLisp programs. The circle of life? Perhaps the next step would be to implement a Java Virtual Machine in PicoLisp.
  - outworlder 4y ago
    Greenspun's tenth rule?
  - kitd 4y ago
    Well, the JVM just starts the PicoLisp binary and runs a WebView pointing to it, so there's no actually implementing going on.
    - paskozdilar 4y ago
      Ah, I see. I didn't think it was possible to run native binaries on Android. Cool to see it happen :)
      - ianlevesque 4y ago
        It's a little convoluted since the app does still fork from the zygote with ART in there, but they added an entire layer of APIs so you can jump right in from C++. Here's a sample https://github.com/android/ndk-samples/blob/master/native-activity/app/src/main/cpp/main.cpp https://github.com/android/ndk-samples/blob/master/native-ac...
- dmitrybrant 4y ago
  > So just a Lisp interpreter for Android? A Lisp interpreter for a single specific ABI of Android, with which you communicate through a local web server. That's... one way to build an app!
  - actionfromafar 4y ago
    I think it sounds worse when you put it like that. In practice, it will run on most phones. Google is phasing out 32-bit[0] and x86 was never really a thing for Android, more than a curiosity. 0: https://www.zdnet.com/article/google-to-64-bit-android-device-owners-no-more-32-bit-only-apps-from-aug-2021/ https://www.zdnet.com/article/google-to-64-bit-android-devic...
    - kllrnohj 4y ago
      x86 is commonly used for emulators which is very useful for compatibility testing. Although if the goal is to not install the Android SDK for some reason then sure, don't really need to care about x86. Unless you want to run on Chromebooks or Windows 11, though. Then you do again.
haolez 4y ago
I assume the same approach wouldn't be possible on iOS, since it seems very dynamic in nature.
- andyjohnson0 4y ago
  I can't find the details right now, but iirc Apple has strict rules about apps that contain interpreters and other execution environments.
  - djxfade 4y ago
    Interpreted languages are OK, and there are many examples of it. What Apple doesn't allow is JIT
    - andyjohnson0 4y ago
      Good! Thanks for clarifying that.
    - srcreigh 4y ago
      This doesn’t pass the sniff test for me. A language interpreter with downloading remote code abilities is basically a new web browser. Maybe doesn’t use HTTP/HTML/JS, but has similar dynamic abilities. That’s what apple doesn’t want on their platform. Why do you say it has to do with JIT languages?
      - lilactown 4y ago
        AFAIK (maybe someone else will correct me) there are two things that people run into when implementing interpreters: 1. You can't write a JIT because you need to be able to dynamically allocate executable memory, which is typically not allowed 2. The App Store needs to know up front what native methods & behavior your app accesses so that it can allow users to observe and control what your app can access. Accessing new native methods by downloading random code over the internet is not allowed There are ways to get around (2) by ensuring you request access to everything your app could possibly access up front, but that could also lead to rejections for asking for permission for things your app doesn't actually need. It's a bit of a dice roll. There was talk that ability to do (1) might be coming in an update a couple years ago, but no official policy change ever came of it.
prosaic-hacker 4y ago
I would not be surprised if other constrained interpreter environments could be created like this one. From the descriptions I believe a Hypercard, Logo, python or (forgive me from saying this) Basic scripting could be created. We could turn lots of older phones into portable toy dev platforms for the next gen of programmers. 10 minutes searching: https://play.google.com/store/apps/details?id=com.krazeapps.pythonprogrammingcompiler&gl=US https://play.google.com/store/apps/details?id=com.krazeapps.... https://play.google.com/store/apps/details?id=and.bas&gl=US https://play.google.com/store/apps/details?id=and.bas&gl=US
- 0xdeadbeefbabe 4y ago
  > or (forgive me from saying this) Basic scripting could be created. It's worth pointing out that no CPUs took offense.
- never_inline 4y ago
  > portable toy dev envs There's also termux and it's predecessors, running debian rootfs with or without root. (Most of them based on proot). Before proot, there were some manually ported GCC and friends. Some years ago, I had an android 5 phone and hacked up a fakechroot'ed debian rootfs on a terminal emulator without root. Basically unpacking some debian .debs with statically linked busybox binary, then using a chain of LD_PRELOAD hacks to call a shell with a shim. But proot is better solution (ptrace instead of shim), and termux is very well done. On the other hand, if you're thinking about scripting without all the hassle of Unix, I saw an app for experimenting with Android APIs using beanshell [1], I made an attempt to create a modern clone for my Android course project this year, but couldn't take it much far due to shortage of time. [1] https://f-droid.org/en/packages/org.ligi.ajsha/ https://f-droid.org/en/packages/org.ligi.ajsha/
RcouF1uZ4gsC 4y ago
Along these same lines, I would love to have Visual Basic for Android.
- orionion 4y ago
  You might try RFO-Basic https://www.tapatalk.com/groups/rfobasic/ https://www.tapatalk.com/groups/rfobasic/
victornomad 4y ago
I took a similar approach with PHONK https://phonk.app https://phonk.app The differences are: - It uses a Javascript interpreter - It includes an on-device-hosted WebEditor, so you can code also from your computer - Simplified API - API that allows to do cool stuff such connect to Arduinos, BT BLE, MQTT, sensors, etc After some time on hold I picked up dev again and I'm about to release a pretty nice release soon. I invite you to join the Discord channel as I will start posting updates there :) https://discord.com/invite/Rt2mkWp https://discord.com/invite/Rt2mkWp (EDIT: formatting)
- Reitet00 4y ago
  The play store link seems to be broken or is it just me?
  - victornomad 4y ago
    Yes, it's broken. I'll update the website soon with the next release to reflect this. Work&family doesnt leave me much free time for this :) Not so far ago, Google changed some policies where you had to give good reasons to allow the app to access the location in the background. PHONK was unlisted then because I failed to showcase the reason for using the background location (they wanted a video and the video I provided seemed not clear enough to be understood) PHONK is a coding environment that gives a lot of power to the user to do pretty much anything with the device. So if you want to make a script that runs in the background to create a Geolocation game, you can do it. After a few changes like this, I realized that I'm going to distribute PHONK only as an APK, F-droid from the next version, and of course with the source code in Github. Just to make it clear, PHONK doesn't use analytics or send info anywhere as opposed to most of the apps. I had hoped Google store could see that to give more margin for apps that behave nicely with the user.
    - Reitet00 4y ago
      Maybe it would be a good idea to link to F-Droid then? I'm using it and would've totally ignored the app if you didn't reply here :)
yewenjie 4y ago
Yes, please. The recommended Android development environment is huge bloat and overwhelming for quickly starting a project.
rathereasy 4y ago
Is this React Native with Lisp instead of JavaScript?
adamius 4y ago
This would be great on iOS but I sense it would be blocked by Apple. Ipad/iphone versions would be an excellent addition.
anta40 4y ago
Being able to code in your phone is fun... although as a native Android developer this won't replace Android Studio for me (yes bloated/resource hungry bla bla bla... I know). Anyway, let's give it a try: Typing "$ ls -l" on the REPL input box gave: "-> NIL" And repeated back press won't close PilBox. Seems like it's intentional (or just a bug?). Will take a look at the source code later...
YourGrace 4y ago
It's nice to see new tools and SDKs being built to try and simplify development. However, I'm always against frameworks/SDKs which try to abstract away the native coding experience and move developers away from using the SDKs Apple/Google provide. These types of solutions will always lag behind the official SDKs, and require ongoing maintenance from the authors as new features are added. This also requires individuals to learn something else in addition to the core SDK (I believe you will ultimately need to learn about the core SDK regardless of what you want to do). In my opinion, working with the native SDKs is the best solution. You are as close to the SDK as possible and are able to do what you want. For Android in particular, it's important to minimize the layers between your code and drawing the UI. With that said, kudos on building this as it's no easy feat to accomplish.

126 points by ducktective 4y ago

So just a Lisp interpreter for Android? >The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.

paskozdilar 4y ago
So we have a Java Virtual Machine that runs a PicoLisp Virtual Machine which runs PicoLisp programs. The circle of life? Perhaps the next step would be to implement a Java Virtual Machine in PicoLisp.
- outworlder 4y ago
  Greenspun's tenth rule?
- kitd 4y ago
  Well, the JVM just starts the PicoLisp binary and runs a WebView pointing to it, so there's no actually implementing going on.
  - paskozdilar 4y ago
    Ah, I see. I didn't think it was possible to run native binaries on Android. Cool to see it happen :)
    - ianlevesque 4y ago
      It's a little convoluted since the app does still fork from the zygote with ART in there, but they added an entire layer of APIs so you can jump right in from C++. Here's a sample https://github.com/android/ndk-samples/blob/master/native-activity/app/src/main/cpp/main.cpp https://github.com/android/ndk-samples/blob/master/native-ac...
dmitrybrant 4y ago
> So just a Lisp interpreter for Android? A Lisp interpreter for a single specific ABI of Android, with which you communicate through a local web server. That's... one way to build an app!
- actionfromafar 4y ago
  I think it sounds worse when you put it like that. In practice, it will run on most phones. Google is phasing out 32-bit[0] and x86 was never really a thing for Android, more than a curiosity. 0: https://www.zdnet.com/article/google-to-64-bit-android-device-owners-no-more-32-bit-only-apps-from-aug-2021/ https://www.zdnet.com/article/google-to-64-bit-android-devic...
  - kllrnohj 4y ago
    x86 is commonly used for emulators which is very useful for compatibility testing. Although if the goal is to not install the Android SDK for some reason then sure, don't really need to care about x86. Unless you want to run on Chromebooks or Windows 11, though. Then you do again.

haolez 4y ago

I assume the same approach wouldn't be possible on iOS, since it seems very dynamic in nature.

andyjohnson0 4y ago
I can't find the details right now, but iirc Apple has strict rules about apps that contain interpreters and other execution environments.
- djxfade 4y ago
  Interpreted languages are OK, and there are many examples of it. What Apple doesn't allow is JIT
  - andyjohnson0 4y ago
    Good! Thanks for clarifying that.
  - srcreigh 4y ago
    This doesn’t pass the sniff test for me. A language interpreter with downloading remote code abilities is basically a new web browser. Maybe doesn’t use HTTP/HTML/JS, but has similar dynamic abilities. That’s what apple doesn’t want on their platform. Why do you say it has to do with JIT languages?
    - lilactown 4y ago
      AFAIK (maybe someone else will correct me) there are two things that people run into when implementing interpreters: 1. You can't write a JIT because you need to be able to dynamically allocate executable memory, which is typically not allowed 2. The App Store needs to know up front what native methods & behavior your app accesses so that it can allow users to observe and control what your app can access. Accessing new native methods by downloading random code over the internet is not allowed There are ways to get around (2) by ensuring you request access to everything your app could possibly access up front, but that could also lead to rejections for asking for permission for things your app doesn't actually need. It's a bit of a dice roll. There was talk that ability to do (1) might be coming in an update a couple years ago, but no official policy change ever came of it.

prosaic-hacker 4y ago

I would not be surprised if other constrained interpreter environments could be created like this one. From the descriptions I believe a Hypercard, Logo, python or (forgive me from saying this) Basic scripting could be created. We could turn lots of older phones into portable toy dev platforms for the next gen of programmers. 10 minutes searching: https://play.google.com/store/apps/details?id=com.krazeapps.pythonprogrammingcompiler&gl=US https://play.google.com/store/apps/details?id=com.krazeapps.... https://play.google.com/store/apps/details?id=and.bas&gl=US https://play.google.com/store/apps/details?id=and.bas&gl=US

0xdeadbeefbabe 4y ago
> or (forgive me from saying this) Basic scripting could be created. It's worth pointing out that no CPUs took offense.
never_inline 4y ago
> portable toy dev envs There's also termux and it's predecessors, running debian rootfs with or without root. (Most of them based on proot). Before proot, there were some manually ported GCC and friends. Some years ago, I had an android 5 phone and hacked up a fakechroot'ed debian rootfs on a terminal emulator without root. Basically unpacking some debian .debs with statically linked busybox binary, then using a chain of LD_PRELOAD hacks to call a shell with a shim. But proot is better solution (ptrace instead of shim), and termux is very well done. On the other hand, if you're thinking about scripting without all the hassle of Unix, I saw an app for experimenting with Android APIs using beanshell [1], I made an attempt to create a modern clone for my Android course project this year, but couldn't take it much far due to shortage of time. [1] https://f-droid.org/en/packages/org.ligi.ajsha/ https://f-droid.org/en/packages/org.ligi.ajsha/

RcouF1uZ4gsC 4y ago

Along these same lines, I would love to have Visual Basic for Android.

orionion 4y ago
You might try RFO-Basic https://www.tapatalk.com/groups/rfobasic/ https://www.tapatalk.com/groups/rfobasic/

victornomad 4y ago

I took a similar approach with PHONK https://phonk.app https://phonk.app The differences are: - It uses a Javascript interpreter - It includes an on-device-hosted WebEditor, so you can code also from your computer - Simplified API - API that allows to do cool stuff such connect to Arduinos, BT BLE, MQTT, sensors, etc After some time on hold I picked up dev again and I'm about to release a pretty nice release soon. I invite you to join the Discord channel as I will start posting updates there :) https://discord.com/invite/Rt2mkWp https://discord.com/invite/Rt2mkWp (EDIT: formatting)

Reitet00 4y ago
The play store link seems to be broken or is it just me?
- victornomad 4y ago
  Yes, it's broken. I'll update the website soon with the next release to reflect this. Work&family doesnt leave me much free time for this :) Not so far ago, Google changed some policies where you had to give good reasons to allow the app to access the location in the background. PHONK was unlisted then because I failed to showcase the reason for using the background location (they wanted a video and the video I provided seemed not clear enough to be understood) PHONK is a coding environment that gives a lot of power to the user to do pretty much anything with the device. So if you want to make a script that runs in the background to create a Geolocation game, you can do it. After a few changes like this, I realized that I'm going to distribute PHONK only as an APK, F-droid from the next version, and of course with the source code in Github. Just to make it clear, PHONK doesn't use analytics or send info anywhere as opposed to most of the apps. I had hoped Google store could see that to give more margin for apps that behave nicely with the user.
  - Reitet00 4y ago
    Maybe it would be a good idea to link to F-Droid then? I'm using it and would've totally ignored the app if you didn't reply here :)

yewenjie 4y ago

Yes, please. The recommended Android development environment is huge bloat and overwhelming for quickly starting a project.

rathereasy 4y ago

Is this React Native with Lisp instead of JavaScript?

adamius 4y ago

This would be great on iOS but I sense it would be blocked by Apple. Ipad/iphone versions would be an excellent addition.

anta40 4y ago

Being able to code in your phone is fun... although as a native Android developer this won't replace Android Studio for me (yes bloated/resource hungry bla bla bla... I know). Anyway, let's give it a try: Typing "$ ls -l" on the REPL input box gave: "-> NIL" And repeated back press won't close PilBox. Seems like it's intentional (or just a bug?). Will take a look at the source code later...

YourGrace 4y ago

It's nice to see new tools and SDKs being built to try and simplify development. However, I'm always against frameworks/SDKs which try to abstract away the native coding experience and move developers away from using the SDKs Apple/Google provide. These types of solutions will always lag behind the official SDKs, and require ongoing maintenance from the authors as new features are added. This also requires individuals to learn something else in addition to the core SDK (I believe you will ultimately need to learn about the core SDK regardless of what you want to do). In my opinion, working with the native SDKs is the best solution. You are as close to the SDK as possible and are able to do what you want. For Android in particular, it's important to minimize the layers between your code and drawing the UI. With that said, kudos on building this as it's no easy feat to accomplish.