I don't remember the details, but I was struck by the huge size of Gradle. Isn't it just a build tool? Why does it need so many updates?

If targeting Android people should first consider if their app can work as a PWA.

Try and do it. if you run into a deal breaking issue with PWA features, then wrap it in a minimalist app shell.

Best case: everything works on Android and iOS and it's also a website.

Worst case: you will end up doing some platform specific code and dealing with the app stores like you were going to do anyway.

Average Case: everything will work on android and some things will be broken on iOS.

Isn't flutter (especially including the flutter rust bridge), achieving that? You do need Android Studio and XCode installed on your machine but you don't have to interact with them directly.

If only Firefox OS had taken off...

XCode is awful but JetBrains makes the best IDEs. There are people that dislike all IDEs which I disagree with but understand.

VSCode isn't bad but disliking Android Studio just feels like you started with it and didn't want to learn a different tool.

Try give a look at kraken: https://github.com/sal0max/kraken

It's a native Android app (Kotlin) which isn't developed using Android Studio. Gradle only.

Give ReactNative + Expo a try

No, it's not. This year I still had to upgrade all my projects (I do this yearly) and they still broke in a myriad of different ways. Most of them fortunately and perhaps ironically the solution was one Google search away.

I actually _like_ Java, so it's not that I hate Android, but frankly, I have no idea what it is even doing downloading and generating gigabytes of crap with inscrutable huge log files. Most of my applications' Java/GUI parts are no more complex than a hello world -- many times I find it easier to just rewrite them from scratch than even try "upgrading" them using Android Studio.

The Android tooling is basically a textbook definition of oversized enterprisey software. I really wish there was just a frigging (resource) compiler, linker and maybe packer that I could invoke from the command line in simple steps.

Gradle was created by folks that didn't learn the Ant lesson, and only matters thanks to Android.

Had it not been for Android replacing Ant with Gradle, and most folks wouldn't even remember Gradle.

With all due respect, that’s a blatant misunderstanding of gradle (though gradle’s documentation not being clear enough, giving to the spread of this misunderstanding is a fair criticism).

Gradle is not too powerful, it builds a build graph based on the .gradle file, and the building itself happens imperatively — but the actual execution is static, based on that fixed build graph. This configuration is cached and subsequent executions will all refer to this static graph to know what requires rebuilding.

This is the minimum required complexity/generality for a build system that is not “hardcoded” for a given task (e.g. to a degree maven, but cargo, go’s build tool etc all can only compile their respective languages on their own. “Plugins” can let them do more, but at that point plugins have to re-develop all the functionality of a build system - caching and parallelization), and as I mentioned there really are only a handful of tools capable of that.

As for valid criticisms of gradle - it’s API historically experiencing constant breakages, used to be dependent on JDK version (and lagged behind for a long time due to Groovy), which is more or less fixed now with toolchains, and the model not being clear enough for people not wanting to dive deep. E.g. I can count on a single hand how many people knows that doFirst/doLast should be used for the actual task itself, anything else will happen at the config build time which is not what you want.

Gradle is pretty sane, from my backend dev experience. But you indeed can get in a situation when dependencies become slightly incompatible after an attempt to upgrade, and you have to fix your code or juggle version requirements, much like with npm or pip.

Maven (and pretty much every other build tool with the exception of bazel) is not capable enough for such a complex build as is required for android, though. E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts. Gradle can always keeps track of tasks correctly.

Yeah, that feeds back to the tooling issues that the post I was replying to was talking about.

Ideally tools should support, not dictate. For instance, if you were building a simple source only app with no assets, a good tool should be able to be pointed at, say, a main.c file in the directory and be able to use the contents of the directory containing main.c for other required files and work with no special extra configuration. Supporting a structure to keep things clean is great, Imposing one(whether you use the features it offers or not) is poor.

I might take a look at the NDK and see if it can be circumvented.

Yes to both OpenJDK and large size.

>I used to work on it, or at least tried to before giving up in frustration.

Out of interest, what blockers did you encounter using Flutter? For me it was much better than native android in terms of development, but it could depend on the usecase.

AFAIK the sandbox on Android is quite a bit stronger than your run-of-the-mill container (starting with every app running under a different UID[0], apps having very restricted access to the screen buffer[1], et cetera).

But it's not really about sandbox security and file system access. The issue is that the more walls you erect and the tighter you make your sandbox, the harder you will make it for apps to access system resources for legitimate purposes. This is where Android shines as it provides a huge, fine-grained API for apps to access system resources while still making sure they only access what they're allowed to access. On Linux we don't even have that fine-grained an API, let alone the same level of fine-grained control. You either grant an application access to your bluetooth/wifi/… device or you don't.

What's more, all Android apps and their UI have been built around this permission-based system these days. Compare this to Linux where applications still assume they have access to everything by default and you have to work very hard to confine an application while making sure it's still usable and the user is not thrown off by weird error messages.

