I can tolerate Java and Kotlin, but the tooling is just awful *.

I've stopped counting how many times I came back to an Android project after only a few months, only to have Android Studio force me to update Gradle and dependencies and whatnot, and break everything.

* Of course one could blame me for not learning the ins and outs of the build system!

> The biggest reason I hate doing android development is the java (and to a lesser extent, kotlin) "ecosystem" is a pain.

Wait till you want to build anything reasonable.

All libraries for Android are in Java and/or Kotlin. If you have to write all of them in C then best of luck doing anything meaningful.

What kind of libraries? Anything related to SSO. Anything related to Material design. Anything related to any ancillary services that you want to integrate with e.g. Google services.

Looking at the Flappy Bird post earlier I noted the structure of the repo to be simultaneously elegantly structured and yet still more complex than I would prefer.

The structure is (using [dirname] notation for directories)

    [Repo Root]
        ...git and github files, READMEs...
        [Flappy Bird]
           ... project files, keystore, build.bat ...
           [App]
             [build] 
                 ... I'm ok with tools making a mess here as long as outputs is tidy ...
                 [outputs/apk]    
                    ..the actual .apk
             [src]
                [main]  this seems a little off,  main contains libs and resources 
                   Android_Manifest.xml     Yep ok, I'll rant about that later, that's its own thing
                   [assets]   all good
                   [res] Wait what?  that's like a synonym for assets, (but for a different layer) 
                   [libs] Hang on, these are .so files.  built libs should be in the build dir
                   [jni] This looks like what src or src/main should have had inside it
 

I'd Shuffle it around to make [Flappy Bird] contain [main] and [build]. move [libs] to [build/libs] rename [jni] to [src].

If you had an architecture like that then the one-true-build-system should be a command line tool that you can point at [main] and it does what [Flappy bird]/build.bat does only with auto detection of the installed tools, optional config file overrides, optional commandline overrides.

AndroidManifest is another issue entirely I'd like something that invisibly converted something sane to XML and I'd never see it again, but I'll grin and bear it. A decent validator and maybe I'd like a standalone AndroidManifest editor that knew what everything did and could provide appropriate boilerplate.

After typing this up (mostly as organizing my thoughts), I actually think you could have a relatively painless way to make Android Apps.

Love2D has Android support. It's surprisingly easy to setup: https://github.com/love2d/love-android

...I of course would rather embed Janet [1], but I realize what is going to have an easier time gaining popularity %) Also, Lua has Löve [2] which could be immediately usable, among other things.

[1]: https://janet-lang.org/

[2]: https://www.love2d.org/

That'd require some form of collaborative behavior across internal organizations, and real planning! </s> </disgruntled_xoogler>

I wake up every morning and thank God that Flutter exists. I can target Android without dealing with building on years and years of sloppy work.

Sunk-cost fallacy x politics leads to this never being fixed. I don't think Google can fix it, unless hardware fails entirely. There's been years-long politics that culminated in the hardware org swallowing all the software orgs, and each step along the way involved killing off anything different.

So which other actual alternative should we use for Android development besides Java and webapps.

Obviously the complete and utter crap that gradle/maven are is much better, right?

Zig also much better at memory as far as I can tell. Only reason I found out about it was some random twitch clip I can't remember, but parts of zig seem to be more readable and easier to learn than rust. Granted I will not stop loving the C language even as someone who has only begun to learn C programming but I do recognise the need for secure software.

Check out this blog on zig memory safety: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

(Not my blog, just a blog I found that discusses zig)

Zig is not at 1.0 yet so its a bit behind rust from what iv seen online. One I manage to get C under my belt and get good at writing los level stuff in that language, I might attempt to learn rust or zig.

Any effort to make android more accessible to a C ABI with a simple toolchain can probably also serve as an FFI to other languages.

If works with C why not Rust