15 ms·

Rawdrawandroid – Build Android apps without any Java, in C and Make

359 points by doodlesdev 2y ago

_bin_ 2y ago
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.
- tredre3 2y ago
  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!
  - 627467 2y ago
    > 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.
    - gnarbarian 2y ago
      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.
      - freedomben 2y ago
        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.
      - modeless 2y ago
        I shipped a PWA in the Play Store. Guess what? It still got delisted because I didn't update to the latest API level or whatever. Unfortunately you can't just ship a PWA with no wrapper. You have to build a special wrapper app that hosts the PWA and you have to use Android Studio and Gradle and all that crap. Updating the wrapper is surely still easier than a whole app, but it's nontrivial and it's frustrating to still have to deal with the platform BS for a pure web app that uses no platform APIs at all. More work than I wanted to deal with for a hobby project, anyway.
        afavour 2y ago
        > Unfortunately you can't just ship a PWA with no wrapper. You can… but it won’t be in the Play Store. Disqualifying for many, but not all.
        gnarbarian 2y ago
        this is what I do. are you really any more discoverable there? I don't think so.
        modeless 2y ago
        I got a significant number of installs and I didn't do any promotion. People also directly requested an "app" and this satisfies them a lot more than a lecture on the steps to install a PWA.
  - jwells89 2y ago
    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.
    - nine_k 2y ago
      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.
  - candiddevmike 2y ago
    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.
    - Discordian93 2y ago
      If only Firefox OS had taken off...
    - Larrikin 2y ago
      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.
      - drzaiusx11 2y ago
        Jetbrains makes great stuff, I only wish their remote development story was better. You basically have to run a full headless instance on the remote and since it's all java it requires way more ram resources than it should.
    - sprinkly-dust 2y ago
      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.
      - candiddevmike 2y ago
        As someone interested in flutter, when do you have to use XCode and Android Studio?
        cageface 2y ago
        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.
  - kllrnohj 2y ago
    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.
    - kristianp 2y ago
      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?
  - ashishb 2y ago
    > 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.
    - AshamedCaptain 2y ago
      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.
      - ashishb 2y ago
        > 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. Yeah, I feel the same. There are CLI approaches that I have encapsulated into Makefile ( https://ashishb.net/all/use-makefile-for-android https://ashishb.net/all/use-makefile-for-android) and GitHub Actions (https://github.com/ashishb/gabo/blob/master/src/gabo/internal/generator/data/build-android-incomplete.yaml https://github.com/ashishb/gabo/blob/master/src/gabo/interna...) but they do require time to set up.
  - metadat 2y ago
    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 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.
    - kaba0 2y ago
      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.
      - drzaiusx11 2y ago
        Saying Gradle is the minimum possible for a build tool because it generates a dependency graph is a bit of a stretch. Gradle is essentially a custom groovy/kotlin build script dsl in addition to a dependency manager. I just want the latter; leave the former to existing tools. Maven and plug-ins can do the same without learning a new (and brittle) dsl. Worst case in maven you have to write your own plugin, but then you just use their documented plug-in API (import org.apache.maven.plugin) like any other JVM project.
  - anta40 2y ago
    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
  - ktosobcy 2y ago
    Eh... "all hail Gradle" :/ Each time I have to touch it, it results in problems... Oh, you updated JDK? Gradle won't work. There is new Gradle? Tough luck it will break your build.. And with Maven it can update and the build keeps working just fine. To that end I mostly ignore prompt "update gradle!" in Android Studio to avoid any issues...
    - kaba0 2y ago
      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.
      - ktosobcy 2y ago
        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. Maven is virtually infinite extensibility via plugins. The difference is that gradle is easier to "hack" and put the build logic in your configuration... > E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts. This is not build shortcoming but rather detection what requires rebuild and what not but in the worst case scenario it rebuilds everything… > Gradle can always keeps track of tasks correctly. LOL, from my experience that is not true. Also, if you have multiple projects using different gradle version this results in multiple daemons running in the background. Besides gradle builds as as slow as maven...
        kaba0 2y ago
        > Maven is virtually infinite extensibility via plugins Losing the only task of a build tool, caching and parallelization. No, the problem is that maven doesn’t rebuild everything. It is actually quite common in code bases that I had to run clean build instead of build to actually recompile everything that changed. I guess maven just doesn’t have an accurate build graph? > LOL, from my experience that is not true In what way is it not true? Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant. And multiple daemons — you can disable them, and they will go away if unused.
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- Lerc 2y ago
  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 So ignoring the outer layer for the README etc. which isn't needed for an Android app, Just encapsulation for presentation. Arguably the same applies for the next layer too. I feel like the contents of App could be placed in here at no loss. 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.
  - BrS96bVxXBLzf5B 2y ago
    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.
    - Lerc 2y ago
- ashishb 2y ago
  > 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.
- deleted 2y ago
  [deleted]
- rho4 2y ago
  [flagged]
- helpfulContrib 2y ago
  [dead]
smarx007 2y ago
Memory corruption, now on Android! Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety https://safecpp.org/draft.html#the-call-for-memory-safety P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124 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_wbLIXre3sody https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
- asveikau 2y ago
  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.
- fbn79 2y ago
  If works with C why not Rust
  - theyknowitsxmas 2y ago
    [flagged]
  - nine_k 2y ago
    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.
    - Yoric 2y ago
      In my experience, C <-> Rust works quite well, except when the C API relies too much on macros. C++ <-> Rust is much more annoying.
    - kelnos 2y ago
      > 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
rkagerer 2y ago
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.
nine_k 2y ago
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.)
- nine_k 2y ago
  ...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/ https://janet-lang.org/ [2]: https://www.love2d.org/ https://www.love2d.org/
  - kragen 2y ago
    thanks for the link to janet! i hadn't heard of it before. a lot of lua energy even if it's a lot bigger
    - cfiggers 2y ago
      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!
  - MrDrMcCoy 2y ago
    Defold is another great open source Lua-based cross-platform game engine, and has a healthy ecosystem. https://defold.com/ https://defold.com/
- chc4 2y ago
  Love2D has Android support. It's surprisingly easy to setup: https://github.com/love2d/love-android https://github.com/love2d/love-android
- RunSet 2y ago
  SDL can be used to provide something similar to what you describe. https://github.com/libsdl-org/SDL/blob/main/docs/README-android.md https://github.com/libsdl-org/SDL/blob/main/docs/README-andr...
38 2y ago
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
- mdp2021 2y ago
  So which other actual alternative should we use for Android development besides Java and webapps.
  - 38 2y ago
    I am not a fan of Java, but going from Java to C is not an improvement.
    - shepherdjerred 2y ago
      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.
      - wiseowise 2y ago
        > It would be silly to write low-level software in Java Depends on what kind of low-level stuff.
        shepherdjerred 2y ago
        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.
        yazzku 2y ago
        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.
sheeshkebab 2y ago
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.
- refulgentis 2y ago
  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.
  - mohn 2y ago
    >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.
    - kmeisthax 2y ago
      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.
skybrian 2y ago
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.
- MaXtreeM 2y ago
  > curl -k "https://dl.google.com/android/repository/commandlinetools-linux-9123335_latest.zip 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"
  - slimsag 2y ago
    This is better indeed, but from recollection last time I tried this.. I think that still requires a full OpenJDK installation and I believe those `sdkmanager` commands install multiple GB of tools sadly.
    - MaXtreeM 2y ago
      Yes to both OpenJDK and large size.
- flohofwoe 2y ago
  It's possible to build without gradle by calling the sdk tools for bundling and signing directly (for instance from make or cmake), but Android Studio is at least useful for debugging the resulting apk (AS also works as "standalone debugger" for debugging an apk built elsewhere).
- hyperbolablabla 2y ago
  Not sure how useful this is but here's a gist that runs through the process without needing Android Studio: https://gist.github.com/jonnybrooks/13c6cbae832e7d1662e6c1431380d42d https://gist.github.com/jonnybrooks/13c6cbae832e7d1662e6c143...
kopirgan 2y ago
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.
- MobiusHorizons 2y ago
  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.
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- voidUpdate 2y ago
  Already been done https://ubuntu-touch.io/en_GB/ https://ubuntu-touch.io/en_GB/ I ran my main phone on this for a little while and it was definitely an interesting experience
- derjames 2y ago
  Maybe PinePhone or Librem5 are a good start.
