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

281–290 of 414 posts

Re: Android vendors, don’t kill my app

#281

Post by zeveb »

simonh wrote: post #72
squarefoot wrote: post #70

Earlier quoted context omitted.

The locked environment may prevent users from removing branded crapware installed by vendors, but it's not its cause. Popularity is. If Gentoo Linux (just to name one we wouldn't expect Joe User to know) became popular as Android on cellphones, we would see in no time vendors trying to cram their crapware into every platform running Gentoo as well, but its open nature would allow users to remove unwanted stuff, so ve…

Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.

> Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems.

That's the beauty of the GPL: one can't lock down a GPLed distro that way.

> In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.

Those who s/freedom/security/g tend to rm -rf / and get neither freedom nor security.

Re: Android vendors, don’t kill my app

#282

Post by me551ah »

Ninn wrote: post #170
adrianhon wrote: post #148

For our Zombies, Run! run tracking/audio adventure app, "battery management" is turning into our most consistent customer complaint, to the point where it's impacting review scores, active users, and probably subscriptions. The result of the changes made by Huawei, OnePlus, Xiaomi, and Samsung mean that our app is killed during runs, and people interpret that as the app crashing. We're trying to figure out the best w…

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged. Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

There is a way to detect it but it's hacky. You need to use fcm xmpp to send data push notifications with delivery receipts and also send an acknowledgement from the apps background service. Devices where you don't get the app ack have an app which is force killed

Details outlined here : hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a

Re: Android vendors, don’t kill my app

#283

Post by nbzklr »

scarface74 wrote: post #141
nbzklr wrote: post #85

Earlier quoted context omitted.

This isn't about protecting the user from badly written and battery draining apps. Almost all of the mentioned manufacturers ship their devices with a long list of pre-installed and whitelisted services, including Facebook and other spyware. As a developer myself, it is just annoying do deal with and just not scalable if you have to explain each user individually how to turn of these "optimizations" (if that's even p…

It’s also not scalable if every app starts running background processes on an operating system without “virtual memory” - yes, I know there is a difference between virtual memory and swapping to the disk.

Even stock android does not guarantee that background services can run indefinitely, but Google at least provides clear rules what process may run how long in the background and under which circumstances it is killed. I have no idea why the manufacturers are allowed to blatantly break those rules and still brand their operating system Android.

Re: Android vendors, don’t kill my app

#284

Post by admax88q »

dithering wrote: post #227
anc84 wrote: post #193

Earlier quoted context omitted.

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

"Use a bouncer" might be the answer there. All engineering is compromise, and needing a bit more compromise to support legacy applications is not unreasonable. (In fact, why are you running a stream-oriented application over such an unreliable connection at all?)

My XMPP client works perfectly on my Android phone. Prompt and reliable notifications of new messages. Better than most "Push Message" based clients I've used for other chat services.

It's consistently the last in battery usage as well.

Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.

Re: Android vendors, don’t kill my app

#285

Post by Nullabillity »

noxToken wrote: post #231
aasasd wrote: post #204

Earlier quoted context omitted.

If Play Store allows to mark the app as incompatible with specific models, that might be the best recourse―since the app can't function properly on those phones anyway.

Isn't that basically a death knell - especially if you're not a top 10/50/100 app - when trying to reach customers? If you wait until the customer has downloaded your app, you'll probably have better retention. If you mark your app as incompatible, people won't even bother to install even though there could be a work around. You'd basically be trying to send a message to users about device manufacturers and the Andro…

Not even that: marking it as incompatible will render the app listing invisible for those devices (in both top lists and searches), and if you do reach the listing directly then the install button will be disabled.

Pulling the nuclear option for something with clear workarounds (or which only impacts peripheral features) is unacceptable.

Re: Android vendors, don’t kill my app

#286

Post by admax88q »

jsjohnst wrote: post #280
feikname wrote: post #252

Earlier quoted context omitted.

Receiving messages (aka "listening" in server jargon) is essentially a background task, constantly probing to check for any changes.

I think the point being made is that’s a terrible use of resources, not only are you keeping the app running, but you are also forcing the power hungry LTE radio to stay on more. This idea that the end device should do all the work is not a sustainable approach. There should be a server side component that is handling this for you and sending push notifications when your app needs to wake up for new data.

> sending push notifications when your app needs

How do you think push notifications work? There isn't some magic in LTE to wake up your phone. Your phone needs to keep a connection open in the background and periodically wake up the modem to check for new information.

I use Conversations (XMPP client) on Android, it keeps a plain old TCP connection open in the background and honestly it does not much battery at all. It's consistently at the bottom of battery usage according to my phone.

Re: Android vendors, don’t kill my app

#287

Post by reificator »

shimfish wrote: post #203
Ninn wrote: post #170

Earlier quoted context omitted.

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged. Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.

> as well as showing a vital misunderstanding about UX

The third party controlling your user's experience is forcibly killing your application while it's in use as intended. This somehow means you are misunderstanding UX?

People are suggesting ways to detect it and teach the user how to stop it, because they have no automated solution to this problem.

Re: Android vendors, don’t kill my app

#288

Post by EpicEng »

shimfish wrote: post #203
Ninn wrote: post #170

Earlier quoted context omitted.

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged. Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.

>a vital misunderstanding about UX.

What misunderstanding would that be exactly? App developer has to find a way to help customers work around an issue they cannot resolve themselves. Seems reasonable to me.

Re: Android vendors, don’t kill my app

#289

Post by apexalpha »

admax88q wrote: post #284
dithering wrote: post #227

Earlier quoted context omitted.

"Use a bouncer" might be the answer there. All engineering is compromise, and needing a bit more compromise to support legacy applications is not unreasonable. (In fact, why are you running a stream-oriented application over such an unreliable connection at all?)

My XMPP client works perfectly on my Android phone. Prompt and reliable notifications of new messages. Better than most "Push Message" based clients I've used for other chat services. It's consistently the last in battery usage as well. Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.

>Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.

No, but the other 6 billion people on the planet do.

Re: Android vendors, don’t kill my app

#290

Post by daveFNbuck »

dbrgn wrote: post #39
daveFNbuck wrote: post #20

Earlier quoted context omitted.

I don't want Slack or Gmail to deliver notifications instantly. I'd love to have functionality that saves battery by delaying them.

If the app is killed that doesn't just delay notifications. It prevents them until you manually open the app again.

Yeah, but we're talking about manufacturers adding custom functionality that delays notifications to save battery.
Post reply on HN