Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

Post reply on HN
Print view View original

191–200 of 414 posts

Re: Android vendors, don’t kill my app

#191

Post by gambiting »

Abishek_Muthian wrote: post #180
gambiting wrote: post #130

Earlier quoted context omitted.

I mean sure, but at least give me a way to override it. On my OnePlus 5T running Android Pie, the system will keep killing my VPN client when in sleep mode, even though I have selected that I don't want to optimize it under battery usage. With the VPN client restricting all unprotected access, it means that once the phone goes into sleep, I stop getting all notifications for anything because there is no internet conn…

Try selecting 'Lock' for the VPN App from the recent apps section (top right)[1] [1]: https://imgur.com/Bk8jXbJ

Hmmm, I had no idea this was a thing. Will give it a try!

Re: Android vendors, don’t kill my app

#192

Post by bad_user »

sudhirj wrote: post #58

This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start their own serivices and do pretty much whatever they wanted, but this is the unfortunate logical result - apps that agressively kill other apps, installed by the handset manufacturers, to protect users from badly written apps that drain the battery in the servi…

>> "Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks"

iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does.

_Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained.

As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail.

Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps.

_Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc).

There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.

Re: Android vendors, don’t kill my app

#193

Post by anc84 »

CodeWriter23 wrote: post #127
simias wrote: post #73

Earlier quoted context omitted.

Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually? By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privac…

No, it’s the consequence of permitting background tasks at will. Apple took some heat, and there is learning curve associated with doing it their way, but they actually thought it through and created an energy-efficient architecture that addresses common use cases. And apps that don’t fit those use cases - what are they doing with your device?

Can I run XMPP or IRC on an iphone by now or does it still only receive messages when foregrounded?

Re: Android vendors, don’t kill my app

#194

Post by amaccuish »

londons_explore wrote: post #101
kijin wrote: post #42

The default mail app on my recent-ish Samsung flagship phone notifies me of new email anywhere from 30 minutes to 1 hour late. I used to depend on K9 Mail for business on the go, but it was even worse: notifications were often several hours late. Android was dropping the IMAP connection and not allowing the app to reconnect for a routine poll. There doesn't seem to be any general-purpose email app on Android that can…

The social media apps will almost certainly use Googles push notification service, which is the only background notification allowed. Your imap client is trying to hold a TCP connection open to your server, which isn't allowed. There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of…

In fairness an exception is made for ActiveSync. I wonder how that is handled at the OS level.

Re: Android vendors, don’t kill my app

#195

Post by Nursie »

GeneralTspoon wrote: post #184
Nursie wrote: post #106

Earlier quoted context omitted.

God save us from beacon-related functionality anyway. No I don't want my day interrupted for a message about your service, sorry!

In that case you wouldn’t opt-in to beacon notifications. But there are many people with varying use-cases - some of whome want reliable BLE detections on their devices. And if they opt-in to these notifications, then it’s a shitty experience when it doesn’t actually work as intended.

> In that case you wouldn’t opt-in to beacon notifications.

Never have, got 'location related alerts' a few times before I figured out how to switch them all off, without ever having opted in.

To be fair I have no idea if these were BLE related, but they were annoying.

Re: Android vendors, don’t kill my app

#196

Post by BoorishBears »

ecocentrik wrote: post #161
Wintamute wrote: post #136

Earlier quoted context omitted.

Auto-killing apps to save battery is obviously good - nobody is contesting that. The bad thing that is being highlighted here is that there's no user friendly way for app developers to request additional privileges from the user.

If you're looking for user friendly ways to request privileges, that solution should really be offered by core android in a way that works for manufacturers and users and probably won't appease all developers. App permissions systems have been a nightmare for users from the start so you can't expect users to learn a newly revamped permissions system. They'll just continue to ignore permissions on install and complain…

What?

The system you’re saying “evolved out of the manufacturers”, runtime permission requests, is from “core Android” all they way back at 6.0

And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions.

The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.

And Android already has built in “active” battery management with Doze, if anything manufacturers are ruining it with poorly coded “optimizers” that do dumb things like kill their own alarm apps...

And even if Android did add a permission to allow an app to do whatever it wants in the background and kill the battery as much as it wants, manufacturers can’t be bothered to write optimizers that don’t kill a music playing app while the user listens to music, why would they bother respecting a permission they didn’t make?

Re: Android vendors, don’t kill my app

#197

Post by morganvachon »

kda26 wrote: post #144
simias wrote: post #73

Earlier quoted context omitted.

Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually? By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privac…

On my phone (android), going to apps>selecting app I want to run in the background>battery>background usage I can allow the app to run unrestricted in the background. All android phones I've owned had this option.

My understanding from the OP website is that this is ineffective for certain popular phone vendors' customizations. In particular, the Nokia phone listed comes preinstalled with an app that aggressively shuts down any running process, whitelisted or not, if the screen has been off for 20 minutes. There's simply no way to stop this behavior apart from gaining root and uninstalling the battery "saving" app, or flashing a stock Android image that doesn't contain it.

Re: Android vendors, don’t kill my app

#198

Post by Nursie »

kijin wrote: post #186
Nursie wrote: post #83

Earlier quoted context omitted.

> Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually? I don't think this is true in the later releases is it? I get a lot more ad-hoc permission requests these days, and there's much more control in the application settings (the android app settings, not the settings the app presents).

It is true to some extent since Marshmellow. But apps can tell when their permissions are denied, so some of them straight out refuse to start unless you give it all the permissions it wants. This is especially problematic when a new version of an app holds your data hostage and refuses to start unless you give it a ridiculous new permission. The Play Store has no requirement that apps degrade gracefully when permiss…

> But apps can tell when their permissions are denied, so some of them straight out refuse to start unless you give it all the permissions it wants.

I'm pretty much fine with this, though the data-hostage situation you describe does seem bad.

You're right that from a user control perspective, the cyanogenmod approach is likely best.

Re: Android vendors, don’t kill my app

#199

Post by morganvachon »

xyzal wrote: post #90

To be honest, as a user I really like the implementation of battery saving features of my Sony phone: 1. They are not enabled by default 2. Their settings screen explicitly states what the modes do 3. They can extend battery life significantly The most aggressive mode is called Ultra Stamina, and it works by basically turning the phone into dumbphone mode -- complete without any internet connectivity, calls, SMS and…

A much better (in my mind) solution to your backpacking battery life issue is to carry a phone with a removable battery. If you're turning off all services including calls and SMS, there's simply no reason for the device to be powered on at all, and removing the battery guarantees there's not even a trickle of power being drained. For your alarm, well I assume you wear a watch backpacking, so you can use its alarm feature.

Of course, then you have the issue of finding a quality midrange or higher end phone with a removable battery in the first place. They are an endangered species due to the thinness war.

Re: Android vendors, don’t kill my app

#200

Post by sudhirj »

bad_user wrote: post #192
sudhirj wrote: post #58

This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start their own serivices and do pretty much whatever they wanted, but this is the unfortunate logical result - apps that agressively kill other apps, installed by the handset manufacturers, to protect users from badly written apps that drain the battery in the servi…

>> " Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks " iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does. _Example 1:_ fetch email (withou…

Example 1 has been solved with Background App Refresh a long time ago [1]

Example 2 should work fine with the background mode declared [2]

Both these APIs are pretty old... is there something I'm missing?

[1] https://developer.apple.com/documentation/uikit/core_app/man...

[2] https://developer.apple.com/documentation/foundation/url_loa...

Post reply on HN