In other words: The strength of Android (and iOS) is that they built in a tight & fine-grained capability-based system from the get-go and also solved the UI challenges that went along with that. These days, they can count on an entire ecosystem of applications that expect to live (and are usable) in that sandbox.

Regular Linux distributions are lightyears away from that. Personally, I really hope SpectrumOS[2] will make a dent here.

[0]: https://source.android.com/docs/security/app-sandbox

[1]: https://source.android.com/docs/core/permissions/restricted-...

[2]: https://spectrum-os.org/

Feel free to ask questions in the Janet Zulip (link at the bottom of the Janet website's front page) if there's anything you need help with!

Fuchsia has components for running APKs (Android Runner) and Linux binaries (Starnix), but that probably isn't what you meant.

The problem with replacing a UI toolkit - any toolkit - is that any change to the toolkit requires modification of all software, including third-party software. Typically, when an OS wants to provide a new toolkit, they wrap the existing toolkit in new code. For example, on macOS, UIKit wraps AppKit, and on all Apple platforms SwiftUI is a wrapper around AppKit and UIKit (depending on platform). On Windows, every UI toolkit ultimately is creating "windows" as they are understood by USER[0], which creates corresponding objects in CSRSS and/or the NT kernel, which can then be used to draw on or attach to a GPU. The lowest level UI abstraction either OS provides is the objects supported by their oldest toolkit, and the lowest level programming language you can write apps in is whatever can call it.

Linux is a bit different, because it inherits its windowing model from X11. X shipped with no default toolkit and a stable window server protocol that apps could program against directly, in an era where most GUI OSes[1] didn't have 'servers' or 'protocols'. You populated resource files and called the relevant function calls to make things happen, and those function calls became sacrosanct. Even Windows NT couldn't escape this; it still used USER despite USER being years older than NT.

The best you can do is shim the library - write something more lower level than the old junk and then rewrite the old library in terms of the new one. This is what Xwayland does to make X apps work on Wayland; and it's what Apple did (mostly) with Carbon to give a transition path to Mac OS 8/9 apps on OS X. Google could, say, ship a new Android toolkit that doesn't use Java bindings, and then make Android's Java toolkit a shim to the new native toolkit. However, this still means you have to keep the shim around forever, at least unless you want to start having flag dates and cut-offs. For context, Apple didn't kill Carbon until macOS 10.15 Catalina, and if they hadn't refused to ship Carbon on 64-bit Intel, it probably would still be in macOS today.

[0] An interesting consequence of this is that disabling "legacy input" in games turns off the ability to move the application window since all that code is intimately coupled to every app that has to open a top-level (i.e. not a widget) window.

[1] At the time that would be XEROX Star, the Lisa, and the Macintosh

[2] This is also why Apple will never, ever ship an iPad that can run macOS software in any capacity. Even if they were forced to allow root access and everything else macOS can do. The entire point of the iPad is to force software developers to rewrite their apps for touch, and I suspect their original intent was for the Macintosh to go away like the Apple ][ did.

Correct, tl;dr roadkill. I don't mean to be disrespectful, someone anonymous picked a bitter fight about this once. But to your point, its clear there was a larger context that Fuchsia was born from, and the ambitions and commitment to it are greatly different than they were at some previous juncture.

> Interfacing with C from Rust is harder

Sure, harder, but not really all that difficult. Run bindgen over the NDK headers and see what happens. Sure, for ergonomics you'll want to write safe Rust wrappers. After that's done once, it's done.

> Rust has fewer cross-compile targets.

Not really an issue here. Rust supports all the targets Android runs on. Natively, even:

    $ rustup target list | grep android
    aarch64-linux-android
    arm-linux-androideabi
    armv7-linux-androideabi
    i686-linux-android
    thumbv7neon-linux-androideabi
    x86_64-linux-android

In my experience, C <-> Rust works quite well, except when the C API relies too much on macros.

C++ <-> Rust is much more annoying.

Going from Java to C is a good step along the way towards supporting any language capable of calling C functions.

It depends purely on what you’re making.

It would be silly to write low-level software in Java, or high-level software (with exceptions for software which would require a low-level language) in C.

So what you are suggesting seems to be, rewrite android_native_app_glue.c in (say) Zig and compile to the .so? Good, but it would nice to see a proof of concept. Also to see how extensive the work has to be: I am not checking all the tree, but android_native_app_glue has includes itself:

  #include <android/configuration.h>
  #include <android/looper.h>
  #include <android/native_activity.h>

Game engines that we can readily use to code for Android outside the Java and web frameworks? Which ones exactly?

It's not blind rage. I've used them, they're over-engineered crap, like most things Java, especially the abominations made at Apache land. You can't say Make is over-engineered; lacking, maybe, but it does what it's meant to do and not much of anything else.