- codethief 2y ago
  (I assume by "Linux" you mean a distribution like Arch/Debian/Fedora/Ubuntu/… since, as the sibling says, Android also runs Linux.) > That will break the back of the duopoly and also make things like this so much easier. …and so much less secure by giving every application access to everything in my home dir. No, thank you.
promiseofbeans 2y ago
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.
- mdhb 2y ago
  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
  - codethief 2y ago
    Would you mind elaborating?
roland_nilsson 2y ago
"I can do anything I want. It's just bits. You don't own me." Fair enough! x-D
- tomw1808 2y ago
  "This is computer science. There aren't restrictions." - It's literally what many people forget when they let themselves constraint by frameworks and claim this and that isn't possible. Very refreshing to see how liberating it is if you go one level deeper.
  - RunSet 2y ago
    "We can cause any problem by introducing an extra level of indirection." ;)
- donquichotte 2y ago
  cnlohr is in his own league, this guy is bordering on genius. Dissatisfied with the state of the vendor SDK for CH32V003 microcontrollers (ultra-cheap RISC-V MCUs), he created his own [1], which is a pleasure to use. He also has a header-only RISC-V emulator that runs Linux (and Doom!) [2], and hacked an ESP32 to emit valid LORA frames with clever use of aliasing [3]. [1] https://github.com/cnlohr/ch32v003fun https://github.com/cnlohr/ch32v003fun [2] https://github.com/cnlohr/mini-rv32ima https://github.com/cnlohr/mini-rv32ima [3] https://www.youtube.com/watch?v=eIdHBDSQHyw https://www.youtube.com/watch?v=eIdHBDSQHyw
a-dub 2y ago
to be clear, this is only really useful for applications that present their ui through opengl and do not interact with the rest of the android system very much. the ndk is meant for writing little bits of c to speed things up in a classic java android application. this is a pretty cool hack that allows for opengl apps to be written in straight c that run full screen and have limited access to things like keyboards, adc inputs or usb. it does not include a reimplementation of the android frameworks in c and the ndk provides limited access for ndk code to interact with them. the main use case seems to be supporting a program for live audio reactive visuals based on extraction of chroma.
- mavamaarten 2y ago
  I read that last bit of your comment before I opened the link, and thought to myself, that's something Cnlohr would write. And it is! Hah.
- spookie 2y ago
  To be fair this is the way to not be platform dependent and more people should pursue it. I'm doing a desktop app meant to be as cross compatible as possible and the only reasonable way to do it (without sending yourself into build config hell) is with opengl.
  - marcellus23 2y ago
    How do you make it accessible?
- kllrnohj 2y ago
  > this is a pretty cool hack that allows for opengl apps to be written in straight c that run full screen and have limited access to things like keyboards, adc inputs or usb. It's not even a hack. Android NDK added that way back in like gingerbread, it's just a NativeActivity. https://developer.android.com/ndk/samples/sample_na https://developer.android.com/ndk/samples/sample_na This is just a small framework on top of that. It's not doing anything "new"
  - 2y ago
baudaux 2y ago
I remember when I was developping a cross platform C++/OpenGL ES engine that worked on Android, iOS, Linux, Web… so satisfying
justmarc 2y ago
There should be a lot more high quality, super lightweight, non bloated apps.
- thih9 2y ago
  Unfortunately it’s easier to write a useful app (reliable, bug free, with useful features, etc) using more bloated tech. That translates to the cost. In other words: lightweight, useful, cheap - pick two.
mouse_ 2y ago
This should be integrated into DevkitPro! Would love to see the relatively lightweight msys2 environment building APKs. I know WSL is better but I'm hesitant to use platforms Microsoft is in the process of embracing and extending.
matsemann 2y ago
Given that it's a thin wrapper around GL and friends, could one have an alternate implementation of these calls and do most of the dev work natively on the desktop? And not muck around with devices or emulators except for some final / edge case testing? I just remember working with Libgdx back in the days. A game framework made for Android. It however was cleverly designed in that you could just run it on desktop by changing which implementations were used for drawing/sounds/assets. Very nice to work with, could just recompile the app in seconds and test, even hot swap, compared to the other way of building an apk, installing, launching etc which took minutes per iteration.
- pjmlp 2y ago
  Present tense, LibGDX is still around, even though it isn't Unity or Godot like cool. https://libgdx.com/ https://libgdx.com/
  - matsemann 2y ago
    Yeah, sorry, the past tense was supposed to be my usage of it, which was around 2012-2015. I was quite active, maintaining lots of the documentation, writing guides on how to do stuff. Specifically how to get it running with IntelliJ, as android sdk at the time was eclipse integrated. Also made a simple project on github to show how to do a "loading screen", aka not just freeze while it loads but have a progress bar and interactivity. Somehow it still gets random stars a decade later.
fredgrott 2y ago
You know its funny all the Gradle sucks comments here....I use Flutter which behind the scenes uses Gradle builds for android targets....no Gradle problems whatsoever...maybe operator touching and changing Gradle was the feature and the problem??
peter_retief 2y ago
I was interested but then saw JDK/Gradle. One of the reasons I avoid android development.
pkphilip 2y ago
C is neat but something like python may be simpler to work with for most programmers. I wonder if anyone here has experience with Kivy and KivyMD libraries for python. The code is simple and self explanatory. class RectangleFlatButton(TouchRippleBehavior, Button): primary_color = get_color_from_hex("#EB8933") def on_touch_down(self, touch): collide_point = self.collide_point(touch.x, touch.y) if collide_point: touch.grab(self) self.ripple_show(touch) return True return False def on_touch_up(self, touch): if touch.grab_current is self: touch.ungrab(self) self.ripple_fade() return True return False class MainApp(App): def build(self): screen = Builder.load_string(KV) screen.add_widget( RectangleFlatButton( text="Hello, World", pos_hint={"center_x": 0.5, "center_y": 0.5}, size_hint=(None, None), size=(dp(110), dp(35)), ripple_color=(0.8, 0.8, 0.8, 0.5), ) ) return screen MainApp().run()
- intrepidhero 2y ago
  I built a simple kivy app a few years. Working with kivy and testing on my (linux) dev machine was great. Even side loading to test on my phone using the kivy launcher wasn't too bad. The pain point was that building APKs that the play store would accept was an ordeal and then when they change requirements you have to hope the kivy folks update their build tools in time to recompile with a new version of the NDK before google delists your app.
  - pkphilip 2y ago
    Thank you. Wasn't aware of that.

359 points by doodlesdev 2y ago

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.

tredre3 2y ago
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!
- 627467 2y ago
  > 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.
  - gnarbarian 2y ago
    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.
    - freedomben 2y ago
      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.
    - modeless 2y ago
      I shipped a PWA in the Play Store. Guess what? It still got delisted because I didn't update to the latest API level or whatever. Unfortunately you can't just ship a PWA with no wrapper. You have to build a special wrapper app that hosts the PWA and you have to use Android Studio and Gradle and all that crap. Updating the wrapper is surely still easier than a whole app, but it's nontrivial and it's frustrating to still have to deal with the platform BS for a pure web app that uses no platform APIs at all. More work than I wanted to deal with for a hobby project, anyway.
      - afavour 2y ago
        > Unfortunately you can't just ship a PWA with no wrapper. You can… but it won’t be in the Play Store. Disqualifying for many, but not all.
        gnarbarian 2y ago
        this is what I do. are you really any more discoverable there? I don't think so.
        modeless 2y ago
        I got a significant number of installs and I didn't do any promotion. People also directly requested an "app" and this satisfies them a lot more than a lecture on the steps to install a PWA.
- jwells89 2y ago
  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.
  - nine_k 2y ago
    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.
- candiddevmike 2y ago
  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.
  - Discordian93 2y ago
    If only Firefox OS had taken off...
  - Larrikin 2y ago
    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.
    - drzaiusx11 2y ago
      Jetbrains makes great stuff, I only wish their remote development story was better. You basically have to run a full headless instance on the remote and since it's all java it requires way more ram resources than it should.
  - sprinkly-dust 2y ago
    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.
    - candiddevmike 2y ago
      As someone interested in flutter, when do you have to use XCode and Android Studio?
      - cageface 2y ago
        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.
- kllrnohj 2y ago
  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.
  - kristianp 2y ago
    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?
