6 ms·

Am I the only one who's really disappointed by the platform's shift in its stance on background execution? I was originally drawn to Android because it wasn't i

by dcow 9y ago

Am I the only one who's really disappointed by the platform's shift in its stance on background execution? I was originally drawn to Android because it wasn't iOS. I wanted to develop on a platform where I could run a service in the background if the user wanted that. Apps that were bad stewards of battery life and phone resources were supposed to be scrutinized by users and removed if they were too poor. You can be a good steward, it's just harder especially when your monolithic app is an uninformed port of some legacy iOS code. By issuing a hard restriction on background usage Google has brilliantly improved battery life for the masses while condonig the same lazy architectural patterns of the past, locked people into Firebase Cloud Messaging--a Google service not part of the AOSP, and potentially stunted Android adoption in domains outside of mobile. It's the turning of an era for Android, and my interests have moved elsewhere (from an app platform perspective, embedded Android is still vialble since everything you ship runs as a system app with no restrictions).

tree_of_item 9y ago
Elsewhere to what? What are you gonna do, run Windows Mobile?
- dcow 9y ago
  I like native app development because it's not a browser. Android was the most honest manifestation of that on mobile (iOS is basically a "client OS"). I look towards domains where people are still putting powerful applications on connected hardware. Mobile is starting to look like a commodity web experience with half the history of JS, so why not just use that?
  - dcow 9y ago
    Point being the delta between what a native app and what a browser app can do has all but disappeared. BT and Graphics are the last few notable things and both will be supported by browsers soon (webgl already is and webbt is incoming). I'm not saying go use JS.. I very much do not enjoy it. Im asking why we need to build native when there's increasingly less to justify the overhead.
    - pjmlp 9y ago
      WebGL is a poor cousin of OpenGL 4.6. Even comparing WebGL 2.0 to OpenGL ES 3.0, which it is based on, there are nice features like geometry shaders missing.
      - fulafel 9y ago
        Nitpick: Geometry shaders came in GLES 3.2 (there was also a geometry shader extension for GLES 3.1). In WebGL 2 you can still do geometry processing, and store results in buffers for subsequent draw calls, using transform feedback.
        pjmlp 9y ago
        You are right, I mixed it up. Like that idea for WebGL 2.0, will have a look into it.
BugsJustFindMe 9y ago
Apps that were bad stewards of battery life and phone resources were supposed to be scrutinized by users If HN allowed emoji in comments, I'd have a U+1F923 here. Since I can't do that, you're adorable. The users, eh? The users are supposed to be burdened with checking the wake status and radio activation schedule of their apps? How was that supposed to work, exactly?
- dcow 9y ago
  I'm not sure what your point is here and your tone indicates you're not really looking for honest discussion. But FYI Android reports energy usage statistics to the user on a per-app basis. What I don't like is Android the platform telling me the user how my phone is best used. It's pretty crippling. Let's say I'm deploying Android on hardware that is always plugged in--something kiosk-style. Why shouldn't I be able to have an app that keep a persistent connection open to a network service for say real-time communication? You can't do that now.
  - digi_owl 9y ago
    And if Android itself didn't tell you enough, there were apps line OSMonitor that could give you more detail (at least until Google shitcanned the permissions that it relied on for "security" reasons).
  - tnone 9y ago
    Blame shitty mobile developers who screwed the pooch on Android. Even if you avoid shovelware, the quality is abysmal. My Android phone still randomly lights up its screen several times a day, without a new notification having come in. Reporting overall energy usage doesn't help me track down the culprit. It's not like anyone's written apps for real work on these devices anyway. It's all just second class software.
  - ihattendorf 9y ago
    And what about the mysterious Android OS/Android System "apps" that show up on the battery usage screen? How do I know which app is hogging resources here? Should we expect users to inspect wakelocks?
klondike_ 9y ago
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.
- dcow 9y ago
  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.
  - nomel 9y ago
    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.
    - digi_owl 9y ago
      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.
