Hacker News Reader

Comment by sudhirj | Hacker News Reader

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 services.

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 (audio playback, downloads, alarms, notifications) to the OS, and made clear guarantees about the circumstances under which the APIs would work.

View on HN

>> "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.

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...

1. no, does not work — email clients warn users that if the app gets killed then notifications will stop and yes, I tested this quite recently

2. no, it does not work for background uploads, here are screenshots of Dropbox's configuration and Dropbox is not alone in doing this ;-)

Step 1: https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02...

Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...

Isn't that the same kind of excuse-making you're dinging the Android world for? "OK, fine, the experience sucks by default but it works fine if you just do this and this and this". Android has all those sorts of features too.

It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad apps. Users do actually benefit from this on balance.

> Users do actually benefit from this on balance.

Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.

> There is no benefit to killing an app without notifying it in any way

Sigh. There can be on balance. Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest).

Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fisted" or the existence of a better solution.

All I'm saying is that app vendors aren't the only parties involved here, and that the problem being addressed is real, and quite important.

Can you explain the advantage in killing the app without notifying it? You're going to kill the app because it's consuming 500MB of memory, fine, send it SIGTERM or equivalent and then give it two minutes to orderly shut down before you send SIGKILL. Not doing it that way has a cost and no apparent benefit to "balance" it with.

> Can you explain the advantage in killing the app without notifying it?

Um.. "The app uses less energy." Is that a serious question?

Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.

> Um.. "The app uses less energy." Is that a serious question?

For the two minutes between when you ask it to shut down and when you kill it? Even assuming that's a meaningful amount of energy savings (probably not), you could just kill it at the same time as you would have regardless but ask it to shut down two minutes before that.

> Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.

All value is relative. You can make anything sound good by comparing it to something arbitrarily worse, but that doesn't prove anything. Riding a donkey is better than walking on foot but I wouldn't want to have to travel from New York to LA on one.

The question is whether it's better than the good known existing alternatives, not whether it's better than the bad ones.

Background App Refresh has been a thing for ages - It took them a while, but Apple solved this problem in a super user-friendly manner.

No, they haven't solved it.

I’m curious: why doesn’t background refresh solve the problem?

Background refresh doesn't work if the user "force closes" the app, i.e. they go to the task manager and swipe it away. Anecdotally, it's super common for people to do this as they have read somewhere that it helps battery life (not untrue, but also not really effective). So if you were writing an e-mail app you wouldn't be able to guarantee that you'll actually deliver e-mail to users, which feels kind of important.

Sounds like user error at that point, I would popup a message after the next force quit saying that doing so will pause email notification until the app is reopened.

There you go: bug turned into a feature.

How on earth would that be a feature? If you have to show a popup on launch for something like that then it's a user experience failure, no matter if it's your fault or Apple's. Either way, it means the user has to treat your app differently to every other app on their phone. That is bad.

"It's user error" is a weak excuse if any kind of significant number of users are doing it.

If a user 'force quits' an app, don't they expect that it won't be running in the background receiving app content updates?

If I force quit an app on my computer, it no longer runs and does things.

I think most users expect to receive notifications from apps (especially communication apps) even if the app doesn't appear in the App Switcher carousel. What people expect from their phones and computers are wildly different here.

An app that has been force quit can still receive remote notifications just fine. I don't think the average users knowledge is so nuanced that they understand the distinction between a remotely-sent notification that always appears and a locally generated one that's the result of a background process that doesn't.

The feature in my mind was an easy way to temp silence an app without going into settings.

I still think of it as user error if they force quit an app but still expect it to run in the background. Why force quit it?

I could see how it could be a UX failure for the OS but I don't think we can blame the dev for that. Apple should clarify what force quit does. I think the advent of webapps that don't really exist on your phone at all also causes confusion: the app has been updated with more content each time you use it, even if it's not running in the background, but to the user that's indistinguishable from the app running in the background.

I see. I can see the issue.

But it comes down to this: if a user explicitly kills an app, should it keep running in the background?

If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed.

I get that some users don't know what killing an app means but do it anyway for some reason.

But that's not a problem with background refresh. E.g., maybe iOS could warn/explain about the implications of killing an app (with a checkbox so you can opt-out of further warnings).