- ashishb 2y ago
  > 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.
  - AshamedCaptain 2y ago
    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.
    - ashishb 2y ago
      > 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. Yeah, I feel the same. There are CLI approaches that I have encapsulated into Makefile ( https://ashishb.net/all/use-makefile-for-android https://ashishb.net/all/use-makefile-for-android) and GitHub Actions (https://github.com/ashishb/gabo/blob/master/src/gabo/internal/generator/data/build-android-incomplete.yaml https://github.com/ashishb/gabo/blob/master/src/gabo/interna...) but they do require time to set up.
- metadat 2y ago
  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 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.
  - kaba0 2y ago
    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.
    - drzaiusx11 2y ago
      Saying Gradle is the minimum possible for a build tool because it generates a dependency graph is a bit of a stretch. Gradle is essentially a custom groovy/kotlin build script dsl in addition to a dependency manager. I just want the latter; leave the former to existing tools. Maven and plug-ins can do the same without learning a new (and brittle) dsl. Worst case in maven you have to write your own plugin, but then you just use their documented plug-in API (import org.apache.maven.plugin) like any other JVM project.
- anta40 2y ago
  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
- ktosobcy 2y ago
  Eh... "all hail Gradle" :/ Each time I have to touch it, it results in problems... Oh, you updated JDK? Gradle won't work. There is new Gradle? Tough luck it will break your build.. And with Maven it can update and the build keeps working just fine. To that end I mostly ignore prompt "update gradle!" in Android Studio to avoid any issues...
  - kaba0 2y ago
    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.
    - ktosobcy 2y ago
      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. Maven is virtually infinite extensibility via plugins. The difference is that gradle is easier to "hack" and put the build logic in your configuration... > E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts. This is not build shortcoming but rather detection what requires rebuild and what not but in the worst case scenario it rebuilds everything… > Gradle can always keeps track of tasks correctly. LOL, from my experience that is not true. Also, if you have multiple projects using different gradle version this results in multiple daemons running in the background. Besides gradle builds as as slow as maven...
      - kaba0 2y ago
        > Maven is virtually infinite extensibility via plugins Losing the only task of a build tool, caching and parallelization. No, the problem is that maven doesn’t rebuild everything. It is actually quite common in code bases that I had to run clean build instead of build to actually recompile everything that changed. I guess maven just doesn’t have an accurate build graph? > LOL, from my experience that is not true In what way is it not true? Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant. And multiple daemons — you can disable them, and they will go away if unused.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
Lerc 2y ago
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 So ignoring the outer layer for the README etc. which isn't needed for an Android app, Just encapsulation for presentation. Arguably the same applies for the next layer too. I feel like the contents of App could be placed in here at no loss. 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.
- BrS96bVxXBLzf5B 2y ago
  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.
  - Lerc 2y ago
ashishb 2y ago
> 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.
deleted 2y ago
[deleted]
rho4 2y ago
[flagged]
helpfulContrib 2y ago
[dead]

smarx007 2y ago

Memory corruption, now on Android! Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety https://safecpp.org/draft.html#the-call-for-memory-safety P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124 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_wbLIXre3sody https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...

asveikau 2y ago
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.
fbn79 2y ago
If works with C why not Rust
- theyknowitsxmas 2y ago
  [flagged]
- nine_k 2y ago
  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.
  - Yoric 2y ago
    In my experience, C <-> Rust works quite well, except when the C API relies too much on macros. C++ <-> Rust is much more annoying.
  - kelnos 2y ago
    > 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

rkagerer 2y ago

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.

nine_k 2y ago

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.)

nine_k 2y ago
...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/ https://janet-lang.org/ [2]: https://www.love2d.org/ https://www.love2d.org/
- kragen 2y ago
  thanks for the link to janet! i hadn't heard of it before. a lot of lua energy even if it's a lot bigger
  - cfiggers 2y ago
    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!
- MrDrMcCoy 2y ago
  Defold is another great open source Lua-based cross-platform game engine, and has a healthy ecosystem. https://defold.com/ https://defold.com/
chc4 2y ago
Love2D has Android support. It's surprisingly easy to setup: https://github.com/love2d/love-android https://github.com/love2d/love-android
RunSet 2y ago
SDL can be used to provide something similar to what you describe. https://github.com/libsdl-org/SDL/blob/main/docs/README-android.md https://github.com/libsdl-org/SDL/blob/main/docs/README-andr...

