Hacker News Reader

Comment by Semaphor | Hacker News Reader

Tangent

> Hopefully you aren’t relying on any abandoned software.

Every major Android update, I get scared. I use an alarm clock (Gentle Alarm) that has far more features than all others, but it’s been long abandoned (as in: removed from the play store, all websites dead. This was a paid app). Android 10 or 11 already broke it, but someone on reddit (where all 4 or so users of the app met :D) found a manifest change and allowing "drawing over other apps" to fix it.

Now it works on 12, but after I already spent hours asking on HN and Reddit for a maintained replacement and testing those, I hope this continues, because with how lacking all others are I’d rather learn Android development and program my own replacement than using something else.

edit: Hah! The thread [0] with the fixed APK is still getting comments from people who found it every few months :D

[0]: https://old.reddit.com/r/androidapps/comments/i01xh3/gentle_...

View on HN

This is a problem with how we treat backwards compatibility on mobile operating systems. Imagine if this was an app for Windows. Would you still be scared of updating?

This is why no one ever pays more than a couple bucks for a mobile app. That would be a terrible investment, as the app could break at any time!

Similarly, this is why mobile will never be a good platform for traditional single-player video games.

Very true. Apple has removed several of my games (all working perfectly fine) because, well, they felt like it:

> Since this app hasn’t been updated within the last three years [...] it has been removed from the App Store

I hate this. I don't think it's the right approach to improving search and discoverability in the app store. (My personal suggestion for instantly improving it 100% would be removing ads that eat up the first half-screen of search results on an iPhone.)

I also greatly dislike how iOS takes the backwards approach of offloading backward compatibility as a yearly support burden multiplied across every developer - rather than maintaining it in the OS.

Platforms are supposed to absorb developer pain for multiplicative benefit - not the other way around.

As a developer I’m not sure that I agree. Some degree of backwards compatibility is good, but it quickly becomes an unwieldy burden that acts as a ball and chain on the development of the OS and platform toolkit.

Among modern operating systems, iOS is probably the worst in terms of backwards compatibility but it’s also one of the most pleasant to develop for — UIKit/Cocoa is unrivaled in terms of both breadth and depth. One can easily build a top class iOS app with few or no third party dependencies, which is not the case on most other platforms. I don’t think that’s a coincidence… if the iOS dev team were encumbered with maintaining backwards compatibility for upwards of a decade it would be much more difficult to build such a complete and polished toolkit.

If iOS had versioned libraries and separate teams maintaining the older branches, would that really impede the modern toolkit? I realize that expanding the scope of a project by adding more developers isn't as simple as it seems, but I feel like there ought to be an organizational/development structure that could make this work.

I wouldn't even be opposed to older apps running in some sort of seamless-to-the-user virtual machine.

Yeah this is insane. I bought Sonic CD and Sim Tower for iOS years ago and they're both just completely gone. Not listed, impossible to install. I'm never buying a mobile game again.

It blows my goddamn mind.

Android's backwards compatibility, especially for apps that don't update, is quite solid. The cases where previously working behavior is broken without requiring the app to "opt-in" to the breakage is generally scoped solely to things that are considered abuse vectors. Which "draws over other apps" unfortunately is.

It's not as good as Windows' back compat, no. But then again nothing is, as that's the only platform concerned with preserving not just API compatibility but bug compatibility.

There's one case I know of where previously working behavior is broken, for something which was not an abuse vector at all: if your app depends on the hardware "menu" button (which is the case for nearly all apps made back when having a hardware "menu" button was standard for Android), for several versions Android showed an emulated software "menu" button next to the back/home/etc buttons, but more recent Android versions no longer show that button, breaking all these apps (since there's no way to get to their menu). See https://www.xda-developers.com/rip-menu-button-android-10-dr... for details.

Android's backwards compatibility is atrocious with a capital A.

Every version has random will-be-breaking changes that get held off if your app was compiled before said version came out, but there's only a release or two before the change starts to ignore your compiled version (for example, when a massive permissions change comes down the pipe, any app that's compiled against the newest SDK breaks immediately, and apps that were compiled against older ones just get to break next release)

