
Rawdrawandroid: Build Android apps in C - pantalaimon
https://github.com/cnlohr/rawdrawandroid
======
Dig1t
"A little bit of this also has to do to stick it to all those luddites people
on the internet who post "that's impossible" or "you're doing it wrong" to
Stack Overflow questions... Requesting permissions in the JNI "oh you have to
do that in Java" or other dumb stuff like that. I am completely uninterested
in your opinions of what is or is not possible. This is computer science.
There aren't restrictions. I can do anything I want. It's just bits. You don't
own me."

This is so funny and so relatable.

~~~
gridlockd
_" I am completely uninterested in your opinions of what is or is not
possible. This is computer science. There aren't restrictions. I can do
anything I want."_

Sir, this is a mobile platform.

------
g_p
This is quite interesting to see, as I recall experimenting with something
similar a few years ago. In that case, borne out of anger and frustration from
how slow Android was at some things, I complained to one of the engineers I
had brought onboard about how a 1970s computer was vastly more responsive and
performant (to the user's perspective) than these modern (in ~2016) Android
devices. We ended up building a prototype of a vertical scrolling ListView,
implemented entirely in C, implementing all the "normal" functionality
required to allow Android to use it.

I believe my initial frustration was borne from performance tracing of an app
we were developing, and finding the amount of time spent in nested
constructors and other kinds of inherited object-oriented bloat was actually
impacting on the user perceived performance (users said it was slow to
scroll). My hypothesis was that if the functionality itself was implemented in
C, properly and efficiently, with none of these extra layers of abstraction,
it would be faster. That was definitely validated. I don't recall the figures
now, but you could scroll a list with no perceptible latency as fast as you
liked, with no stutter. The performance traces were nice and normal. It was
smooth and fast.

Mobile apps were something I got far away from for a while, but every time I
return, I'm disappointed to see an ecosystem of re-inventing the same
(boilerplate) wheel, and running the same code. For the number of layers of
abstraction I saw the OS burning cycles on, it is absurd to me why the "end-
developer" is left to do so much boilerplate coding! Surely at least one of
those layers of abstractions could get developers to a place of implementing
their own logic, rather than platform-specific logic. Case in point, the
Android activity lifecycle (!)

~~~
nexuist
It is a bit confusing why developers are still expected to implement entire
UIs themselves. Almost every app today that's not a game uses the same exact
layout: tables and grids. As a mobile app developer I could save so much time
by having the OS ask me what I want to put in these tables or grids, rather
than having to implement the UITableViews and ListViews verbatim in almost
every single project.

Since we're on this topic: Why is there still no native user
login/registration widget? Why can't the user just press a button to have the
OS autofill and save all of their information across all of their apps?

I know someone is going to say you can already do this, but the truth is, you
still can't do it reliably enough to make it the first option. Sure, password
manager extensions are supported by the OS, but I still have to go through
whatever native interface my password manager wants to show me before I can
get close to having a form filled out. In most cases, for most form fields, I
am not prompted to fill anything out unless I'm in a web browser. It's a
massive waste of time and developer energy considering these forms almost
universally require the same input: name, profile icon, email, password.

~~~
g_p
Can't agree enough - when you delve beneath the scenes, it gets so
ridiculously complex for something that just shouldn't be. For a List view, I
can understand making something to put into that view.

I miss the days of VB6 and creating a GUI in drag-and-drop, aligning
everything, and then double clicking each component to add add the default
event handler. Occasionally I didn't want the default event handler, so I'd
pick another one. Done!

I feel like with VB6 (and similar tools of the era), it was straightforward -
I knew if I wanted to set the Label of Button1 programmatically as the window
opened, I'd create a Window1.OnLoad method, and set Button1.Label to whatever
I wanted... Doing this on Android will entail reading about the opinionated
Android lifecycle model, which seems a good way of the OS forcing Devs to
handle tasks that any sane OS should (i.e. handling loading, suspending and
resumption of the app...) That should be given to me by the platform as a
default! Overrideable if needed. Why must I totally redraw everything if the
user rotates their phone? Can't I get shown 2 templates when I draw my UI, and
make the landscape one a copy of the portrait, with some common sense
adjustments (horizontal list view rather than vertical)? Then I wouldn't have
to save and restore all state if the user jostles the device!

To your point about login, absolutely - if there was a simple Login View (I
believe I recall one in VB6, just saying...) it would probably reduce a whole
host of security issues from Devs doing it wrongly and logging credentials to
places they don't belong, or putting them places they shouldn't be. It just
seems crazy that for such dense and weighty platforms, we don't get any of
this functionality included properly by the OS!

~~~
realharo
_> I miss the days of VB6 and creating a GUI in drag-and-drop, aligning
everything_

That was a fixed non-resizable layout, showing static content.

 _> I knew if I wanted to set the Label of Button1 programmatically as the
window opened, I'd create a Window1.OnLoad method, and set Button1.Label to
whatever I wanted..._

That works initially for simple UIs, but gets ugly really fast once you need
to start displaying _data_ items, including possible loading states and error
states, etc. Mobile apps tend to fetch content from the internet a lot. You
could also do your example in Android - just add a setText call to onStart of
whatever empty Activity the wizard created for you.

Jetpack Compose promises to make Android UI development much nicer in the
future
[https://developer.android.com/jetpack/compose](https://developer.android.com/jetpack/compose)
\- there is bit of a trend of mobile moving towards more React-like UI
patterns (e.g. SwiftUI, Flutter, etc.).

~~~
flukus
> That was a fixed non-resizable layout, showing static content.

It eventually morphed into the Windows Forms builder which handled dynamic
layouts quite well, if a little different to most. Elements could be
"anchored" to specific points of their container, so you button 10px off the
bottom left would always be 10px off the bottom left, elements you wanted to
grow to fill available space could be anchored on either side. All handled
well by the visual designer.

Generally I prefer the gtk/qt method of just writing code, but the forms
builder works really well too, both options are much better than the xml mess
that is android and windows development these days.

~~~
int_19h
This actually predates Windows Forms - it's the model used by Delphi/VCL (and
these days, Lazarus). However, anchors are nowhere near as flexible as layout
managers, and there are many things that they can't handle. For example, when
localizing UI, length of labels can change substantially, which requires the
other controls that they're labeling to be moved around.

------
tomcam
This looks wonderful. I wish it had been around when I was doing an android
app. I absolutely love seeing it and a good old make script. I am thrilled at
the tiny tiny runtime requirements. Bravo. This must have required an
incredible amount of experimenting and mucking through old, poorly documented
examples in the dusty corners of an SDK somewhere.

~~~
kabacha
I feel the opposite. Whenever I see Makefile being used in 2020 instead of a
hundred better modern alternatives I can't help but feel turned off.

~~~
ianlevesque
They could do the same with CMake (and regain things like IDE support) but I
think it goes against the spirit of the hack.

------
pengaru
You can similarly develop in C for Android using SDL2. Basically your app
becomes a .so with a thin java shim SDL2 provides that calls into your .so and
you're off to the races.

[https://wiki.libsdl.org/Android](https://wiki.libsdl.org/Android)

~~~
pedrohlc
In 2013 a friend and I created an SDK for building games with GNOME's Vala
(that transpires to C with GLib), SDL2 and Chipmunk physics for Android,
Linux, and Windows (all within the same codebase).

It worked flawless, I even ported a XNA example. It may be useful for someone
today: [https://github.com/avalanche-games/avalanche/wiki/Getting-
St...](https://github.com/avalanche-games/avalanche/wiki/Getting-
Started-\(for-Linux-users\)#cross-compiling-for-android-only-different-steps)

------
realharo
Plenty of games used to be written like this, where you basically had a C (or
C++) OpenGL ES platform independent code base, and then a bunch of small
platform-specific parts for the different OSes.

They did usually have tiny pieces of code in platform-native language though.

I even wrote a game like that back in 2012 (originally for Samsung's bada OS,
later ported to many things) [https://github.com/peterholak/rail-
climber](https://github.com/peterholak/rail-climber) (it says 2016 on github,
but the code is much older).

One great thing about it is, when you have a desktop target, you can
compile/test/debug things much faster (including things like level files), and
only do a mobile build every once in a while to check that it still all works
as it should. Almost like a full featured game engine.

~~~
s3cur3
This is what we do with X-Plane. It’s really, really nice to be able to debug
code destined for mobile on the desktop sim first. It cuts the iteration time
down by a huge factor.

------
benibela
I wrote my Android app in Pascal

Although I used Java to create the layouts/views.

But I have started porting some things to Kotlin. Nearly finished replacing
all the Java

I also had to buy a new computer. The Pascal IDE worked great on my ten year
old laptop; the Java/Kotlin IDE became so slow, it was unusable. It is
surprising that Java can run on a phone, when it cannot run on my development
system

~~~
realharo
If you mean Android Studio being slow (and the Android build system in
general, with its many transform steps), that has little to do with Java
itself.

Even IntelliJ IDEA, built on the same platform is much, much faster than AS
(with non-Android projects).

Android Studio is just a slow IDE. 16 GB RAM and a good CPU is the absolute
bare minimum for it these days for any non-trivial project, especially if you
want to run the emulator as well.

~~~
benibela
Yes, Android Studio (and the emulator)

The Android app development went from my first laptop with 4GB RAM and HDD to
my second laptop with 8GB RAM and HDD to my current, third laptop with 16 GB
RAM and SDD.

But all the laptops were really fast. I started writing Pascal code with
Delphi under Windows 98 on a 166 MHz PC with 64 MB RAM or something, and it
was fast enough

~~~
realharo
I'm pretty sure Delphi also didn't have the same level of code navigation and
inspections across the entire codebase (including resources, even from 3rd
party libraries), or a built-in CPU/memory/network/energy profiler of the same
quality, or layout previews that actually reflect the written code.

Android Studio is still slow even by today's standards, but that is not an
apples-to-apples comparison. There are also some ways to make incremental
debug builds faster (can be brought down to a few seconds for smaller changes,
gradle can show which step takes how long).

~~~
jfkebwjsbx
We have 3 orders of magnitude more computational resources than back then...

There is something very wrong with IDEs and complex applications these days.

~~~
realharo
The same can be said about just about any software (plus again, AS is an
exception, a typical IDE doesn't use anywhere near that much RAM - only few
hundred MB to low GBs). Everything is bigger these days - web browsers show
bigger web pages, photo editing software deals with much larger photos, etc.
Today's cars and planes are also much more complex than the cars and planes
from 100 years ago.

What it comes down to is, are the extra features provided by today's tools
worth it? For most people, that's a no brainer.

As a random example, take auto import suggestions.

I can start typing 3 or 4 letters, and get a suggestion for a function name to
call (and it's not just prefix search either, it is aware of words, etc.),
then I just hit enter, and the function call is added to my code, plus the
import statement is seamlessly added to the top of the file. I can see that
function's documentation right then and there, navigate to its implementation
and its usages inside a 3rd party library or just in my project, I get an
immediate warning if I use it wrong or make a common mistake, etc.

Then you have languages like TypeScript that automatically narrow variable
types based on the checks you perform around them. So if you have `if (user
=== undefined) { return }`, then it knows that below that block, `user` is
definitely not `undefined` and the error reporting and autocomplete reflects
that and doesn't complain. If you later remove that check, you'll immediately
see red squiggly lines on code below it that broke because it can no longer
rely on that assumption.

All of this requires having the code of my project and all of its dependencies
indexed into a pretty verbose structure, but the productivity and reliability
gains are 100% worth the extra bit of RAM and CPU time it takes - that's what
it's there for.

~~~
jfkebwjsbx
We were talking about code and IDEs, not media files.

Code completion, GUI designers and all sorts of fancy features already existed
in IDEs _20 years ago_.

You claim you have gained productivity, but coding a business app as a webpage
or as an Electron app is not any faster than making it in VB6 or Delphi was.
And the language were designed designed than JavaScript.

~~~
realharo
"Code completion" can mean many different things, from very basic features to
more advanced ones. Many "lightweight" tools I've seen lack the more useful
parts and offer only really basic completion.

For example if a function in a library I'm using is called
`createUserWithSubscription`, and I start typing `usersub` anywhere in the
project, it should offer that function near or at the top of the suggestion
list, even if its location is not already imported/included in my current
file. Things like that have a _huge_ impact on easy discoverability of a
library's functionality, which in turn has a huge impact on productivity and
speed of adopting new technology.

If I just press Ctrl+space while the cursor is inside a function call, without
typing anything, it should offer suggestions based on what other code passes
into that function, or suggestions based on the type of the argument, etc. I
don't recall these things from 20 years ago. And that is still just one of the
features.

 _> coding a business app as a webpage or as an Electron app is not any faster
than making it in VB6 or Delphi was_

I would say it is. Of course the apps made today are very different from the
apps back then, but making UI _that displays data_ is much easier.

~~~
jfkebwjsbx
The kind of features you are describing existed two decades ago, in several
IDEs, in one way or another, and for the most part do not require huge amounts
of CPU/memory. Definitely not 2 orders of magnitude more.

> Of course the apps made today are very different from the apps back then,
> but making UI that displays data is much easier.

How so? Both VB6 and Delphi were designed to display and edit data quickly.
Its main use case was creating business apps _very_ quickly and both had
WYSIWYG GUI designers in the IDE itself!

There were menus, buttons, lists, tables, tree displays, rich-text editors and
many other ready-to-use controls. You had adaptors for different databases,
OLE for embedded documents, COM support, etc. You could display images, video,
sound too. Even commercial games were developed on them.

~~~
realharo
None of that matters when once you need to display a list of items (where
every item has its own group of UI widgets), you have to start dealing with a
whole bunch of clunky model wrappers, and even basic features like sorting and
filtering require special care. Not to mention keeping all the UI in sync when
one piece of data that is displayed in more than one place changes.

Instead of just doing

    
    
        <>
          <h1>List of items</h1>
          {items
            .filter(itemFilter)
            .map(item => <div>
                {/* UI for the individual item, e.g. name,
                    subtitle, icon, buttons, etc. */ }
            </div>)}
        </>
    

that also keeps the displayed data current no matter what - new data comes in
from network, the filter in the search textbox changes, it all stays in
sync...

~~~
jfkebwjsbx
I don't understand what you are talking about. What is so special about
receiving data and displaying UI controls from it?

Networked apps, business apps, database frontends, etc. have been a thing
since the 80’s, and I am not even talking about that but IDEs from the 90’s
and later.

The code you show is identical to what was done back then in many languages,
many frameworks and many systems. Filtering, sorting, per-item UI, multi-
views, synchronization, etc. has been always a basic need.

The web is yet another UI/app framework. Nothing less, nothing more.

~~~
realharo
My point is that in environments like old-school Delphi or VB, or even with
frameworks like Qt, those things take way more effort and boilerplate code
than they should.

For exapmle in Qt you have to either subclass QAbstractListModel or use
QStandardItemModel with weird QStandardItem wrappers around your data, then
you have QSortFilterProxyModel
([https://doc.qt.io/qt-5/qsortfilterproxymodel.html](https://doc.qt.io/qt-5/qsortfilterproxymodel.html))
and all that weirdness. And then for the actual UI of the individual items,
you have QAbstractItemDelegate, etc.
[https://doc.qt.io/qt-5/qabstractitemdelegate.html](https://doc.qt.io/qt-5/qabstractitemdelegate.html)

I mean, just look at this example: [https://doc.qt.io/qt-5/qtwidgets-
itemviews-stardelegate-exam...](https://doc.qt.io/qt-5/qtwidgets-itemviews-
stardelegate-example.html)

No way that should take that much code.

~~~
jfkebwjsbx
If you say so. I have worked professionally in quite a few UI frameworks and
they are pretty much the same.

The web is actually one of the most complex ones out there due to the never
ending frameworks and libraries that come into fashion every other year. Old
environments had a defined set of things to use and learn and things were
stable for many years.

In Qt you can build your UI on the fly with code without using those classes
if that is what you are asking.

~~~
realharo
I doubt I could build something like this

[https://codesandbox.io/s/eloquent-
spence-d51td?file=/src/App...](https://codesandbox.io/s/eloquent-
spence-d51td?file=/src/App.tsx)

in Qt or one of the "old school" desktop tools as quickly as I just did in a
few minutes, that loads data from the web (mock) and displays them in this way
(and has this level of flexibility for further development). There's just no
way.

~~~
detaro
Hows the code in that link fundamentally different from what you'd write in
e.g. Qt's QML?

~~~
realharo
One difference is that you can just use data directly as it comes from the net
(or combine it with any other data in your application).

You don't have to wrap it in models like this [https://doc.qt.io/qt-5/qtquick-
modelviewsdata-modelview.html](https://doc.qt.io/qt-5/qtquick-modelviewsdata-
modelview.html) and then either recalculate that when the data changes or have
a custom model class that does it. Though granted that is still a huge
improvement over doing this in regular Qt Widgets (see the star example a few
comments above), or one of the "old school" desktop GUI builders. This
difference would be felt even more if the items also had some interactivity
with state (e.g. expanded/collapsed things in them, lazy loaded extra info
etc.)

One consequence of the way rendering works is that I can just use language-
native constructs like `if` or the ternary operator to either include or not
include the "Top poster" line in the example. Instead of having to do
something like this
[https://stackoverflow.com/questions/27695717/conditionally-i...](https://stackoverflow.com/questions/27695717/conditionally-
include-component-based-on-property-value). Similarly, you can use map/filter
on arrays, transform the data more easily before rendering it, etc.

Another difference is that JS/TS is the main language of the entire app, not a
separate DSL that you can use for some parts and not for others. You can use
async/await, have the entire npm ecosystem available, etc.

Though QML is still hell of a lot better in this regard than old school VB or
Delphi used to be.

------
grawprog
Cool. This seems like it would be really helpful for building libraries for
other languages to enable native android programming in a variety of
languages.

I know D's not the most popular language on here, but I know HN has a few D
enthusiasts and Walter Bright hangs out here, but my first thought was this

[https://wiki.dlang.org/Build_D_for_Android](https://wiki.dlang.org/Build_D_for_Android)

I've tried to cross compile D apps for android and it was a hassle, I never
really got it to work properly.

Would something like this project help efforts in that direction? Writing
wrappers around C libraries in D is fairly painless comparatively.

------
akavel
I'm working on a somewhat similar development, where I however wrote an actual
assembler for .dex (Dalvik bytecode) files, which gives access to all the
Android APIs and allows defining your own subclasses (e.g. new GUI components
etc.) For example, I can drive a regular SurfaceView in a multithreaded way. I
plan to speak about it on the upcoming Online Nim Conference on Jun 6. You can
see a "teaser" that is an old version of the project (initial PoC) here:
[https://forum.nim-lang.org/t/4840](https://forum.nim-lang.org/t/4840)

------
solarkraft
I'm a huge CNLor fan.

My favorites are the WiFi signal strength mapping (it quite shaped my
understanding of RF communication) and ColorChord. No! Euclid! (which has hot
reloading in C!), glass PCBs and oscilloscope images through a VGA port (along
with all the ESP8266 stuff) are also great.

If you like Applied Science you'll like this dude.

I highly recommend you to check out his YouTube channel:
[https://www.youtube.com/channel/UCG7yIWtVwcENg_ZS-
nahg5g](https://www.youtube.com/channel/UCG7yIWtVwcENg_ZS-nahg5g)

------
mrb
Real life example of Android app weighting 31 kB:
[https://play.google.com/store/apps/details?id=jp.rallwell.si...](https://play.google.com/store/apps/details?id=jp.rallwell.siriuth.touchscreentest)

No idea what framework the author used to accomplish that.

~~~
gridlockd
You don't need a framework, you can just use the interfaces directly. You
know, like a framework.

------
saagarjha
Related: [https://stackoverflow.com/questions/10289890/how-to-write-
io...](https://stackoverflow.com/questions/10289890/how-to-write-ios-app-
purely-in-c)

------
matheusmoreira
> A little bit of this also has to do to stick it to all those luddites people
> on the internet who post "that's impossible" or "you're doing it wrong" to
> Stack Overflow questions...

> Requesting permissions in the JNI "oh you have to do that in Java" or other
> dumb stuff like that.

> If you want a bunch of examples of how to do a ton of things in C on Android
> that you "need" java for, scroll to the bottom of this file:

>
> [https://github.com/cntools/rawdraw/blob/master/CNFGEGLDriver...](https://github.com/cntools/rawdraw/blob/master/CNFGEGLDriver.c)

> it shows how to use the JNI to marshall a ton of stuff to/from the Android
> API without needing to jump back into Java/Kotlin land.

I respect this attitude but it's wrong to say Java isn't being used or
executed. The truth is Java code is being called from C.

    
    
      jclass ClassActivity = env->FindClass(envptr, "android/app/Activity");
      jmethodID MethodrequestPermissions = env->GetMethodID(envptr, ClassActivity, "requestPermissions", "([Ljava/lang/String;I)V");
      env->CallVoidMethod(envptr, activity, MethodrequestPermissions, perm_array, 0);
    

This code directly interfaces with the Java virtual machine. It obtains a
handle to a Java class and a handle to one of its methods. Then it instructs
the virtual machine to invoke the method with parameters supplied by code
written in C.

I searched the repository for JavaVM and JNI_CreateJavaVM and got no results.
So this code is being dynamically loaded by a pre-existing Java virtual
machine at runtime.

~~~
411111111111111
> _I respect this attitude but it 's wrong to say Java isn't being used or
> executed. The truth is Java code is being called from C._

He isn't wrong, because he didn't say that.

It's admittedly very close to that, but not quiet.

You just don't have to use Java to ask for permission. If that ultimately
still executes Java code... Well, he didn't say.

~~~
matheusmoreira
The author wrote:

> it shows how to use the JNI to marshall a ton of stuff to/from the Android
> API _without needing to jump back into Java /Kotlin land_

The C code "jumps back into Java/Kotlin land" when it calls the CallVoidMethod
function.

~~~
foota
I think the point is that the marshalling is done in C, and calls into Java,
but the marshalling itself isn't done in Java.

------
esamatti
I wonder if the same method could be used to write Android Apps only with
Rust?

------
musicale
Someone should invent a mobile platform where you can just write apps in
natively compiled C/C++/ObjC.

You know, kind of like the old Palm, WebOS, or iPhone platforms.

~~~
flukus
That's basically the Librem 5
([https://puri.sm/products/librem-5/](https://puri.sm/products/librem-5/)) and
to me the most exciting thing about it.

~~~
gridlockd
The sad part is that since mobile development has now drifted so far away from
that ideal, porting existing iOS/Android applications to the Librem isn't
trivial.

You could of course have an Android runtime on the Librem...

~~~
flukus
That's a good fallback for everyone's $ANDROID_APP that can't live without.
But for the most part I'd be fine with not having that tire fire ported
anyway, those apps are likely to be slow, suck battery and not conform at all
to the native look and feel.

------
bla3
Here's how to do this if you also want to have parts in Java:
[https://www.hanshq.net/command-line-
android.html](https://www.hanshq.net/command-line-android.html)

------
Ui1ahcex
That's awesome :)

I'm not sure I'm going to use it, though, as it still requires to install a
lot of android stuff on the development computer.

Something I find to work well to make apps for myself on my phone without
requiring the android ndk : using termux. I have installed nginx within it,
then I write react apps that I load in my mobile browser and they make http
request to golang apps that run in termux as well. The first time I
experimented with that, I thought it would drain my battery, but it turns out
I don't see any difference (I don't use a database, though, my apps work with
files).

~~~
jniedrauer
Is there a reason you use nginx instead of serving the frontend using a Go
static fileserver?

~~~
Ui1ahcex
Only contextual reasons : I have already nginx to serve a few backend-less
react apps and static files, so this was less code to write.

------
fredsanford
Oh how I wished for something like this about 5 years ago...

If I ever get over that experience I know where I'll start anew.

------
haberman
Looks to be based on
[https://github.com/cntools/rawdraw](https://github.com/cntools/rawdraw),
"CN's Fundamental Graphics Library", though I don't know who CN is.

~~~
synackrst
That's by the same author (CNLohr), but in an organization rather than a
personal account.

------
Mizza
This. Rocks.

I quit mobile development after too many Java-induced meltdowns. This just
renewed my interest in it.

Quick ideas: \- Demoscene potential!! \- Needs a C-based Android UI lib! \-
Musical potential! VCV Rack for Android?! \- Great for ports!

------
valera_rozuvan
Having the possibility to write C and have it run on embedded hardware - it
feels extremely empowering. Because the usual way (as intended by mobile
architecture developers) of writing mobile apps introduces some overhead.

Also, this project allows for the slow introduction of the vast C ecosystem
(libraries, frameworks) to the Android landscape. Just think of all the
possibilities!

------
andoma
I've been building a native-only Android app for testing various aspects of a
cross-platform (ie, Android and iOS) library we use at dayjob. Building and
running with Makefile feels so liberating and is so d*mn fast compared to the
Android Studio and Gradle molasses. Can recommend.

------
kragen
This is really inspiring! Would an app built this way have problems getting
approved for F-Droid?

------
ZoomZoomZoom
That's super cool. Would love to see someone using this as a base for KOReader
(essential app, in my book) which has an unusual architecture for android,
being written mostly in lua.

Would this permit to compile the APK for ancient android versions, like 2.1?

------
marco_craveiro
Very interesting! On this topic, there is also Boden [1] - though it has been
a little bit quiet of late...

[1]
[https://github.com/AshampooSystems/boden](https://github.com/AshampooSystems/boden)

------
emilfihlman
This seems super interesting! I've long been saddened at the requirement of
Java to write applications for Android and now it's fixed! This should allow
lots of interesting (art)projects and whatnot!

------
winrid
Very cool! But you can write apps in Java and not have big apk sizes... I have
a pretty well optimized collaborative drawing pixel art app on the marketplace
and it's < 8mb last I checked.

~~~
Lerc
To provide perspective, there was a time when people joked that EMACS stood
for Eight Megabytes Always Constantly Swapping.

Big is a notion that has changed over the years. Comparing to what I did on my
2.5 megabyte Amiga, I feel like more should be done with less.

~~~
psanford
As a funny aside, I built the emacs-native branch for the first time this week
and I had to upgrade from 16GB to 32GB of ram for the build process to not run
out of memory.

~~~
iib
Do you know if not having enough RAM would result in segmentation faults
during the build process? Or how exactly does it manifest? I have way less
than 16 GB and when I tried to compile it a week ago, it segfaulted during the
build, but I am unsure of the causes.

~~~
pantalaimon
On Linux if you run out of memory the OOM killer tries to find the process
consuming the most RAM and kills it.

Unfriendly it’s not always triggered fast enough, so your system might lock up
slowing to a crawl swapping before it gets a chance to run.

You’ll find a message about it in dmesg

------
1602
It would be interesting to know how to make something like that integrated
with sensors and services OS offers: activity detection, geolocation,
foreground tasks, scheduled alarms, etc.

~~~
gridlockd
With some exceptions, "you have to do it in Java" or "use JNI" sadly is still
the correct answer.

------
fulafel
Any experiences of building Android apps by just generating code from your
favourite productive language on the desktop? Any ideas if this would be a
better target than Java for that?

------
Snelius
Yes, it's possible of course. But we need to make "native" android GUI which
entire JAVA framework. :(

------
DroitThemes
Great article