38 2y ago

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

mdp2021 2y ago
So which other actual alternative should we use for Android development besides Java and webapps.
- 38 2y ago
  I am not a fan of Java, but going from Java to C is not an improvement.
  - shepherdjerred 2y ago
    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.
    - wiseowise 2y ago
      > It would be silly to write low-level software in Java Depends on what kind of low-level stuff.
      - shepherdjerred 2y ago
        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.
      - yazzku 2y ago
        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.

sheeshkebab 2y ago

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.

refulgentis 2y ago
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.
- mohn 2y ago
  >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.
  - kmeisthax 2y ago
    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.

skybrian 2y ago

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.

MaXtreeM 2y ago
> curl -k "https://dl.google.com/android/repository/commandlinetools-linux-9123335_latest.zip 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"
- slimsag 2y ago
  This is better indeed, but from recollection last time I tried this.. I think that still requires a full OpenJDK installation and I believe those `sdkmanager` commands install multiple GB of tools sadly.
  - MaXtreeM 2y ago
    Yes to both OpenJDK and large size.
flohofwoe 2y ago
It's possible to build without gradle by calling the sdk tools for bundling and signing directly (for instance from make or cmake), but Android Studio is at least useful for debugging the resulting apk (AS also works as "standalone debugger" for debugging an apk built elsewhere).
hyperbolablabla 2y ago
Not sure how useful this is but here's a gist that runs through the process without needing Android Studio: https://gist.github.com/jonnybrooks/13c6cbae832e7d1662e6c1431380d42d https://gist.github.com/jonnybrooks/13c6cbae832e7d1662e6c143...

kopirgan 2y ago

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.

MobiusHorizons 2y ago
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.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
voidUpdate 2y ago
Already been done https://ubuntu-touch.io/en_GB/ https://ubuntu-touch.io/en_GB/ I ran my main phone on this for a little while and it was definitely an interesting experience
derjames 2y ago
Maybe PinePhone or Librem5 are a good start.
codethief 2y ago
(I assume by "Linux" you mean a distribution like Arch/Debian/Fedora/Ubuntu/… since, as the sibling says, Android also runs Linux.) > That will break the back of the duopoly and also make things like this so much easier. …and so much less secure by giving every application access to everything in my home dir. No, thank you.

promiseofbeans 2y ago

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.

mdhb 2y ago
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
- codethief 2y ago
  Would you mind elaborating?

roland_nilsson 2y ago

"I can do anything I want. It's just bits. You don't own me." Fair enough! x-D

tomw1808 2y ago
"This is computer science. There aren't restrictions." - It's literally what many people forget when they let themselves constraint by frameworks and claim this and that isn't possible. Very refreshing to see how liberating it is if you go one level deeper.
- RunSet 2y ago
  "We can cause any problem by introducing an extra level of indirection." ;)
donquichotte 2y ago
cnlohr is in his own league, this guy is bordering on genius. Dissatisfied with the state of the vendor SDK for CH32V003 microcontrollers (ultra-cheap RISC-V MCUs), he created his own [1], which is a pleasure to use. He also has a header-only RISC-V emulator that runs Linux (and Doom!) [2], and hacked an ESP32 to emit valid LORA frames with clever use of aliasing [3]. [1] https://github.com/cnlohr/ch32v003fun https://github.com/cnlohr/ch32v003fun [2] https://github.com/cnlohr/mini-rv32ima https://github.com/cnlohr/mini-rv32ima [3] https://www.youtube.com/watch?v=eIdHBDSQHyw https://www.youtube.com/watch?v=eIdHBDSQHyw

a-dub 2y ago

to be clear, this is only really useful for applications that present their ui through opengl and do not interact with the rest of the android system very much. the ndk is meant for writing little bits of c to speed things up in a classic java android application. this is a pretty cool hack that allows for opengl apps to be written in straight c that run full screen and have limited access to things like keyboards, adc inputs or usb. it does not include a reimplementation of the android frameworks in c and the ndk provides limited access for ndk code to interact with them. the main use case seems to be supporting a program for live audio reactive visuals based on extraction of chroma.

