Hacker News Reader

Comment by hlbjhblbljib | Hacker News Reader

> 3. Low target API level (SDK) for client & apps

Yeah well Google fucked up and removed a lot of important API stuff that supported tools.

So I'll continue to use termux from F-Droid. Otherwise I might as well not have a phone.

That's not a sustainable approach as these old APIs will be obsoleted by a future version of Android. The correct approach is to follow modern practices that will guarantee security & privacy. In the case of Termux, they're well aware of the issue: https://github.com/termux/termux-app/issues/2155

This is a similar situation to iOS which has a saner app ecosystem for this reason (in my opinion). That doesn't prevent apps with the same purpose to exist. iSH and a-Shell are examples of that on iOS. UserLAnd on Android takes the proot approach: https://userland.tech/

If you trust Microsoft/GitHub more than F-Droid, you could also grab it from there: https://github.com/termux/termux-app#github (you'll have to take care of your own update mechanism though)

Not that I'd recommend it personally, but f-droid isn't the only option. Kind of the beauty of open source :). So often apps (e.g. from the government for corona) are only available if you first agree to the Google TOS and privacy policy. Which, of course, most people already did anyway, but the point here is that you don't need to if there's just a build from the devs somewhere, or a build environment you can replicate without too much trouble.

Yup. Raising the target SDK means that more phones become ewaste, not because of their hardware becoming outdated, but because their software will never receive an update.

Raising the minimum SDK level might do this. This is separate from the target SDK level.

Raising the target SDK just turns a general computing device into a glorified webbrowser, because you lose access to the filesystem, the ability to run background daemons, and the ability to run compilers.

These should be permissions, not disabled wholesale.

Literally the only situation when an app would need access to your filesystem is when the app is a file manager. And file managers can still request access to your file system.

Not at all. If you want to support e.g. playlists you need to be able to load video files while the storage framework only gives you access to the playlist file.

Or when you want to store and load ROMs from a folder.

Or in general every time you want to automatically load files that should also be accessible to other apps.

Unsure why you think the storage access framework doesn't let you grant access to a directory. You can literally try it on a relatively modern app such as Lemuroid: the system file picker lets you grant access to your ROMs folder.

Whole access to the shared storage is deprecated by SAF and scoped storage. That doesn't mean there is no way to achieve the same productivity tasks you could achieve before: it's just that now you're granting explicit fine-grained access to the files and folders your app needs.

MANAGE_EXTERNAL_STORAGE still exists and is now reserved for apps that can justify their file management purpose. Since this is a highly privacy-invasive permission, Play Store requires a review for these kinds of apps.

Reply on news.ycombinator.com