avar 9y ago
What part of that page indicates that you can't use the platform like that? They just say "more control over how apps run in the background". Presumably you can still give your users a good reason for why you need to run uninterrupted in the background and they can approve it similarly to how they now approve other permissions.
- dcow 9y ago
  The way this is implemented is that the system will kill any background services your app has after a grace period, just like iOS. In order to have a background service that "good reason" equates to a persistent notification in the tray and icon in the status bar--which nobody agrees is a good product experience.
  - avar 9y ago
    Why is that not a good experience? Now I need to dig through Settings to find all these background services. If they're important enough to be running constantly they're important enough to take up some space to prominently show me that they're running.
    - kuschku 9y ago
      Yes, and you're okay with having 20 to 30 notifications at all times just to run open source apps, or would you say "this is too annoying, I'll switch back to the closed ones that spy on me". If you want the open source products to win, they need to be able to provide the same usability as the proprietary solution. This is not possible here - you need Google's FCM or you get major disadvantages, and this is problematic. I've filed a complaint with the EU, this seems like the only option I've got left. I can't tell everyone running a bouncer to register with Google, I can't relay all messages of all IRC users through a server of mine, and I can't bake in a Google API key into IRC bouncers (as that violates Google's ToS)
      - avar 9y ago
        This doesn't inherently have anything to do with open source, but the problem that whatever license the apps on the phone are under they can't all be implementing their own push/pull message queue, having 30 open network connections constantly waking up the phone is going to drain the battery. If I install 100 apps that have their own messaging implementation should the phone just not be showing that to me, even though my battery is now drained in half the time as a result? I'm pointing out that as a user this is very pertinent info to be showing me, if I have 30 apps running in the background I'd like to see it.
kevincox 9y ago
You can disable "Battery Optimization" per app, so this isn't very restrictive. It just applies by default.
- mjevans 9y ago
  I'd like to do that, but when I 'exit' an app and/or swipe it off of the list of program cards I want it to ACTUALLY exit (at least within 30 seconds).
  - dcow 9y ago
    What if that app is say and open source messenger app that doesn't use GCM/FCM. For that to work you need to maintain a connection with a remote service. You don't need the UI hogging memory the whole time but you definitely want messages to come in immediately. IMO the system should offer a way to completely kill and app but "killing the UI" should not stop critical services utilized by the app. Okay so maybe you could argue that if you never "swipe kill" the app it should be allowed to have background services executing much like e.g. Slack on macOS. But you can't even do that. Having your ui in the recent tasks list does not exempt you from background restriction.
    - dlubarov 9y ago
      There is a way to kill an app process, but it's in Setting and takes several clicks. I think it's for the best that killing isn't easier, because users don't generally know the implications of killing an app. In Square's Register app for example, force killing the process could prevent the app from uploading important payment data in a timely fashion.
    - exadeci 9y ago
      You just don't know much about android dev it seems. When an app gets put in the background it gets an event from the OS it's then the devs job to not keep everything loaded in the background but most don't.
  - kllrnohj 9y ago
