Build Android apps without an Android SDK using PicoLisp
picolisp.com
picolisp.com
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
(EDIT: formatting)
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.
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....
It's worth pointing out that no CPUs took offense.
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.
>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.
The circle of life?
Perhaps the next step would be to implement a Java Virtual Machine in PicoLisp.
I didn't think it was possible to run native binaries on Android. Cool to see it happen :)
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!
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-devic...
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.
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.
Why do you say it has to do with JIT languages?
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.
Fortunately Apple carved out an exception for runtime object code on Apple silicon to allow optimizing interpreters to work, and they call it 'JIT.' Because of this loophole it's still possible to run Lisp compilers on MacOS on Apple silicon.
Apple never allowed the JIT loophole on IOS, which is why it's not possible to run a full Lisp compiler on IOS. You can run programs created with Lisp but you can't use any Lisp features that depend on the runtime compiler, so the language feels somewhat crippled.
However, I know of at least one application where all the game logic was built with Gambit Scheme. The scheme code was compiled to C and then embedded. One could theoretically open a remote REPL over the network and issue commands, but that feature was disabled before release.
Is that an 'execution environment' or 'interpreter'? The binary contains both.
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...