And just like any mobile platform, apps heavily rely on the OS to provide UI widgets and layout. So even design language changes can (and often do) break the UI.

What you're probably seeing is what developers are forced to work around: the fact that everyone is stuck targeting ancient versions of Android because Android users have just accepted their devices never getting OS upgrades.

Android Studio will still default to targeting a minimum SDK version of API 25. Android 5.0. From November 12 2014.

The situation is so bad that Google removed it from their dashboard (https://developer.android.com/about/dashboards) and buried it in the IDE: https://9to5google.com/2022/05/20/android-2022-distribution-...

Nearly a third of Android devices are on a version of Android >5 years old... just imagine if all your iOS apps had to target iOS 11 as a minimum feature set, and XCode defaulted to supporting iOS 8 for all new projects

When the apps can't rely on any newer features, it creates the illusion of backwards compatibility.

Uhh... Like all of that is wrong. Android Studio defaults to targeting the latest API level, and Play Store even refuses to let you upload an APK targeting something more than a couple APIs old. You're regularly confusing target API with min API. Those are very different things. And compiled SDK version is yet something else.

And the rest of your rant is about developers updating their app needing to track changes. That's an unrelated discussion. We're talking about backwards compatibility for apps that don't update. Meaning compile SDK & target API aren't changing. Android keeps those working quite well.

> So even design language changes can (and often do) break the UI.

Nonsense. The platform widgets are governed by the theme which almost never changes. Old apps that don't get updated will still be depending on Theme.Holo which is still there, still unchanging.

And most apps are primarily not using platform widgets anyway, they're using Jetpack instead. Things like RecyclerView, MotionLayout, ConstraintLayout, CardView, etc.. are not in the platform, they're in jetpack. Which is a static library bundled into the APK. And therefore obviously not changing with an OS update

I'm something of a career Android guy so I can do better than point out how you're wrong, I can explain how you're wrong too :)

> Android Studio defaults to targeting the latest API level

Whoops, you confused compileSdkVersion, targetSdkVersion, and minimumSdkVersion (I even mention targetSdkVersion separately as "compiled against")

You (wrongly) thought I was talking about targetSdkVersion (which often doesn't match compileSdkVersion on new releases because... targetSdkVersion lets you duck those breaking changes! That's why Google usually gives about a year before any given compileSdkVersion requirement [latest release] is graduated to a targetSdkVersion requirement).

I mean, read what I wrote again: "targeting a minimum SDK version of API 25".

Min SDK is still defaulted to selecting Lollipop in AS Dolphin which hit full release just this month, and when you ask AS for help it specifically highlights API 25. Try it yourself :)

> And the rest of your rant is about developers updating their app needing to track changes. That's an unrelated discussion. We're talking about backwards compatibility for apps that don't update. Meaning compile SDK & target API aren't changing. Android keeps those working quite well.

You didn't understand the conversation so you failed to follow the connection. I'm saying that Android doesn't do backwards compatibility well, but it doesn't need to since everyone is actively going out of their way to support old versions.

That's why any moderately long lived Android codebase will be full of:

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.XXX) useOldPermission/Flag/Type else useNewPermission/Flag/Type

> Nonsense. The platform widgets are governed by the theme which almost never changes. Old apps that don't get updated will still be depending on Theme.Holo which is still there, still unchanging.

Forget OS version, the theme changes per device manufacturer! There've been cases of manufacturers redefining constants like android.R.color.black to be something completely different than black! That's why you can't rely on android.R for anything

> And most apps are primarily not using platform widgets anyway, they're using Jetpack instead. Things like RecyclerView, MotionLayout, ConstraintLayout, CardView, etc.. are not in the platform, they're in jetpack.

You failed to realize that the part of Jetpack they're using the most is a library literally called AppCompat. You know why it's called that?

It try (and sometimes fail) to wrap dozens of versions worth of incompatibilities, bugs, breaking changes, and missing implementations in the user space (app)!