Edit: just realized I left the word “not” out just above, which reverses it’s meaning

The problem is that nothing is self-evident. An app that sends remote notifications to notify you of an e-mail looks exactly the same as one that locally generates a notification as a result of background processing. But the former will work after being swiped away from the app switcher and the latter won't.

I just don't think it's reasonable to expect the average use to "get" that.

I agree the users shouldn’t be the ones worrying about the subtlties. It’s we developers.

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 privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.

Should also see if the killer apps are phoning home every time they kill anything, along with info about which app is killed on whose phone at what time. Becuase, you know, analytics.

And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied.

But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.

As I understand it, on iOS third part apps don’t actually do any tasks in the background, most such services are actually implemented by platform services provided by Apple that the third part apps request or subscribe to. So for example apps request an Apple service to do a background download on their behalf. Or the app subscribes to a notification feed that wakes it up when triggered to handle the notification, but the app doesn't do a download or wait for notifications itself.

Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication.

This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way.

EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.

For some basic use cases, like notifications and downloads, there is a special system or api that allows your app to do that in the background without actually running.

If you want to play audio or track gps in the background you need to do things yourself though.

OK, hence the Facebook issue where they played a silent audio track to keep their app active. I'd forgotten about that, thanks.

Wow, that sucks is again super user hostile, I'm so happy I removed their app.

>I don’t think you could implement a tracking socket masquerading as a background download

The Facebook app used to play a silent audio track to stay active in the background, until they got called out: https://www.reddit.com/r/iphone/comments/3opxhm/facebook_app...

Holy crap, I didn’t know that. Yet another reason I was right to uninstall the app and just use the website.

Technically, you could have an app that plays silent audio in the background to keep from getting killed and then do something else, but that would get flagged by the review process.

But, if I recall correctly, VLC will continue a background file transfer session from its built in web server on iOS if you play a movie in the background. Otherwise it will be killed after 10 minutes.

I think they've wisened up to that trick. My girlfriend and I use a guided meditation app that has long silences in the audio. If the screen is off, her phone kills the app after about thirty seconds of silence, making the app practically useless.

I was going to report a bug to the app suggesting they include some ultrasonic or subsonic audio to defeat this mechanism, but it's just an arms race at that point. The phone will start looking at the total power in the audible spectrum to decide whether to kill the app or something.

This kind of thing is infuriating and prevents apps from doing anything outside of the box, stifling innovation and making users frustrated.

> 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).

That is the case in iOS. All permissions are optional and the app must gracefully degrade if permissions are denied.

Unfortunately, some apps just degrade, ungracefully, by flat out refusing to run without certain permissions.

On iOS? That's against app store rules if I remember correctly.

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 permissions are denied. So the result is usually the same as pre-Marshmellow. You just get more annoying popups.

I miss Cyanogenmod where I could deny a permission (e.g. contacts) and the app would have no idea it was denied (it would receive an empty list of contacts).

> 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.

I really wish I could whitelist which contacts each app could see, so WhatsApp only sees the ones I want on that app.

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?

Slack receives messages with no problem.

If XMPP/IRC can’t provide that, it’s not iOS’ problem.

I don't know why you were downvoted; it's a solid-and-concise critique of the difference in protocols.

Slack works because of push notifications. A random IRC app can't handle push notifications for you because they aren't the IRC server and aren't running a bouncer for you. On the other hand, the IRC server can't handle push notifications for you because they don't have an app signed with Apple's key sending the notifications.

Basically protocols as a general thing can't work on iOS, only individual apps/services which get to read all your messages and access your login credentials work.

> Basically protocols as a general thing can't work on iOS, only individual apps/services which get to read all your messages and access your login credentials work.

Which I think is a reasonable requirement for a chat service, especially on mobile.

"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?)

>"Use a bouncer" might be the answer there.

Weechat and weechat-android are great choices here. Best CLI and Android IRC clients I've used, and I've tried quite a few.

A bouncer is not a satisfying answer, then I could just use something web-based anyways.

My Android tablet is on a stable WiFi network at home...

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.

Which is why Apple is so big. Also Walmart. Also Top40.

Classic HN response.