catdog 9y ago
At least in Android 7 you can explicitly allow this for a specific app. This question can even be triggered by the app itself (e.g. Conversations and Signal ask you to do this if they can't use GCM). This is hopefully still possible. > It's the turning of an era for Android, and my interests have moved elsewhere (from an app platform perspective, embedded Android is still vialble since everything you ship runs as a system app with no restrictions). Google making it more and more difficult to avoid gapps is nothing new.
- dcow 9y ago
  Can you point me to the relevant info? This is news to me (and sounds exciting). No doubt we've seen it coming for awhile. But I'm still sad to see it finally come to this, at least ideologically. iOS is a closed ecosystem that's been opening up. Android was an open ecosystem that's becoming more locked down.
  - catdog 9y ago
    [1] Seems to do the trick but I don't do Android dev so I don't know any details about this. [1] https://github.com/siacs/Conversations/blob/2b9cdde558ed96c23ca02357b3d9e4f47a80e764/src/main/java/eu/siacs/conversations/ui/ConversationActivity.java#L1500 https://github.com/siacs/Conversations/blob/2b9cdde558ed96c2...
    - dcow 9y ago
      I looked into this. It seems this is something that was added in M pertaining to Doze and App Stanby modes and is not related to the new O background execution limits (which apply generally). In any event, app exemptions must be approved by Google so we've already crossed the open platform line. They do list that voip-style/message apps will receive approval if they can't use FCM for some technical reason: https://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases https://developer.android.com/training/monitoring-device-sta...
- kuschku 9y ago
  There is some level of opt-out, but it doesn't work reliably, and your app might still get killed. Even the K9 team had issues with that, and many other open apps did so, too. I've been trying to work some kind of push messaging into the IRC bouncer for which I wrote an Android client, but the issues with legality (I can't just connect to a third party without explicit opt in), API keys (people who host an IRC bouncer don't want to register with Google), liability (I don't want to relay all messages through a server of my own), Google's ToS (I can't just publish an API key for everyone to use), confidentiality (I can't actually put content into the FCM messages due to legal issues), etc are so problematic that it's basically stalled everything. I've filed a complaint with the EU, this seems like the only option I've got left. I can't tell everyone running a bouncer to register with Google, I can't relay all messages of all IRC users through a server of mine, and I can't bake in a Google API key into IRC bouncers (as that violates Google's ToS)

by dcow 9y ago

tree_of_item 9y ago

Elsewhere to what? What are you gonna do, run Windows Mobile?

dcow 9y ago
I like native app development because it's not a browser. Android was the most honest manifestation of that on mobile (iOS is basically a "client OS"). I look towards domains where people are still putting powerful applications on connected hardware. Mobile is starting to look like a commodity web experience with half the history of JS, so why not just use that?
- dcow 9y ago
  Point being the delta between what a native app and what a browser app can do has all but disappeared. BT and Graphics are the last few notable things and both will be supported by browsers soon (webgl already is and webbt is incoming). I'm not saying go use JS.. I very much do not enjoy it. Im asking why we need to build native when there's increasingly less to justify the overhead.
  - pjmlp 9y ago
    WebGL is a poor cousin of OpenGL 4.6. Even comparing WebGL 2.0 to OpenGL ES 3.0, which it is based on, there are nice features like geometry shaders missing.
    - fulafel 9y ago
      Nitpick: Geometry shaders came in GLES 3.2 (there was also a geometry shader extension for GLES 3.1). In WebGL 2 you can still do geometry processing, and store results in buffers for subsequent draw calls, using transform feedback.
      - pjmlp 9y ago
        You are right, I mixed it up. Like that idea for WebGL 2.0, will have a look into it.

BugsJustFindMe 9y ago

Apps that were bad stewards of battery life and phone resources were supposed to be scrutinized by users If HN allowed emoji in comments, I'd have a U+1F923 here. Since I can't do that, you're adorable. The users, eh? The users are supposed to be burdened with checking the wake status and radio activation schedule of their apps? How was that supposed to work, exactly?

dcow 9y ago
I'm not sure what your point is here and your tone indicates you're not really looking for honest discussion. But FYI Android reports energy usage statistics to the user on a per-app basis. What I don't like is Android the platform telling me the user how my phone is best used. It's pretty crippling. Let's say I'm deploying Android on hardware that is always plugged in--something kiosk-style. Why shouldn't I be able to have an app that keep a persistent connection open to a network service for say real-time communication? You can't do that now.
- digi_owl 9y ago
  And if Android itself didn't tell you enough, there were apps line OSMonitor that could give you more detail (at least until Google shitcanned the permissions that it relied on for "security" reasons).
- tnone 9y ago
  Blame shitty mobile developers who screwed the pooch on Android. Even if you avoid shovelware, the quality is abysmal. My Android phone still randomly lights up its screen several times a day, without a new notification having come in. Reporting overall energy usage doesn't help me track down the culprit. It's not like anyone's written apps for real work on these devices anyway. It's all just second class software.
- ihattendorf 9y ago
  And what about the mysterious Android OS/Android System "apps" that show up on the battery usage screen? How do I know which app is hogging resources here? Should we expect users to inspect wakelocks?

klondike_ 9y ago

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.

dcow 9y ago
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.
- nomel 9y ago
  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.
  - digi_owl 9y ago
    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.

avar 9y ago

What part of that page indicates that you can't use the platform like that? They just say "more control over how apps run in the background". Presumably you can still give your users a good reason for why you need to run uninterrupted in the background and they can approve it similarly to how they now approve other permissions.

dcow 9y ago
The way this is implemented is that the system will kill any background services your app has after a grace period, just like iOS. In order to have a background service that "good reason" equates to a persistent notification in the tray and icon in the status bar--which nobody agrees is a good product experience.
- avar 9y ago
  Why is that not a good experience? Now I need to dig through Settings to find all these background services. If they're important enough to be running constantly they're important enough to take up some space to prominently show me that they're running.
  - kuschku 9y ago
    Yes, and you're okay with having 20 to 30 notifications at all times just to run open source apps, or would you say "this is too annoying, I'll switch back to the closed ones that spy on me". If you want the open source products to win, they need to be able to provide the same usability as the proprietary solution. This is not possible here - you need Google's FCM or you get major disadvantages, and this is problematic. I've filed a complaint with the EU, this seems like the only option I've got left. I can't tell everyone running a bouncer to register with Google, I can't relay all messages of all IRC users through a server of mine, and I can't bake in a Google API key into IRC bouncers (as that violates Google's ToS)
    - avar 9y ago
      This doesn't inherently have anything to do with open source, but the problem that whatever license the apps on the phone are under they can't all be implementing their own push/pull message queue, having 30 open network connections constantly waking up the phone is going to drain the battery. If I install 100 apps that have their own messaging implementation should the phone just not be showing that to me, even though my battery is now drained in half the time as a result? I'm pointing out that as a user this is very pertinent info to be showing me, if I have 30 apps running in the background I'd like to see it.

kevincox 9y ago

You can disable "Battery Optimization" per app, so this isn't very restrictive. It just applies by default.

mjevans 9y ago
I'd like to do that, but when I 'exit' an app and/or swipe it off of the list of program cards I want it to ACTUALLY exit (at least within 30 seconds).
- dcow 9y ago
  What if that app is say and open source messenger app that doesn't use GCM/FCM. For that to work you need to maintain a connection with a remote service. You don't need the UI hogging memory the whole time but you definitely want messages to come in immediately. IMO the system should offer a way to completely kill and app but "killing the UI" should not stop critical services utilized by the app. Okay so maybe you could argue that if you never "swipe kill" the app it should be allowed to have background services executing much like e.g. Slack on macOS. But you can't even do that. Having your ui in the recent tasks list does not exempt you from background restriction.
  - dlubarov 9y ago
    There is a way to kill an app process, but it's in Setting and takes several clicks. I think it's for the best that killing isn't easier, because users don't generally know the implications of killing an app. In Square's Register app for example, force killing the process could prevent the app from uploading important payment data in a timely fashion.
  - exadeci 9y ago
    You just don't know much about android dev it seems. When an app gets put in the background it gets an event from the OS it's then the devs job to not keep everything loaded in the background but most don't.
- kllrnohj 9y ago

catdog 9y ago

At least in Android 7 you can explicitly allow this for a specific app. This question can even be triggered by the app itself (e.g. Conversations and Signal ask you to do this if they can't use GCM). This is hopefully still possible. > It's the turning of an era for Android, and my interests have moved elsewhere (from an app platform perspective, embedded Android is still vialble since everything you ship runs as a system app with no restrictions). Google making it more and more difficult to avoid gapps is nothing new.

dcow 9y ago
Can you point me to the relevant info? This is news to me (and sounds exciting). No doubt we've seen it coming for awhile. But I'm still sad to see it finally come to this, at least ideologically. iOS is a closed ecosystem that's been opening up. Android was an open ecosystem that's becoming more locked down.
- catdog 9y ago
  [1] Seems to do the trick but I don't do Android dev so I don't know any details about this. [1] https://github.com/siacs/Conversations/blob/2b9cdde558ed96c23ca02357b3d9e4f47a80e764/src/main/java/eu/siacs/conversations/ui/ConversationActivity.java#L1500 https://github.com/siacs/Conversations/blob/2b9cdde558ed96c2...
  - dcow 9y ago
    I looked into this. It seems this is something that was added in M pertaining to Doze and App Stanby modes and is not related to the new O background execution limits (which apply generally). In any event, app exemptions must be approved by Google so we've already crossed the open platform line. They do list that voip-style/message apps will receive approval if they can't use FCM for some technical reason: https://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases https://developer.android.com/training/monitoring-device-sta...
kuschku 9y ago
There is some level of opt-out, but it doesn't work reliably, and your app might still get killed. Even the K9 team had issues with that, and many other open apps did so, too. I've been trying to work some kind of push messaging into the IRC bouncer for which I wrote an Android client, but the issues with legality (I can't just connect to a third party without explicit opt in), API keys (people who host an IRC bouncer don't want to register with Google), liability (I don't want to relay all messages through a server of my own), Google's ToS (I can't just publish an API key for everyone to use), confidentiality (I can't actually put content into the FCM messages due to legal issues), etc are so problematic that it's basically stalled everything. I've filed a complaint with the EU, this seems like the only option I've got left. I can't tell everyone running a bouncer to register with Google, I can't relay all messages of all IRC users through a server of mine, and I can't bake in a Google API key into IRC bouncers (as that violates Google's ToS)