Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> He's using ancient APIs. All written in Java with Activities instead of Kotlin with a single Activity and many Fragments.

That doesn't mean it's ancient at all. Java isn't deprecated, and using Fragments instead of Activities is just one possible architectural approach.

I think Google recommends Kotlin now, but that's only been the case for a couple of years or so.

Google's constant demands for changes to how Android apps are configured are very annoying to the developer, but even they're not that bad.



A lot of my analysis is personal and subjective based on 5yoe as a full time Android Dev.

The ancient APIs is using Runnables/Handlers with Tasks more than it is using Java.

The single (or reduced) Activities with many fragments will improve stability.

Kotlin has been the official language of Android for a relatively short period of time, true, but it's entirely interoperable with all Java code, and improves maintainability _significantly_.

The main issue he's facing here is your last sentence: He refused to change how the app was configured. Use of illegal calls (which he helpfully posts the Stack Trace as a comment when it fails) means the app just doesn't work on modern Android without having to manually grant permissions.


> The main issue he's facing here is your last sentence: He refused to change how the app was configured.

I do have a lot of sympathy of for him. I also maintain an app which I provide for free to my users out of altruism.

I don't "refuse" to change how the app is configured, but I don't have time to constantly rewrite it.

Trying to keep up with the Google treadmill of required changes is extremely difficult for someone with a side project (I don't know if FairEmail is full time for its author). Example: I need to rewrite large portions of my app to use scoped storage, but even using the example code from the Google API docs already gets flagged as deprecated.

It might be tolerable if Android is your day job. I guess that's all Google cares about now - apps large enough to be profitable to give them a cut.

Personally I think Android as an O/S should not break userspace.


>Trying to keep up with the Google treadmill of required changes is extremely difficult for someone with a side project (I don't know if FairEmail is full time for its author). Example: I need to rewrite large portions of my app to use scoped storage, but even using the example code from the Google API docs already gets flagged as deprecated.

I mean, I sympathize, but that's sort of the agreement you make if you want to be in the Play Store, right? Like, if you don't have time to maintain your app, that's totally OK -- but at least you have other methods of distributing your app if you want. But if you want to use Google's distribution platform, following their rules for what is and isn't allowed seems fair.


> following their rules for what is and isn't allowed seems fair

It depends on how you look at it. That is literally the deal, yes, but it's a poor deal for developers of free apps.

We make Android's platform more valuable, for free, and in return we have to constantly rewrite our apps because of poorly-thought out policies that keep changing.

The suspicion is that many of these changes are unnecessary and a result of Google's notorious "promotion-driven development".

I think the most annoying aspect of it is that Android changes so often and so fast that they can't even keep their own documentation in sync.


And scoped storage is basically a nuclear bomb. Nvidia is still struggling with it on the Shield/Android TV as it has completely upset the turnip cart in regards to things like Plex Media Server that worked just fine before scoped storage.

Google doesn't care. Change for the sake of change is the name of the game, so apps that aren't maintained professionally are screwed


>Kotlin has been the official language of Android for a relatively short period of time, true, but it's entirely interoperable with all Java code, and improves maintainability _significantly_.

Has the JavaScript culture of rewriting everything every two years purely for the sake of change infected android now too?


Yes, we all exist on treadmills and race the Red Queen nowadays.


It's been that way since at least Android 9




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: