Hacker News new | past | comments | ask | show | jobs | submit login

That might be good for power users, but for the average user it's a disaster. How many people actually read the app permissions when they install something? Most apps request background privileges and if you don't like that your only other option (until recently) was to not install the app.

Users blame Android when Facebook and other popular apps started eating all their battery by running in the background. Google's only choice was to aggressively punish these apps.

All developers think their app is the most important thing running on the user's system, and that is how we get into situations like this.




Yeah I understand why we're in this situation. I'm lamenting the fact that it's reached this point. Maybe I'm a minority but I don't think my apps are the hottest shit around and I try to make an effort to be a good steward. IMO engineers should push back when product asks for things that clobber system resources. However the few bad examples should not ruin it for the use cases where you really do need something running in the background. I also partly blame these DI solutions that encourage devs to stuff everything in a graph they do or don't realize is tied to their application instance. I've seen this multiple times in production apps.


What are these apps doing in the background? I've always assumed they're collecting/streaming device and user metrics. Running apps, location, WiFi SSIDs, etc. If that's the case, then a reduction in data collection could mean a reduction in metrics/income.


Its a mix of things.

Android by design leave apps in the background when you exit them via the home button.

Before 4.0 introduced the switcher button, and the accompanying swipe action to fully close an app, the only way to properly exit an app was to hit the back button until you exited back to the home screen.

This because the initial design of Android was less about apps and more about "activities". These were the individual parts of an app, and what enables that one app launch parts of another app to complete a user action (the most prominent likely being the share menu).

This was presented back in the day as a metaphorical stack of cards. As more user actions where taken that opened more activities, those activities would be added on top of the stack. Then as the user hit the back button he would be flipping backwards in that stack. To enable all this, Android keep apps around in RAM until it runs low, and then start to close down the oldest ones (first by waking them up and telling them to exit gracefully, then forcing them).

Thus often an app will sit in the background even though it is doing nothing.

One good way to observe this (until recently) was to run something like OSMonitor and look at CPU time of various app processes. Often they would be present but basically show no indication of actually doing anything. They would just sit there idle, waiting for user actions.


So make it an opt-in mode, just like sideloading apps.




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

Search: