Looks like you still have to start by installing Android Studio, which seems excessive. Is there a way to just download an Android SDK?
Looking briefly at the makefile, I think they might have avoided Gradle, though it calls other tools written in Java.
I'd love to see a way to build a Flutter app without Gradle.
> curl -k "https://dl.google.com/android/repository/commandlinetools-li..." -o commandlinetools-linux.zip
unzip somewhere, set path variable
> yes | sdkmanager --licenses && sdkmanager "platform-tools" && sdkmanager "ndk-bundle" && sdkmanager "build-tools;33.0.0" "platforms;android-33"
This is pretty great. The biggest reason I hate doing android development is the java (and to a lesser extent, kotlin) "ecosystem" is a pain. Java is a sucky language to write; Kotlin is less bad, but the whole build tooling/package management/IDE mania mess is still a hassle to use. So thanks to the author.
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!
> only to have Android Studio force me to update Gradle and dependencies and whatnot, and break everything
This. And people are surprised that many just wrap websites as apps on Android.
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.
This really is a good way to go. The majority of apps can be a PWA just fine as long as you don't have to have an app in the Apple app store. If you need push notifications of the specific Apple variety or any other APIs that Apple doesn't think non-native apps should be able to call, then you'll hit some friction as well, but for the most part it's a pleasant delivery strategy.
Even now if I need a "native" app I'm looking very seriously at React Native first before rolling two totally separate apps in different languages.
As an Android dev who use Android Studio for daily work, I confirm updating Gradle may break your projects, well depends on the libraries you used.
In other cases, updating Gradle won't give any problem. You can build the APK fine. Debugging the build system is annoying :D
Same thing with XCode. I'd love a mobile app development pipeline that lets me never use either Android Studio or XCode. Let me drive everything with scripts and/or VSCode extensions.
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.
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.
As someone interested in flutter, when do you have to use XCode and Android Studio?
The only times I’ve had to use Xcode for my flutter app is configuring some things related to signing and distribution. There hasn’t been anything that required Android Studio except for setting up emulators.
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.
If only Firefox OS had taken off...
Gradle/Studio rot is so bad. If you continuously keep up to date it's not so bad, but you're absolutely fucked if you want to open a project from a year ago.
Unfortunately this doesn't actually protect you from that since you still have to deal with that for both the actual "make an APK" step as well as the Java bindings for critical features.
> 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.
This used to be 5-6 years back. These days it is very stable.
Gradle rot really is a pain, at least for Android projects (haven't used it in e.g. serverside stuff).
Proguard is fun too, with how it'll carve out or break chunks of functional code if you don't spell out precisely what shouldn't get deleted/obfuscated.
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.
This is why folks should stick with Maven and live a happy, generally drama-free life.
As a Gradle veteran, I've written in detail about this previously:
https://news.ycombinator.com/item?id=38875936
TL;DR: Gradle is too powerful (which is fun and seems valuable at first!) with too many footguns. Combine this with the mandatory update migrations and you're literally signing up for future pain compared to using a lower change-rate build tool like Maven. Do you really need to run arbitrary commands to build your app? If so, take a deep gaze in the mirror and reflect on what you're doing with your life.
> 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.
The `src` folder is structured that way because the Android NDK demands it. They're not just chosen by convention, but because the build tool searches for those files and subdirectories.
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.
Whenever I need to touch XCode or Android Studio, I'm reminded how lucky web devs are now that almost everything has converged around Vite (death stare at NextJS). Everything Just Works(tm). Simple plugin system to integrate anything.
The few times there wasn't a plugin to do what I needed, I've managed to roll a custom one pretty easily.
When Vite breaks you're completely screwed though. Find a different way to do it or wait until a patch comes out. Vite internals are nigh impossible to fix on your own.
I sincerely Vite would just align with actual web standards rather than throwing in bits and pieces of their own nonsense. It’s precisely why it tends to break in seemingly unfixable ways
May be someone with deep pockets like Elon must get Linux to work on mobile. I know there's efforts going on but seems slow progress. That will break the back of the duopoly and also make things like this so much easier.
Getting Linux running is not the problem. All android phones have a working Linux kernel, and could probably be made to run some kind of Linux based software if you can get through the bootloader hurdles. The issues so far with open source phone stacks are largely around getting all the hardware talking with open source software, battery life, mobile appropriate UIs and finding ways to bring the apps people expect on board.
Now we only need to embed Lua into this to write the high-level logic, and we may have a winner for stuff that does not need a lot of accessibility support. Like, say, games, or media players. Easy to link C libraries that do performance-critical stuff, or writhe your own C code.
(Then gradually rewrite the core in Zig.)
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.
Honestly the whole java/kotlin tooling is the worst to pick for mobile dev, and KEEP it after so many other great languages and tools that are out there. I don’t why google didn’t offer at least Go as a native alternative for android dev.
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.
>I don't think Google can fix it
Can they eventually throw away Android and replace it with Fuchsia? In the reporting about Fuchsia that I read ages ago, it sounded like it was intended to be an Android replacement but, looking into it again just now, it seems more like an embedded OS for other non-smartphone hardware -- maybe with some (aspirational?) claims of utility on smartphones and tablets.
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.
Make? Jesus Christ people are still using that? It's like people don't realize that other languages have been created in the last 20 years
So which other actual alternative should we use for Android development besides Java and webapps.
C++ or Rust? Or Zig? Or D? Kinda pretty much anything else tbh?
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>Quite a few game engines work and don't use Make.
Game engines that we can readily use to code for Android outside the Java and web frameworks? Which ones exactly?
At least Unreal, Unity and Godot but most likely more target Android and iOS as well.
Unreal and Unity both target iOS and Android and are not "java" or "web frameworks"
I am not a fan of Java, but going from Java to C is not an improvement.
Going from Java to C is a good step along the way towards supporting any language capable of calling C functions.
We have WASM/WASI now which is almost certainly going to become the new gold standard of cross language interop.
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.
> It would be silly to write low-level software in Java
Depends on what kind of low-level stuff.
If you're going to nit-pick then at least do us the favor of writing something interesting, like a case where Java was a surprisingly good choice or some interesting libraries.
Yes, of course there are exceptions to every rule. In general, as much as I love the language, Java is not always going to be the best choice.
No, it doesn't.
Java is a piece of crap with JVMs imposing an 8-24 byte overhead per object, which destroys caching, memory footprint, and any chance of low-level optimization. Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable. That, along with lacking SIMD, imposing stupid decisions like bounds checks on all array accesses, making arrays boxed (int[] is not an array of ints, sorry), or using exceptions for control flow, which is the wrong way to use exceptions, is a just part of the big laundry list of why Java is a piece of obsolete crap that nobody serious about low-level hardware programming uses. Java SE/ME is a fucking joke, as is every book I have read about "high performance Java". People who promote Java for low-level hardware programming, real-time systems, and the like, just have absolutely no fucking idea what they're talking about and they get their garbage published only because of the low standards of publishing nowadays. They do get the "Java Champ" badge from Oracle, though. Noobs award other noobs badges, as it turns out.
Obviously the complete and utter crap that gradle/maven are is much better, right?
Yes. Definitely. Ignore your blind rage of Gradle/Maven for a second and realize that they’re literally next iterations of Make.
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.
> I've used them, they're over-engineered crap
Compared to what? And in what way? And then for you to manually recreate it anyway? Like when you need NodeJs, typescript, Turborepo, webpack, babel and a whole list of tools and then you still need scripts to build and deploy?
Yes Maven and Gradle has its problems, but which tool is exactly better? They all just have their pros and cons. Which tool / framework in Go allows you to update a single dependency instead of the 100 that you might need and generates OpenAPI docs for you, etc etc?
Memory corruption, now on Android!
Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety
P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124
P.P.S. The author has a great YT channel with awesome embedded systems projects: https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
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.
Yes, I think Zig is the most suitable language (of Zig, Rust, Go, ...) to replace C in various (systems-related) contexts including embedded/RTOS.
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
Interfacing with C from Rust is harder, and Rust has fewer cross-compile targets.
I'd expect Zig to be an easier deal here, with its zero-impedance interface with C.
In my experience, C <-> Rust works quite well, except when the C API relies too much on macros.
C++ <-> Rust is much more annoying.
Rawdraw operates on everything from an ESP8266, to RaspberryPi, Windows Linux and now, even Android. Write code once, use it everywhere.
That "everything" contains a pretty big gap.