I'd guess a FTP and a linux file-server would solve all your filesharing woes as well.

No dev making a mass market device or software should build as if the 1% graybeard engineer is gonna be the only user, that's a lot more user hostile.

Never mind HN, that's a classic Slashdot response.

Android's "these are the apps killing your battery life" interface is perfectly usable by Joe Everyuser. This is a specious argument.

Reality suggests otherwise.

Every modern phone today will give you a list of the apps that take the most juice, and yet somehow for some reason people still install facebook. We might need to protect users from themselves.

Or users could start holding facebook accountable for shitty battery life.

I don't understand why phone manufacturers need to add features to protect facebook users from facebook. facebook has the money to build an app that isn't shit.

The "which apps are using battery" feature is easily useable by novice users.

However most phone vendors incorrectly assume "background connections" will drain battery life despite evidence to the contrary.

Phone vendors have a vested interest though in forcing developers to use their proprietary "push" feature for syncing to phones, they say it's for "battery life" but really its about vendor lock in.

A well engineered app can sync over its own TCP connection just fine and not hurt battery life, but then such an app can work on any device, not just blessed Android builds that have access to GCM.

I run Cisco Jabber on my iPhone, and it seems to run fine. AFAIK that is XMPP.

Getting messages should not/does not have anything to do with running in the background.

Getting messages requires an open TCP connection, hence it really is quite important (at least with IRC) that the app stays running in the background.

This is what the push message API in iOS is for. It wakes up the app when messages come in.

Which means there is a third party eavesdropping on chat.

> This is what the push message API in iOS is for. It wakes up the app when messages come in.

IRC isn't reliant on a proprietary push message API, though (be that provided by Apple or Google).

I'm sure there are long-lived bouncer plugins that will integrate with said APIs, but the core IRC protocol is not suited to or designed for devices that aren't capable of a long-lived connection.

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.

Do push notifications take advantage of knowledge of the physical layer of the network?

It's a lot cheaper to keep an LTE radio on in a low-wattage "ping me if you need me" mode and trust the 'infinite-power' landside terminal to notify you of messages than to wake it up once every N seconds to loudly ping a cell tower "HEY LET ME KNOW IF I HAVE ANY MESSAGES KTHX."

> How do you think push notifications work?

There’s a very distinct difference between having a persistent connection that only transmits data when there’s something notable vs having a connection that constants pushes a kitchen sink of data that may or may not be needed. Sure, if you sent a push notification on every single message and status change on the IRC server, it’d likely use the same amount of (or maybe more) battery, but who does that?

Right. That's why there's an API for it. Each app doesn't have to stay awake listening. The OS will wake the app up.

Oh, that does make sense.

In that case, having the app run the background really does seem like a waste when compared to leaving the OS to do this task.

If you want a messaging app to work well, it should send and receive messages when the phone has network connectivity and power. Power is a prerequisite for running in the foreground, but network connectivity is not. Some people may in fact want messaging apps to only work while in the foreground and network available, but I suspect that's less desired.

If you're trying to run standard irc and appear online as much as possible, that's not going to work in iOS without a bouncer to stay online for you and send push messages to send notifications and allow the app to run for a bit to download the messages.

It's probably not a bad idea on Android too, it's technically possible to run as a background service and stay connected, but there's a lot of uncertainty, because other services can crowd you out, and you're at the whim of Google and oems with power management these days.

And also, it's the 21st century and we don't need chat protocols to be client-side-liveness chatty to "stay on" when the entire cellular network is architected to find devices and route messages to them.

IRC isn't a well-designed protocol for this use case, and a "land-side" bouncer that bridges the chatty protocol to a lazier protocol ought to be more energy-efficient overall.

Well-designed or not, it exists, and sometimes you just want to use it, without a lecture on how it's suboptimal.

That's fine. you are "free" to hack your own version of Android that modifies the APIs to disregard power-management best practices.

... and maybe your own hardware to run them on. But I wouldn't expect any major player competing against other companies to do the work for you when the outcome is supporting some chat protocols that most people don't use.

