6 ms·

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 la

by _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.
    - ktosobcy 2y ago
      I use most of the things as pages (miniflux, bluesky) and feel no need to install apps for them....
- 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]

by _bin_ 2y ago

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.
  - ktosobcy 2y ago
    I use most of the things as pages (miniflux, bluesky) and feel no need to install apps for them....
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]