It's a literal ode to my entire point, that Android *the OS* has never done backwards compatibility well, so developers *in userspace* end up putting a *ton* off work into glossing it over!

Imagine if on iOS you couldn't just make a UITextView, you had to use a wrapper around a UITextView because iOS 8 was still a valid target for many apps and any new feature for the UITextView in the OS had to be simultaneously back ported to iOS 8...

Just the other day I observed a case where the Jetpack Cardview worked on API 32 but broke on API 25 because on API 32 the library falls back to the built-in from the OS... Well it turns out the AppCompat implementation just randomly breaks if the radius of a corner is greater than View.height / 2. The OS implementation handles that gracefully.

That's why any half-serious development team ends up needing to run their apps on all those versions of Android (or just unwittingly lives the life of one of those randomly poorly behaving apps in the wild)

Like if you just slow your roll and read what I said, it shouldn't be controversial to any serious Android developer.

You said it yourself... Android has reached the point where basic UI development is literally built on a ball of strategies to work around the atrocious backwards compatibility situation via AppCompat and other libraries in Jetpack... do you realize that's not normal or indicative of an OS with good backwards compatibility? It's an utterly bizarre corner that Google backed themselves into and are aching for outs on

Preach brother. More people need to know about this insanity outside /r/mAndroidDev .

> I'm saying that Android doesn't do backwards compatibility well, but it doesn't need to since everyone is actively going out of their way to support old versions.

Which is not relevant to the discussion. The discussion is about apps that aren't updated. Android doesn't break those. Developers targeting previous releases is a wholly unrelated issue.

> AppCompat. You know why it's called that?

Because it provides compatibility for new APIs on older platforms. You seem to be completely lost on what backwards compatibile means.

It means old binaries/APIs work on new releases. Which it does on Android quite well. It does not mean that new APIs magically work on old releases. Which is the problem jetpack/appcompat is targeting, and is the entirety of your rant.

> android.R.color.black to be something completely different than black! That's why you can't rely on android.R for anything

And yet everyone does rely on android.R, because those color redefine issues are vanishingly rare.

There's also entire CTS suites that verify oems don't modify theme.holo and theme.material. which is why everyone inherits from those, and don't have problems with it

> Which is not relevant to the discussion. The discussion is about apps that aren't updated. Android doesn't break those. Developers targeting previous releases is a wholly unrelated issue.

No, it is the discussion. If you rely on the OS and lean into new features, many updates will break your app, and in fact many devices on the same OS version will break it!

But there's a massive reluctance to rely on anything but the lowest common denominator of functionality in your apps, so there is outwardly an impression of backwards compatibility.

Seriously, you're talking about backwards compatibility when Android can barely do sideways compatibility, the mind boggles.

> And yet everyone does rely on android.R, because those color redefine issues are vanishingly rare.

Well I guess I'm referring to a certain level of experience... so just call it a code smell.

You get Lint warnings for not fully qualifying any use of it since it's usually not what you want.

Those of us who've needed to support enough apps realize it's really not that rare for random android.R overrides to exist in things like animations, and especially if you have a global footprint. So we just take 5 seconds to define ourpackage.R.color.black or ourpackage.R.anim.fade_in

> There's also entire CTS suites that verify oems don't modify theme.holo and theme.material. which is why everyone inherits from those, and don't have problems with it

No... they inherit from AppCompat wrappers on those because there are many subtle breaking changes between versions.

You're clearly not making the logical connection conveyed here, and I don't think there's anything wrong with accepting that.

No one will completely understand or agree with everything they read, but clearly others are able to make the link, and I think I've gone out of my way enough explaining the link, but you're completely stuck at the first step convinced that someone who's dealt with backwards compatibility for a very long time doesn't know what it is, instead of opening your mind to comprehending the bigger picture.

So I'll leave it at that :)

But then in the case of Windows we complain that Windows releases in 2022 still have stuff that looks like Windows releases from 2002. Maintaining that backwards compatibility can become a massive pain too.

