"Typical good candidates for the NDK are self-contained, CPU-intensive
operations that don't allocate much memory, such as signal processing, physics
simulation, and so on."
Ok, here's a plan for :-) a real Android picolisp ... start by taking a version
of picolisp, and begin cutting it back by dropping everything ndk c/c++ headers
do not support. So, the idea would be you'd get much of picolisp, hopefully
more than minipicolisp, at least as much as ersatz, (I would think), and with
no java interpretation penalty for the lisp interpreter.
re: "... that don't allocate much memory". Fine; allocate what you need per
application on init (from java), pass it to android picolisp to use.