(Otherwise, if you're expecting vendors to do it for you, you get to expect the lecture that comes with that expectation, in the form of APIs designed to minimize the ease of doing the wrong-for-the-average-utility-of-the-platform thing. Your cell radio could probably be adjusted to operate as a spark-gap transmitter also, but I don't expect them to provide an easy API for that either ;) ).

> And apps that don’t fit those use cases - what are they doing with your device?

What I, the owner of my device, have directed them to do.

Apple's approach makes easy things difficult (because one must use their APIs) and difficult things impossible (because Apple have decided that purchasers of their devices shouldn't be permitted to do things Apple wishes them not to do).

I want a general-purpose computer that I own & control in my pocket, not some stripped-down communicator owned & control by someone else.

You've definitely made the case that you don't want an iOS device.

... the market appears to be making the case that you are not the average consumer, but that's an independent variable.

The market has consistently been choosing Android phones in higher volumes than iPhones for years.

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.

A design so disrespectful it borders on malware.

The Nokia one is egregious, but their second worst vendor (OnePlus) allows users to whitelist individual apps, though there's a bug right now where that setting gets reset randomly.

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 possible).

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.

I think that's an over fatalistic interpretation. You're implying that giving more power to users inevitably results in them harming themselves and therefore should not be done, instead the OS vendor should make explicit APIs for everything and only whitelist "allowable" things.

My problem with that is that it kills all innovation and creativity - only the OS vendor can come up with a "new" whitelisted activity. Anybody else is out of luck. Inevitably that means you simply can't get niche applications because what Google or Apple sized company is going to invest in something only 10,000 people might use? I might be idealistic, but I firmly believe that it's possible to both grant power to end users (as in, enable app developers to have a very large amount of control) AND deliver a good end user experience. It requires a lot of good design and discipline and it's definitely hard, but that's not an excuse to give up and hand over all control to the OS vendor.

I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here.

It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.

What is a trash app by your definition?

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 vendors would use any tactic to make it less open in order to force users to run their crap, get more brand exposition, steal personal data etc.

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.

> only a closed system with a single gatekeeper that can avoid this problem at scale

I guess you are hinting at Apple phones but this works only because the gatekeeper is acting in good faith. Then again why do you need a single gatekeeper?

You clipped off my answer to that question from your quote.

I mean you can disagree, that's fine, in which case just say so.

> 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.

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

True, but its strength is also its weakness in this context: anyone can keep the distro open but add some "vital" code that is closed and does what they want without anyone noticing. The GPL doesn't prevent closed code from running on open source machines, it just sets limitations on imposing limitations (which makes it so great IMO), so a module that displays advertising, tracks users or steals personal data can easily be implemented inside a closed app, blob, device driver etc. and unless I missed something the GPL can do nothing if that module was compiled using non GPLed compilers, linked against non GPLed libraries etc. In other words, if I take a non GPLed compiler and a set of non GPLed libraries that set no obligation to open the resulting code if I distribute the output, I can write anything and add it to a Linux distro then distribute them together without any legal obligation to publish the source and reveal the internals of my code. That would be the case for suspicious code inside blobs and drivers. Someone please correct me if I'm wrong.

Of course the community can fork in no time, but imagine a very popular piece of hardware which could work only with that closed blob.

> 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.

PC hardware is available from arbitrarily many vendors and you can install stock Windows or Linux on pretty much all of it. Many of the OEMs preinstall their various spyware, but you don't have to buy from them to begin with, and even then they can't stop you from removing it.

The primary difference in the phone market is the lack of open source drivers, so you can't install stock Android on your arbitrary phone because it needs the specific weird kernel it came with. But basically everybody hates that -- even the OEMs, because they neither want to be blamed for not providing updates nor want to have to actually provide them themselves. So it's slowly changing.

And even now, as a customer, there are unlocked devices available that will run stock Android, all you have to do is buy one of them.

> but its open nature would allow users to remove unwanted stuff

They would find a way, because money.

The point is trash apps don't have to be a problem as long as the platform is managed properly. Anyway your trash app is probably someone else's fun entertainment.

I just doubt that "managed" platforms are delivering what they have promised and think that the quality of apps on more open systems is generally better by a few magnitudes without exaggerating too much.

And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration.

"Managed" platforms accelerated this phenomenon in my opinion.

Reply on news.ycombinator.com