I've seen several remnants of Android 2.1 or below in my Android phone in settings and dialogues that don't need much maintenance. They're reskinned easier, but they are there!

Those tend to be the most usable parts of recent Windows releases. It comes as a relief to encounter them.

While you're right that Microsoft has a much better track record for backwards compatibility, this isn't just limited to mobile operating systems. See: Apple breaking x86, deprecating OpenGL, switching platforms, disabling drivers, etc.

Most things that actually break on Android break for good reason, in my opinion. I consider giving apps the ability to draw overlays without any kind of permission in a supposedly sandboxed environment a design flaw, for example. I'm more annoyed by their restrictions on dynamic loading but even that still seems to work fine if you avoid the Play Store and set your API targets to a version that triggers the backwards compatibility system.

The recent change to the way uploading to Google Play works (where you have Google sign your apps instead doing it yourself) is the worst change in years, but that's technically a Google change, not an Android change.

Almost all API changes necessary to run old apps are minute. The permission overhaul for Android 6 (interactive permissions for many permissions that were previously granted install-time) requires a few more lines of code to show an error if the user denies a critical permission but it doesn't require a full rewrite.

The consequence is that app devs with some minimal time on their hands can update their apps to work on modern devices quite easily. Only apps that are thrown over the wall and abandoned or created by defunct companies are now broken.

Luckily, decompiling most Android apps is quite trivial. If the app is indeed completely defunct with the company disappearing, one might relatively safely maintain a decompiled fork of the abandonware to make it work on modern platforms.

It's a pain, but not a dissimilar amount of pain to searching working on NoCD cracks for games that require DRM broken on Windows 10. Enthusiasts do it, quite regularly as it turns out!

This is also why I'm in favour of laws about source control for abandonware; if a company doesn't exist anymore and people still use their software, the source code should be opened so customers aren't screwed over. Source escrow isn't unheard of in B2B applications and I don't see why it can't be done for consumer apps.

Re: source code release, it seems like that could get rather messy for anyone using third party source code that isn't open.

Also, right away any sort of law like that would become incredibly nuanced. I have a pacemaker and there's an optional BLE app for it. Security through obscurity is lame, but I'd rather that app's source code not be dumped on the internet if the pacemaker company stops supporting it. The source code wouldn't keep the app going because it is dependent on the cloud, and would only be of value to folk trying to reverse engineer the diagnostic protocol. Personally that sounds like a lot of fun, but it's also hardwired into my heart...

On the other hand, something wired into your heart probably shouldn't rely on a proprietary app from a for-profit company that could drop support at any time...

It is what it is. As far as I know, there aren't any viable open source pacemakers. The existence of pacemakers is a wonderful modern marvel, and for-profit companies made it happen. It's likely $100 in materials, but my insurance probably paid at least $30K for the device and two leads. Considering how much engineering went into building it, I think it's a fair price. I once heard that there's roughly a 2:1 ratio between requirements and lines of code.

BLE strapped to one's heart sounds incredibly dystopic to me for some reason.

Source code for such products shouldn't be a problem because devices like these should definitely come with the necessary signature checks out of the box. Such key material shouldn't be released for anything important to one's health (medical devices, emergency devices, etc.). If you're at risk of having a heart attack when someone beats some kind of app code obfuscation then you're in for a bad time.

The cloud won't save you either. When the company disappears, their domain name expires eventually. Someone malicious could record and analyse API traffic and buy the domain to set up their own evil API server.

There are so many attack vectors for such a setup that I'm worried about how tech-ingrained such crucial devices are.

> I consider giving apps the ability to draw overlays without any kind of permission in a supposedly sandboxed environment a design flaw, for example.

FWIW, Gentle Alarm doesn’t do that :D

It’s not quite clear why giving the permission helps, but without it, the alarm doesn’t go off when the screen is off (it still does if the screen is on and the app in the background).

I think it does, but not in the way you expect it. For the longest time this API was the only reliable way to get anything onto the lock screen of some Android phones. If it didn't use this API, you would need to unlock your phone before you could get to the snooze/dismiss buttons.

I can easily see the dev calling into the API to initialise the alarm dialogue before actually playing the sound (after all, who wants an alarm they can't turn off?) and the API call that used to go through without issue now throwing an exception, killing the wakeup process dead in its tracks. I haven't reversed the APK, or course, but it's a very likely scenario.

I don't think this is how the API is intended to be used, but you can find plenty of stackoverflow answers like https://stackoverflow.com/questions/35327328/android-overlay... that (ab)use the window API. This one: https://stackoverflow.com/questions/46860993/window-over-oth... shows the API change, throwing exceptions on API level 26 (Android 8) that didn't get thrown before.

On modern devices, these old workarounds are usually no longer necessary. There's a separate API which is easier to use for interacting with the lock screen now and the permissions to take over the lock screen have been made harsher. For a maintained app this would mean fewer compatibility hacks, less weird lingering visual artifacts in edge cases and a better alarm. Sadly, with the dev ending their operation, the alarm is probably stuck calling old APIs with limited support now that Android security is tightening. Such a change broke clipboard sync in KDE Connect, for example, except it didn't leave a compatibility workaround for old apps.

I'm in favour of better privacy and security but restricting previously unrestricted APIs is a painful process. I've gone so far as to root my phone to provide the necessary permissions but I don't think I'll be able to do that forever...

Oh, that explanation makes perfect sense, thank you for the background information :)

Probably you should decompile it, instead of starting from scratch.

This is made easier because apps are distributed in bytecode form, and compiled to machine code on installation. The bytecode is retained in the .apk file, IIUC.

I use starfield as screensaver since pretty much first android phones, just keep old APK from few years and it still works

What's so special about that app? So that we know

> When setting the alarm, by default I want to have the option to set it in hours/minutes from now. So instead of setting the alarm for 04:30, I want to tell it to set it in 6h30m from now.

> I need it to allow me to set a time of X minutes during which it gets louder until it reaches the pre-set volume.

> pre-alarm: It’s an alarm that goes off X minutes before your main alarm, at a very low volume, with its own settings of volume, time to reach full volume, media to play, etc.

From my Reddit thread [0] back then. It was the upgrade to 10 that did it.

[0]: https://www.reddit.com/r/androidapps/comments/jvbsuz/looking...

Isn't setting an alarm a distance from now vs a set time called a "timer"?

Technically, I guess? But it behaves exactly like an alarm (it is actually just the input, if it’s 13:00, and I set the alarm-timer for 6h, the app will set an alarm for 19:00, not a 6h countdown).

I use alarms instead of timers for most things because of snooze. For stuff like laundry, this is critical to me because I often will turn off a timer's alert thinking "I'll get to this in a minute" but without snooze I forget until the next morning.

This looks awesome. It's the perfect example of way too many features for a built in app, which is supposed to be used by the general public, but a wonderful fit for a very specific niche that should be addressed by third party.

I feel you and that's why we need more open source software.

Several of those features have subfeatures, and then there are more that I don’t use. It’s exactly my kind of app, one that does everything, and everything well ;)

My favorite Windows apps are the same (MediaMonkey, EmEditor, and DirectoryOpus), paid apps with tons of features, more than I need, but also all that I need.

For your first note, if I ask Siri to "Set an alarm in 6 hours" it does that (yes, I know you're talking about Android, but I assume Google Assistant does the same)

Google Assistant will set an alarm for ${currentTime} + 6 hours in your standard alarm app (can by Google's clock, can be your app of choice). Depending on your app of choice, this can have the effect of polluting your list of alarm presets with one-off alarms that you'd need to delete later.

But the feature in Gentle Alarm works with all its other features, specifically alarm profiles that have different settings depending on what I need at the moment (sleeping alone, sleeping next to my wife, napping).

In addition, I’m already trying to get rid of Alexa, I really don’t want to add another voice assistant.

I have seen release notes about automated fixes Apple themselves for apps in the App Store that haven’t been updated recently.

Reply on news.ycombinator.com