mavamaarten 2y ago
I read that last bit of your comment before I opened the link, and thought to myself, that's something Cnlohr would write. And it is! Hah.
spookie 2y ago
To be fair this is the way to not be platform dependent and more people should pursue it. I'm doing a desktop app meant to be as cross compatible as possible and the only reasonable way to do it (without sending yourself into build config hell) is with opengl.
- marcellus23 2y ago
  How do you make it accessible?
kllrnohj 2y ago
> this is a pretty cool hack that allows for opengl apps to be written in straight c that run full screen and have limited access to things like keyboards, adc inputs or usb. It's not even a hack. Android NDK added that way back in like gingerbread, it's just a NativeActivity. https://developer.android.com/ndk/samples/sample_na https://developer.android.com/ndk/samples/sample_na This is just a small framework on top of that. It's not doing anything "new"
- 2y ago

baudaux 2y ago

I remember when I was developping a cross platform C++/OpenGL ES engine that worked on Android, iOS, Linux, Web… so satisfying

justmarc 2y ago

There should be a lot more high quality, super lightweight, non bloated apps.

thih9 2y ago
Unfortunately it’s easier to write a useful app (reliable, bug free, with useful features, etc) using more bloated tech. That translates to the cost. In other words: lightweight, useful, cheap - pick two.

mouse_ 2y ago

This should be integrated into DevkitPro! Would love to see the relatively lightweight msys2 environment building APKs. I know WSL is better but I'm hesitant to use platforms Microsoft is in the process of embracing and extending.

matsemann 2y ago

Given that it's a thin wrapper around GL and friends, could one have an alternate implementation of these calls and do most of the dev work natively on the desktop? And not muck around with devices or emulators except for some final / edge case testing? I just remember working with Libgdx back in the days. A game framework made for Android. It however was cleverly designed in that you could just run it on desktop by changing which implementations were used for drawing/sounds/assets. Very nice to work with, could just recompile the app in seconds and test, even hot swap, compared to the other way of building an apk, installing, launching etc which took minutes per iteration.

pjmlp 2y ago
Present tense, LibGDX is still around, even though it isn't Unity or Godot like cool. https://libgdx.com/ https://libgdx.com/
- matsemann 2y ago
  Yeah, sorry, the past tense was supposed to be my usage of it, which was around 2012-2015. I was quite active, maintaining lots of the documentation, writing guides on how to do stuff. Specifically how to get it running with IntelliJ, as android sdk at the time was eclipse integrated. Also made a simple project on github to show how to do a "loading screen", aka not just freeze while it loads but have a progress bar and interactivity. Somehow it still gets random stars a decade later.

fredgrott 2y ago

You know its funny all the Gradle sucks comments here....I use Flutter which behind the scenes uses Gradle builds for android targets....no Gradle problems whatsoever...maybe operator touching and changing Gradle was the feature and the problem??

peter_retief 2y ago

I was interested but then saw JDK/Gradle. One of the reasons I avoid android development.

pkphilip 2y ago

C is neat but something like python may be simpler to work with for most programmers. I wonder if anyone here has experience with Kivy and KivyMD libraries for python. The code is simple and self explanatory. class RectangleFlatButton(TouchRippleBehavior, Button): primary_color = get_color_from_hex("#EB8933") def on_touch_down(self, touch): collide_point = self.collide_point(touch.x, touch.y) if collide_point: touch.grab(self) self.ripple_show(touch) return True return False def on_touch_up(self, touch): if touch.grab_current is self: touch.ungrab(self) self.ripple_fade() return True return False class MainApp(App): def build(self): screen = Builder.load_string(KV) screen.add_widget( RectangleFlatButton( text="Hello, World", pos_hint={"center_x": 0.5, "center_y": 0.5}, size_hint=(None, None), size=(dp(110), dp(35)), ripple_color=(0.8, 0.8, 0.8, 0.5), ) ) return screen MainApp().run()

intrepidhero 2y ago
I built a simple kivy app a few years. Working with kivy and testing on my (linux) dev machine was great. Even side loading to test on my phone using the kivy launcher wasn't too bad. The pain point was that building APKs that the play store would accept was an ordeal and then when they change requirements you have to hope the kivy folks update their build tools in time to recompile with a new version of the NDK before google delists your app.
- pkphilip 2y ago
  Thank you. Wasn't aware of that.