Slashdot Mirror


Google: Less Than One Percent of Android Devices Are Affected By Harmful Apps

jfruh writes: One of the selling points of iOS is that its more restrictive nature makes it more secure. But even though it's easier for users to accidentally install malicious apps on Android, data collected by Google (PDF) indicates that less than one percent of Android users have actually done so. Quoting: "During October 2014, the lowest level of device hygiene was 99.5% and the highest level was 99.65%, so less than 0.5% of devices had a Potentially Harmful Application (PHA) installed (excluding non-malicious Rooting apps). During that same time period, approximately 0.25% of devices had a non-malicious Rooting application installed. ... Worldwide, excluding non-malicious Rooting applications, PHAs are installed on less than 0.1% of devices that install applications only from Google Play. Non-rooting PHAs are installed on approximately 0.7% of devices that are configured to permit installation from outside of Google Play. Additionally, the second graph shows devices with any PHA (including Rooting applications). Rooting applications are installed on about 0.5% of devices that allow sideloading of applications from outside of Google Play."

91 comments

  1. Bring back... by ADRA · · Score: 1, Offtopic

    AppOps, tyvm. Done.

    --
    Bye!
  2. 0.5 percent of 1 billlion is by Anonymous Coward · · Score: 1

    A lot.

    1. Re:0.5 percent of 1 billlion is by jaxn · · Score: 1

      Well, let's see

      If only Jayne from Firefly could help us with the math.

      1% of more than a billion?
      1+1x1, carry the zero, x 1 billion, divided by, oh goram that's a lot! I aint never seen numbers that big.

      --


      "Being alive is a crock of shit." --Kilgore Trout
  3. A less biased source please? by Anonymous Coward · · Score: 1

    If Google or Apple talk stats about their ecosystem, take it with a giant grain of salt.

    It's pure marketing BS.

    1. Re:A less biased source please? by halivar · · Score: 3, Funny

      According to Apple, iOS users are more virile, and have love-making stamina for hours.
      According the Microsoft, Windows Phone users are endowed with the power of invisibility, which is why they are so elusive.

    2. Re:A less biased source please? by Aighearach · · Score: 4, Insightful

      Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info. The vast majority of apps in their walled garden don't actually need any special permissions at all to do whatever the app does, or maybe 1 permission. Find an app that has only the permission it needs. Good luck, hope you ate a big breakfast before you started searching.

      How is tracking me with nothing given in return not "harmful?" My privacy has value to me, surely. The claim that there is no harm relies on the known lie that my privacy has no value to me.

      The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google . That is actually a different thing than what they're saying, though. So I call lie .

    3. Re:A less biased source please? by Anonymous Coward · · Score: 0, Troll

      "According to Apple, iOS users are more virile, and have love-making stamina for hours."

      What they don't tell you is that's only for gay sex.

    4. Re:A less biased source please? by grimmjeeper · · Score: 1

      What do you mean? A company might be dishonest when they audit themselves for marketing purposes? I don't believe you... /sarcasm

    5. Re:A less biased source please? by Anonymous Coward · · Score: 0

      Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info.

      Could you please give some examples? It seems to me F-Droid strips out a lot of the crap. I know they eliminate advertising and tracking.

    6. Re:A less biased source please? by Aighearach · · Score: 1

      You don't "know" that, because if you spent time with it and were paying attention, you'd know otherwise.

      In some cases they strip out analytics libraries, for example. However, many of those apps are still asking for your device ID and "phone status." "Phone status" sounds like it is about the current status, but actually that exposes all the numbers you call, when, for how long, etc.

      And the same app will ask for full network access, even though if you look at the traffic, almost all of them are using HTTP to talk to their services, and they have no legit need for full network access. However, it lets them look at what all your network connections are.

      If the defense is, "Golly gee, writing apps is easy but writing an android manifest that only requests actually used permissions is hard" then that is pretty bad news. But it isn't at all the same as, "they're not doing it."

      "Nobody" cares, if there was going to be outrage there already would be. If they wanted to fix the way they handle permissions, they would have already. F-Droid may push malware, but they're not ignorant of the choices they make. There is no utility at all in naming examples, you can click on 5 or 10 and have 4 to 9 examples of it. Install 10 random apps, you'll likely have exactly 1 that doesn't request any special permissions. And that will be the only one that needed its permissions. Even various "sky map" and "mountain map" apps want your phone ID. Why? No reason? Then why did they ask? Do you trust people who ask for personal information they claim not to have any use for? If I knew they asked for it out of incompetence, it wouldn't increase my trust at all.

    7. Re:A less biased source please? by Anonymous Coward · · Score: 0

      "One of the selling points of iOS is that its more restrictive nature makes it more secure."
                                                                  ---Apple

      Just kidding, that was OP. An insane claim.

    8. Re:A less biased source please? by Anonymous Coward · · Score: 2, Funny

      "Waah! I don't like teh Appul! It's teh gay!!11111!1" (Self-entitled smirk) (Gets modded up by other smug, self-entitled Slashdotters)

    9. Re:A less biased source please? by swillden · · Score: 3, Informative

      If Google or Apple talk stats about their ecosystem, take it with a giant grain of salt.

      It's pure marketing BS.

      Take it with a grain of salt, sure, that's wise. However, there's nothing marketing-related about the numbers in the report. These numbers are snapshots of the data the Android anti-malware team uses internally to assess its effectiveness. The numbers are not fudged, and what they show is that while there are issues, Google's anti-malware team is making solid progress and the current state of the ecosystem is actually not too bad. There are some caveats (called out in the report) around the fact that the numbers describe the prevalence of known potentially-harmful apps. The charts get revised retroactively when new PHAs are discovered but snapshots in reports are static. Still, I think the numbers are quite reliable.

      Note that I'm a member of the Android security team, and my manager is the primary author of the report and blog post, though I work on platform crypto features, not anti-malware.

      At worst, the numbers in the report represent the ways in with the Android team fools itself about the state of ecosystem security. At best they're an accurate and nuanced reflection of the state of the ecosystem. The truth is somewhere in between, but I think it's far, far closer to the latter than the former. What the numbers definitely are not is anything cooked up specifically for the public.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:A less biased source please? by Immerman · · Score: 1

      >How is tracking me with nothing given in return not "harmful?"
      I agree, except for the "nothing given in return" part. They're giving you the use of their software. Part of the price you pay is letting them spy on you. A nice straightforward business transaction - except for the fact that their spying is usually deceptively obscured.

      I have no problem with a piece of software that spies on me as part of its declared up front price - I'll tell them to go fuck themselves and look for an alternative unless they offer an incredibly compelling product (Google/Bing/Yahoo services anyone?), but hey, if they can find takers, well good for them (except for the fact that I get indirectly spied on if I interact with those takers - that chafes). What really bothers me is that they try to obscure the fact that they're spying on users - THAT should qualify as invasive and fraudulent behavior - after all they didn't mention that part of the price when you agreed to purchase.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    11. Re:A less biased source please? by swillden · · Score: 3, Informative

      Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info.

      (I'm a member of Google's Android security team.)

      This is a valid issue, but separate from what the report is attempting to address. Well, not entirely separate, because the Android security team does in some cases classify apps that request excessive permissions as potentially-harmful, but only when there's evidence that the apps are actually trying to abuse the user.

      Note that I'm not trying to downplay the issue of apps that request more permissions than they need. I think (based on lots of evidence) that in most cases this is more an artifact of developer laziness than malice; they aren't sure exactly what they need and definitely don't know what they're going to need in the future and so find it easier to ask for the world. This is a problem the Android security team recognizes and is working to address, in various ways that I can't go into.

      How is tracking me with nothing given in return not "harmful?" My privacy has value to me, surely. The claim that there is no harm relies on the known lie that my privacy has no value to me.

      Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.

      The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google.

      Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not. In general, the Android security team treats the rest of Google as just another app developer and online service provider. It's not our job to enable their revenue streams. Granted that we recognize that those revenue streams pay our salaries, but in the long run treating users well is what will enable Google to continue making money and paying our salaries.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    12. Re:A less biased source please? by Anonymous Coward · · Score: 0

      So you're not going to give an example of an app in F-Droid that does what you say?

    13. Re:A less biased source please? by Anubis+IV · · Score: 1

      Indeed. For me, the biggest questions were regarding the date range of the data being used. Why just one month's stats from 6 months ago? Why October specifically, rather than continuing on beyond?

      Turns out I managed to answer my own questions while scanning through the report for answers. October is when they began monitoring these statistics, so that explains why it starts when it does. As for why the stats only run through the end of October, they were preparing the report in February, apparently, and their research indicates that most Potentially Harmful Apps (PHAs) are identified within the first 60 days, which meant that there's a lag of 60 days between when the raw data comes in and when they can make the best sense of it based on discovering which apps were PHAs.

      My other concern was that Verify Apps was described as only collecting data at the time of installation, meaning that I thought they were really measuring the frequency of devices with new infections during the measured period (i.e. I was thinking their data was really saying that "less than 1% of Android devices had a new infection in the three-week period", which would be a downright scary statistic), rather than the frequency of devices with an infection, period. As it turns out, Verify Apps was enhanced in March 2014 to add full-device, background scanning, so it actually is monitoring previous installs as well.

      I'll admit, I'm an iPhone fan, but I can't really find any faults with the study. It's factual and, at least on an initial look, doesn't appear to be obscuring unpleasant truths in market speak. The more I scrutinize it, the more it seems to hold up. In fact, these numbers aren't altogether that dissimilar from what I recall seeing independent researchers put out regarding Android a few months back.

      That said, where this report differs from the independent ones is that the independent ones did comparisons between the various ecosystems, and pointed out that Android suffered from infection rates that were an order of magnitude or more worse than its competitors. Obviously, this report contains no mention of such comparisons. Which is to say, it's clear that this is an attempt by Google to change the nature of the narrative surrounding malware and its presence on Android, but that's an entirely fair thing for them to try and do, since a 1% infection rate really is worth bragging about in most cases, even if the competition might be doing better.

    14. Re:A less biased source please? by Anonymous Coward · · Score: 0

      Same thing happens in iOS, except you don't know it is doing so. Try a jailbroken device with PMP (Protect my Privacy), and you will see that a lot of iOS apps do a lot more phoning home than you would think.

    15. Re:A less biased source please? by mlts · · Score: 1

      IMHO, the Google/Android security team is doing a good job. I have never gotten stung on the Play Store, and I've not encountered "fishy" apps (ones that have horror stories in the reviews) that didn't get taken down quickly in a long time.

      Of course, I am still partial to XPrivacy, because it doesn't deny an app permissions... it just feeds it BS. However, I do think Google has kept with the times in terms of security.

      The black eye with Android isn't Google's fault. Virtually all reports of malware I see here in the US are due to people going to shady repositories for pirated apps. Yes, it might "save" $1.99 on an app, but there is a good chance, a lot more "functionality" might come with the .apk file.

    16. Re:A less biased source please? by chadenright · · Score: 1

      Mod parent up +1

    17. Re: A less biased source please? by Anonymous Coward · · Score: 0

      I've had spyware from the play store 3x, maybe you are that android stereotype that just isn't using a lot of apps...?

    18. Re:A less biased source please? by 0123456 · · Score: 2

      Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.

      So when are you going to give us the ability to disable permissions on a per-app basis? You know, like you added to the OS a few revisions back, then took away again?

      This is the biggest single reason I recommend people not to buy Android these days if they ask. I'm sick of apps asking for all kinds of permissions that I don't want to give them, and not having any way to block them.

    19. Re:A less biased source please? by ejasons · · Score: 2

      I recently moved back to an iPhone, after a few years on Android. It is so very nice to be able to update my apps, and not have to review all of the extra permissions that every app is requesting. And not having to manage the permissions in appops/xprivacy.

    20. Re:A less biased source please? by macs4all · · Score: 2

      Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.

      Of course, then there's THIS .

    21. Re:A less biased source please? by macs4all · · Score: 0

      The black eye with Android isn't Google's fault. Virtually all reports of malware I see here in the US are due to people going to shady repositories for pirated apps. Yes, it might "save" $1.99 on an app, but there is a good chance, a lot more "functionality" might come with the .apk file.

      And so there it is: the exact argument for a Curated Collection (a/k/a "Walled Garden")...

      Thank You.

    22. Re:A less biased source please? by macs4all · · Score: 1

      Same thing happens in iOS, except you don't know it is doing so. Try a jailbroken device with PMP (Protect my Privacy), and you will see that a lot of iOS apps do a lot more phoning home than you would think.

      Log files, or it didn't happen.

    23. Re:A less biased source please? by Anonymous Coward · · Score: 0

      This is a problem the Android security team recognizes and is working to address, in various ways that I can't go into.

      That's okay, we all know how you're going to solve it: the same way you solve everything else ... by copying what Apple did. (OMG spoiler alert!)

    24. Re:A less biased source please? by fluffernutter · · Score: 1

      Tracking is not harmful, it is creepy. It is doing something no person should ever feel the need to do to another person.

      If you are the type of person who will do it, you are not likely to see the fault in your actions.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    25. Re:A less biased source please? by TheRaven64 · · Score: 1

      I'm sorry, but I simply don't believe you (by the way, is the 'Android Security Team' still six guys, or did you recruit some new people / start talking to the main Google security teams?). If Google cares so much about my privacy, then why does the 'enable Google tracking my location' dialog box have a 'don't ask me again' option that's only enabled if you select 'yes' and not if you select 'no'? This is a relatively recent change in newer versions of Android: previously you could permanently disable the dialog if you selected 'no', so someone in the Android team has made a conscious decision to make it harder to opt out.

      Why do you still not, as Symbian did almost two decades ago, allow permissions to be removed form an app or enabled on a single-use basis? Why have you changed the permissions display in the UI to be less informative? Why do your developers know so little about the importance of API security that app developers don't have an easy way of determining the permissions that they need? This isn't exactly a new problem and there's a vast amount of research literature on how to do it better.

      --
      I am TheRaven on Soylent News
    26. Re:A less biased source please? by Anonymous Coward · · Score: 0

      Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.

      You are brainwashed. It's true this is one of their corporate principles (which were put in place by the FTC's consent-decree after Buzz, by the way), but it's untrue that the Android permissions system, and the iterations Google has done on that system, reflects this principle. Slipping into corporate-principle land and spilling the present discussion's context on the floor when it becomes uncomfortable is what I call "brainwashed."

      Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not.

      I see your view, but something that would be clearly classified as "spyware" by a virus and malware scanning tool on a desktop is legit in Android, and the reason Google has drawn the line where they do is to encourage developers and the "ecosystem" at the user's expense.

    27. Re:A less biased source please? by Anonymous Coward · · Score: 0

      your privacy does have value to you, and that you should be able to decide what you'll trade it for.

      Right, you in Android see the permissions screen as a bargain: the developer can be sure the user doesn't get the app unless she hands over all the data the developer wants. No holding out: phones don't have profiles the way browsers do, so all the accounts you add go into one big bucket. No lying to the app: phones don't have cookie-clearing or location-faking, and if you write an app that implements it Android Security Team will ban your developer account for life. Basically you are policing a platform that monetizes user's private data. You tell us you're protecting the user, but you're not. You're protecting the developer.

      Yes, you sometimes enforce against developers, but in a meaningless way compared to what's really going on with phones. Your enforcement creates the appearance of order and legitimizes the wholesale harvest of private data that's happening on mobile, and you rationalize it to yourself with this bogus idea of a trade of data for "something".

      You in Android are the reason people believe Google sells their personal data to advertisers. They believe it because, on Anrdoid, you _do_. But people think the rest of Google does this on their ad platform, too. It's just Android that has this idea that users are trading their privacy. The rules for user data in the rest of Google don't embrace this idea of controlling a marketplace where data can be traded away: the rule is to put the user first always, and the rest will follow. You don't live up to that.

      Android security team recognizes and is working to address, in various ways that I can't go into.

      It has been this way for years. The web and Cyanogenmod have already figured this out. You're making it complicated on purpose to stall, and I don't trust your judgement.

    28. Re:A less biased source please? by Aighearach · · Score: 1

      The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google.

      Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not.

      Nonsense. Broaden the meaning of the words until what I said sounds like a true statement; good, now you've understood my statement. ;)

      Like you admit, if you attribute it to laziness you just assume there is no problem. It would be harmful for google to actually try to address the problem, because the only solution for lazy developers would be to inconvenience them in some way; kick their apps out until they fix their permissions. Your whole statement just reinforces my original view; the problem is addressed only in the area that google gets blamed for ("malicious" apps) and totally ignores the problem that hurts users more: incompetence that turns any app security bug into super-malware. Your position makes perfect sense, if the PR of the Google Play Store is the concern.

      And history of walled garden software repositories shows that this approach results in malicious parties putting their apps in without the bad parts first, then later making changes in updates. If you're accepting security problems as long as they are only lazy mistakes, you're not protecting against much. The first wave of security work is just enabling the second wave of attacks in that case. The same thing as is happening to advertisers. Google is what it is today mostly because of text ads; there is no malware vector. Everybody else gives power to advertisers to spew HTML blocks at customers, and it is full of malware. Reviewing the ads in advance isn't helping the competition. Google's left hand doesn't have the wisdom of the right hand, unfortunately.

      With f-droid though, I can just download the source code, remove the permissions, recompile, and install by hand. Done and done.

    29. Re:A less biased source please? by Aighearach · · Score: 1

      Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.

      So when are you going to give us the ability to disable permissions on a per-app basis? You know, like you added to the OS a few revisions back, then took away again?

      This is the biggest single reason I recommend people not to buy Android these days if they ask. I'm sick of apps asking for all kinds of permissions that I don't want to give them, and not having any way to block them.

      That really blasts their Pollyanna "it's all roses" line out of the water. If they hadn't made something that was really great on a technical level, that can give us what we want, and then scaled it back so we can't have it... then I'd still be listening to their line. A few short years ago there was nothing I loved more than a new Google API. Now, it reads the same as "Microsoft API," e.g., something I may have to be aware of at work, but not the thing we're actually going to be using.

    30. Re:A less biased source please? by Aighearach · · Score: 1

      To expand on this:

      If they wanted to add to the dev tools the capability to auto-generate permissions by running the app in a sandbox, measuring what permissions it actually used, and then generating the manifest, that would be easy to do. In fact, you could just have a test suite that exercises all the app features to drive it. That way for people who write tests, they would get tailored permissions for free; and any missing permission would be parallel to a missing test, and so it would help mitigate bug escalation.

      I'd be happy to write it for them, except that the terms of using their dev tools prevents me from writing dev tools. If they decided it was harmful or encouraged forking, I could be banned from even compiling apps with their toolchain. If google was the same company today that they were when they first wrote Android, I'd probably already have put out a version of this sort of tool.

    31. Re:A less biased source please? by Aighearach · · Score: 1

      While I mostly agree with you, there are location-faking apps out there. Probably require root, but on the Google-branded devices that is easy to get since they are unlocked. It doesn't really help much, though.

      The ironic thing is that when it comes to Google's money-maker, advertising, they're the only company that protects the consumers data. (by keeping it to themselves and being the middle-man) And then when it comes to their platform, they started with that philosophy, then changed their ways and features, and now they conspire with the app devs to help those app devs get direct access to the users private information. They seem totally ignorant of the fact that this leaks into their whole brand, that it takes their strongest feature from their biggest money-maker, and destroys the trust it built.

    32. Re:A less biased source please? by Anonymous Coward · · Score: 0

      Yes, but Google gives you the choice; a simple settings parameter will allow you to step outside that walled garden (giving me hesitation to even term it as such) while Apple requires you to jailbreak your phone, which they forbid and actively try to prevent.

      For billionth fucking time.

    33. Re:A less biased source please? by Anonymous Coward · · Score: 0

      For the*

      Also, Macs4all (the most depressing notion ever mentioned in technology), have you ever administered users in a Mac environment? I have. It made me want to leave IT.

      "How do I do [this], [this], and [this]?."
      My answer was generally one of the following 3 statements: 1. You can't because it's so easy, it's somehow super fucking hard. 2. You can, but you'll have to type your password about 4-10 times during the process, so enjoy that. Or 3. Install Windows and you can get that functionality."
      "I don't like that answer."
      "Then why did you choose to spend 2-3x on a Mac?"
      "It's a MAC, man! Look how pretty it is!" ...

      Someone should punch these people in the fucking face for having more money than sense.

    34. Re:A less biased source please? by Anonymous Coward · · Score: 0

      lolwut? Your hero in your privacy war against Google is...Apple?!

      HOLY FUCK THAT'S HILARIOUS.

    35. Re:A less biased source please? by macs4all · · Score: 1

      ...have you ever administered users in a Mac environment? I have. It made me want to leave IT.

      Why yes. Yes I have. In a mixed environment with Windows, so I know the difference.

      In that particular case, the Windows:Mac ratio was only about 2:1, yet the trouble-ticket ratio was about 50:1, with Windows being the "50", of course. And no, it is not a reflection on my IT skills in either environment; nor of the relative complexity of the tasks to which the machines of each OS were put; but rather a testament to the stability and ease-of-use (or lack thereof), of each.

      . And judging from your responses and attitude, I would say that it is clear that you never bothered to learn how to Admin Macs, and so were stuck forever trying to figure out how to Admin Macs like Windows machines; which obviously frustrated both you and your unfortunate users. No wonder you were frustrated; hoping to death that your superiors wouldn't find out just how lame you were/are.

      I have, at various times since Windows was DOS and Macs were Lisas, both used and administered both platforms in a huge variety of applications, including, but in no way limited to, such "swimming-uphill" ones like doing embedded software and hardware design on old-school Macs (it's a lot easier now), to doing desktop publishing on Windows, and absolutely everything in-between. I currently write Windows application software, and Admin several Windows servers (and the occasional Windows desktop) across several versions of both.

      What I am saying is that you'd better improve your understanding of Macs and OS X; because, they're here to stay (just like Windows). So, the next time you feel enraged at a "stupid Mac user" (and, just like stupid Windows users, they most certainly exist), you can stop, take a deep breath, and actually try to help, rather than berate, them, ok?

      Or perhaps, you should just listen to your heart and simply leave IT; because you aren't doing it right.

    36. Re:A less biased source please? by macs4all · · Score: 1

      Yes, but Google gives you the choice; a simple settings parameter will allow you to step outside that walled garden (giving me hesitation to even term it as such) while Apple requires you to jailbreak your phone, which they forbid and actively try to prevent.

      For billionth fucking time.

      WOOSH!

      You were so filled with Apple Hate that you completely missed the point: That, perhaps that, even given the choice (which I bet most Android users actually don't tKe advantage of anyway), the number of times that going outside of the Garden would solve an actual need for all but the most esoteric of uses, is so vanishingly small, that it just doesn't make sense by an overwhelming margin.

      Typical egotistical slashdotter; what's good for me must be good for the platform...

    37. Re:A less biased source please? by tepples · · Score: 1

      However, it lets them look at what all your network connections are.

      Is ACCESS_NETWORK_STATE too intrusive? If so, what's the preferred way for, say, a mail client to determine when a device has an Internet connection in order to start downloading updated information in the background for later use while offline? Should users have to install an additional helper app from Google Play Store for each potentially intrusive permission that a main app might optionally use? Or do you think apps shouldn't allow for background updates in the first place?

    38. Re:A less biased source please? by Aighearach · · Score: 1

      If the purpose of the app is not to manage network connections, then that is useless information. It is just supposing that you should check first, without any reason.

      A key thing to understand is that checking if the OS says a connection is up doesn't mean your connection will succeed or that there is really a real connection. The networking technology is already designed to deal with that. You have to have error handling already. Checking the network connection first is silly, it adds extra code to bug out, and redundantly covers the same condition that the regular networking code handles. You may not be able to connect to the server. The way to find out if you can connect is by connecting. That is the same as on a desktop computer. I've never once encountered a desktop or server app that wants permission to fiddle or list my network connections before trying to use a network resource. You open your port and do your thing, if the connection isn't up, you handle the error.

      You're supposing you'd have an extra helper app to do the thing instead, but actually you just rip that crap code out, and use the error checking you already have in place right after it.

      In the case of a mail app, maybe a user wants it to be aware right when the connection is available. And maybe they're happy with it trying again after a minute. That is not a problem. That is a reasonable use case for the feature.

      However, almost every app that uses the network wants to read the connections. The vast majority of those do not need the permission. I personally would let an email app do that. But lots of other apps I choose not to install because they asked for ACCESS_NETWORK_STATE and that isn't a feature they should be using.

  4. PHA? by jbmartin6 · · Score: 1

    If it was possible to identify all the PHAs antivirus would still be 100% effective. Not to mention the varying definitions of 'harm.' For instance, i consider all the apps wanting to take my IMEI harmful, and I doubt Google counted these as 'potentially harmful'.

    --
    This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
    1. Re:PHA? by Anubis+IV · · Score: 1

      They don't claim 100% accuracy, but they readily admit in the paper that they aren't an oracle who can immediately recognize PHAs on sight. Rather, the capture data for all app installations, and then as apps are flagged as PHAs later (most of which happens within 60 days, according to them), they're able to make sense of the data to understand what percentage of installs were for PHAs. I.e. They're using hindsight to provide accurate data, rather than relying on the information they had at the time.

  5. its not the apps, its the os I worry about by TheGratefulNet · · Score: 2

    the great Short Attention Span Company(tm) EOLs phones like there's no tomorrow. my older google phone is stuck at android 2.x and will never get updates. I don't care about features, but I'd like kernel, ip-stack and some onboard apps to have fixes for security.

    it won't ever happen. we don't really own our phones. and we are suppose to keep landfilling perfectly fine hardware - to keep the monsters in high profit.

    even if I ran no apps at all, the os is buggy and full of weaknesses. I'm sure I could be attacked with an old 2.2 android os, probably in just a few minutes time.

    this is why I hate phones and have zero interest in spending more money and time on this crap. the ceo's might have gotton it right: use dumb feature phones and be more secure!

    --

    --
    "It is now safe to switch off your computer."
    1. Re:its not the apps, its the os I worry about by Anonymous Coward · · Score: 0

      So you're using a 4+ year old phone, and you expect us to care? I buy a new phone about every year. They are not that expensive.

    2. Re:its not the apps, its the os I worry about by Coren22 · · Score: 1

      we don't really own our phones.

      This is a result of you owning your phone. If you were renting the phone, they would be expected to keep it up to date, instead, you buy it and they wash their hands of it. This is not as much a problem with Google as it is a problem with carriers. The carriers want control, so they get it and cause phones to be end of life'd quicker.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
    3. Re:its not the apps, its the os I worry about by swillden · · Score: 1

      the great Short Attention Span Company(tm) EOLs phones like there's no tomorrow. my older google phone is stuck at android 2.x and will never get updates.

      You're still using a Nexus One? Even the Nexus S got upgraded to 4.1. Serious kudos on keeping that five year-old phone running. Do modern apps run on it?

      From a broader perspective, while I think Google should probably do a little better at updating older Nexus devices than it has, it's really not that bad; the Nexus 4 and first-gen Nexus 7 got Lollipop (though it doesn't run all that well on the N7v1), and I suspect that if it weren't for the fact that the SoC vendor is gone, the Galaxy Nexus would have as well.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:its not the apps, its the os I worry about by Anonymous Coward · · Score: 0

      personally, im using a desire Z with a 4.0 rom on it... still cant find a reason to replace it, its not even slow :X (well, its slow for games but i prefer to not game on a phone) almost 5 years old aswell

    5. Re:its not the apps, its the os I worry about by Anne+Thwacks · · Score: 1

      Go back to your bedroom. Loads of people think five years is still a child. I am writing this on a ten year old laptop, and regularly use a 10 year old Nokia phone (I have a new Samsung, but quite often I need to be away from the mains for more time than 3 spare batteries allow.

      Electronics does not rot or rust, and in the absence of a hard disk or CDrom drive, should last 30 years.

      I see no reason why Google should have to maintain old devices. However, I do think that if a manufacturer EOLs a device, which might pose a security threat to others (by hosting malware) they should be required by law to release all the technical details that could possibly be required by third parties to support the device They cannot have it both ways.

      --
      Sent from my ASR33 using ASCII
  6. That's Still A Lot by Immerial · · Score: 2

    Even .1% of a billion devices, is still a lot of devices affected. Even that is still a very conservative number: lowest rate listed and a very small number of devices. This says there are ~1.6 billion phones (http://www.statisticbrain.com/android-phone-statistics/), which doesn't include tablets or any other devices. So percent-wise .1% sounds great... but numbers-wise I hope they get that percent even smaller ;) Just saying...

    1. Re:That's Still A Lot by Anonymous Coward · · Score: 0

      Yeah, 1% is terrible. What percentage of Chrome OS is infected by malware?

      And whatever that number is, how much of that percentage comes from importing Android's broken "app store" with its trade-personal-data-for-access permissions system as the Web Store? From what I heard, the main (only?) security problem with Chrome OS in practice has been malicious extensions, or non-malicious extensions that the developer sells to someone evil so the new owner can auto-update it into a data-stealing app.

  7. Make sense by danbob999 · · Score: 1

    While I have seen a lot of viruses on Windows PCs, I have never seen an Android "harmful app" or virus. They probably exist, but I tend to believe that they are only installed on less than 0.5% of Android phones.
    I've seen a lot of crapware with too much permissions and lots of ads, just like on iOS, but nothing the user didn't agree with.
    Soon enough, all these apps will be forgotten and replaced by better alternatives, just like nobody still use WinZip or any other file archiver with a nag screen.

    1. Re:Make sense by Coren22 · · Score: 2

      Take a look at the permissions your average (free) flashlight app requests then reconsider your definition of harmful.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
    2. Re:Make sense by Anonymous Coward · · Score: 0

      I'm not sure what you mean by average. The tiny one on F-Droid requests no permissions at all.

    3. Re:Make sense by danbob999 · · Score: 1

      Flashlight app? I use the one built-in to my OS.

    4. Re:Make sense by Coren22 · · Score: 1

      Me too, but that is a newer thing, many of the older phones did not include that. I was pointing out that there are many definitions of harmful.

      https://www.youtube.com/embed/...

      According to this guy, the most popular free flashlight apps steal your personal information and transmit it to other countries. It makes for an interesting spy gadget for them apparently.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
  8. I can believe this by Needs2BeSaid · · Score: 1

    All of the Android phones I've owned had huge space limitations (can not install to the SD card) which keeps me from installing and playing with many potentially dangerous apps. Hey, Google, why can't I install apps to my SD card?

    --
    Some things need to be said...
    1. Re:I can believe this by Anonymous Coward · · Score: 0

      A lot of Gingerbread phones had limited internal storage, but most of them let you "adb shell pm set-install-location 2" to install apps to the SD card.

    2. Re:I can believe this by Aighearach · · Score: 1

      You're probably asking the wrong company. Ask the company who built your device. The google branded Nexus devices don't have that limitation.

    3. Re:I can believe this by Anonymous Coward · · Score: 0

      But... but.... but.... itz teh Linuxxzxxx!!!!!!1211123

    4. Re:I can believe this by Anonymous Coward · · Score: 1

      Kind of weird to say the Google branded devices don't have the limitation of not being able to install apps to the SD card, when they don't have an SD card at all.

    5. Re:I can believe this by chadenright · · Score: 1

      On my tablet, the SD card went under the SIM chip. You may be able to put an SD card into your phone, but it may not be immediately obvious where it goes.

    6. Re:I can believe this by chadenright · · Score: 1

      On my smartphone, I mean.

  9. Yeah, but where's the money? by Anonymous Coward · · Score: 0

    There might be twice as many Android users out there, but iOS accounts for 85% of the revenue collected from apps.
    There might be less than one percent Android users that are running around with infected phones, but there's nearly half a billion iPhone users and thanks to Apple's business model there's zero known infected phones. The only way to infect your iPhone is to jailbreak it first, then you can install whatever malware you want.

    It's fun to imagine other industries coming out with such nonsense statements. Less than one percent of our cars sometimes drive off a cliff on their own. Less than one percent of our televisions watch pay per view automaticly. Less than one percent of our airplanes sometimes run into buildings. Less than one percent of our prostitutes have STDs. Less than one percent of our staff will steal your identity and your stuff.

    1. Re: Yeah, but where's the money? by Anonymous Coward · · Score: 0

      Android is still behind, but not 85% anymore. The sheer number of android devices is helping this. Benedict Evans has published this recently I believe. For the record, I'm an iOS person.

  10. Definitions by Anonymous Coward · · Score: 0

    I see that their definition of "potentially harmful app" doesn't include those which send whatever personal data they can get access to into the "cloud". IMHO there are hardly any Android apps that are not potentially harmful, except those in the open source F-droid.org "app store". Of the top 40 apps in the Google app store, only Avira Antivirus and WhatsApp don't have one of the ad trojans embedded, but of course one is snake oil and the other is an app that only an exhibitionist wouldn't find offensive.

  11. Fixed: Less than 10 million... by uberbrainchild8437 · · Score: 1

    Google: Less Than 10 Million of Android Devices Are Affected By Harmful Apps Doesn't sound so nice now does it

    --
    http://Anveto.com - Web Design, SEO, Marketing, Analytics & Security
  12. Rooting .NE. Sideloading by frovingslosh · · Score: 1

    Rooting applications are installed on about 0.5% of devices that allow sideloading of applications from outside of Google Play.

    When an article (and a summary) include garbage like this, I refuse to take the rest seriously. Rooting is not Sideloading. There is a feature right in every stock Android system that tells Android that it is OK to accept Apps from sources other than Google. There are apps included with factory fresh Android that will install these apps as long as the user has chosen to allow it. This is how things like the Amazon app store work, which I have on every one of my Android devices even though none of them are rooted.

    If the article can't get this right, and I know it is wrong, then I don't even want to risk exposure to bad information that I might not know enough to reject.

    --
    I'm an American. I love this country and the freedoms that we used to have.
    1. Re:Rooting .NE. Sideloading by Anonymous Coward · · Score: 0
      Wow, that's a pretty spectacular reading comprehension fail. Let's try changing the formatting a little.

      Rooting applications are installed on about 0.5% of devices that allow sideloading...

      That sentence states, among devices with sideloading enabled, 0.5% also have a rooting application installed.

  13. Depends on one's definition of malicious by Anonymous Coward · · Score: 0

    If one is is interested in privacy then the continuous monitoring by Google is clearly a malicious invasion of it. This is built into the core of Android though, so there aren't many good alternatives other than to avoid it altogether.

    A halfway house is to avoid some of Android's insecurity by design and and the privacy leakage of Google Play by installing only free and open source apps from F-droid. While this can provide some confidence that apps are not phoning home and other malicious things, it does nothing about the core operating system itself. Big Brother Google is still in charge.

    Maybe one day Schmidt will have his Android device hacked and will then tell Google techs that they have to do something about Android security, especially add a firewall and jail all apps in individual Linux containers.

    What he's never going to do though is to give users total control over what applications can do post-installation, because their lack of control is what empowers app developers and hence brings in Google profits. That conflict of interest is at the heart of Android's security/privacy problems.

    1. Re:Depends on one's definition of malicious by iamacat · · Score: 1

      Dude! You are full of it, and besides you are an F-droid shill based on at least 3 posts promoting whatever it is in this thread.

      Android already puts all apps in sandboxes. It also happens to be open source, so you can put on a tinfoil hat and hack a custom ROM to your hearts content, including denying apps you don't trust any network or shared storage access.

      And if you want to be taken seriously, give an example of how core OS or Google Play specifically violated your privacy. Most people voluntarily store their e-mail and photos on the cloud and use GPS navigation that tells server their whereabouts. What information is being leaked from your phone that is MORE private than that? More importantly, how is it being linked to you specifically and misused?

  14. Thats because the new android rendered em useless by Anonymous Coward · · Score: 0

    it now takes 6 minutes for my tablet to become usable after i open the lid.

    Thanks android patch :P

  15. 1% = several million by 140Mandak262Jamuna · · Score: 2
    How to lie with statistics, trick number one.

    95% of the brand A cars build in the last 10 years are still one road, does not mean brand A cars have a 95% chance of lasting 10 years. Only 10% of the cars built over the last 10 years is likely to be 10 years old. So they could be talking of just 50-50 chance of their cars lasting 10 years.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  16. 1% by Anonymous Coward · · Score: 0

    1% of (assuming by now) billions of devices is a lot of compromised devices.

  17. Define "harmful app" by sunderland56 · · Score: 1

    An app that you don't want, is completely useless, that consumes storage space, but is not removable - that, to me, is harmful. By that measure, 99.9% of Android phones contain harmful apps.

    Just wait until one of the cannot-be-uninstalled apps comes up with a major security vulnerability. That's going to be fun to watch.

  18. How many million in 1%? by Anonymous Coward · · Score: 0

    As of June 2014 there were 1 billion active Android users.

    That makes 1% equal to [drum roll] 10 million devices as of 10 months ago, so the current number is bigger. That's NOT an insignificant number, Google. Do something!!!

  19. Never trust the compromised by manu0601 · · Score: 1

    What do they actually count? When a device was compromised, the attackers should cover their tracks and the device should be difficult to identify as being compromised.

    In other words, there is no "compromised' flag to easily identify on devices. Which leads to the question: what does Google's number mean?

  20. Lies by Anonymous Coward · · Score: 0

    Yea....that data is coming from Google who has a history of lying! Yea I believe that! 97% of the malware is for android and most android users are on older devices without patches on them and some bugs Google refuses to fix! Please sell me another lie!

  21. "Phone status" to avoid the OOM killer by tepples · · Score: 1

    "Phone status" sounds like it is about the current status, but actually that exposes all the numbers you call, when, for how long, etc.

    Perhaps it's just to give the app advance notice to autosave the user's unsaved work in case the app gets forcibly OOM-killed by the dialer app on an underpowered device. The problem is with Android itself: the permission for "tell when the phone is ringing" is conflated with too many other capabilities.

    And the same app will ask for full network access, even though if you look at the traffic, almost all of them are using HTTP to talk to their services

    Your app still needs "full network access" if you want it to do anything other than open web pages in a web browser. Or were you planning on opening a web page in a web browser to send the data to the server and then having the server redirect the browser back to a custom URL scheme that sends the data back to your application? That'd certainly be a circuitous route just to avoid a permission.

    1. Re:"Phone status" to avoid the OOM killer by Aighearach · · Score: 1

      There are other mechanisms to save work. Also, the whole platform requires you to assume you can be interrupted at any time. This is almost entirely mitigated by the API giving you a sqlite database to store all your crap in. It will still be there. The part the user is interacting with is just a viewer, it is not the core of an app.

      It is absolutely, unquestionably, an awful app that would try to use it as you describe. The platform isn't designed to tell you what is happening and to preserve your running instance until it tells you otherwise; and the vast majority of causes of your app getting whacked don't have any warning, or some side-channel thing you check to see why. You just close the GUI part, serialize your data in the backend process, and you're ready to either get control back, or have the backend killed by force, either of which is possible without any error state.

      The only app that needs to know the phone state is a dialer app, or something else that is intended to be used as a phone interface. The feature they want is not any of that. They reason it is requested is because they bundled the device ID with the phone status. So any app that you want to be able to identify your device, for example to save a high score on a server, or auto-login to a game server, is to also give that app access to all the numbers you call, all the numbers that call you, etc.

      The main use of the feature has nothing to do with your phone number or your contacts, and yet it leaks that data. It is too big a conflation to believe it is accidental. The only logical answer is that Google intends to leak all the numbers called to all the apps that have an interest in identifying a device. So basically, anybody that wants to track your use of their app on your device, also gets to track all the numbers you call. And it is specifically designed to work that way. They put engineering hours into combining these things, bundling them together. It is not an accident.

      Also, no, you don't need "full network access" to access anything outside a web browser. You only need it to go off port 80 HTTP. You can still just use a subdomain for the remote app API. You're conflating two different permissions.

  22. How else to put food on the table? by tepples · · Score: 1

    If not through advertisement, then how do you expect a developer to recoup the cost of developing an application for distribution without charge?

  23. Permissions by thetoadwarrior · · Score: 1

    Even if that number is correct that goes by google's definition. I'd say many of the apps in their own store are harmful because they ask for too many permissions and you have little you can do about it thanks to google's all or nothing approach to permissions.

  24. For both OOM killer and battery use by tepples · · Score: 1

    Also, the whole platform requires you to assume you can be interrupted at any time. This is almost entirely mitigated by the API giving you a sqlite database to store all your crap in. It will still be there.

    Would it be prudent for the application to COMMIT the SQLite database after every single character the user types, every single brush stroke in a drawing program, or every frame of a real-time video game, just in case the backend is killed by force? If not, what would be an appropriate compromise?

    The only app that needs to know the phone state is a dialer app

    Another problem conflated with "phone state" is whether the user is connected to the Internet at all. Say an application is designed to retrieve data from the Internet when the user happens to be momentarily connected to the Internet. Checking every minute would waste battery. So how should an app request to be notified when an Internet connection becomes available? Or is the application's developer expected to operate a server that acts as a proxy to perform this polling process and then send push notifications through Google Cloud Messaging to the application?

    Also, no, you don't need "full network access" to access anything outside a web browser. You only need it to go off port 80 HTTP.

    For one thing, where is this documented? Google android http without internet permission didn't appear to turn up anything relevant. For another, "port 80 HTTP" allows a passive attacker to view private information being passed between the client and the server and an active attacker to change said information. Does port 443 HTTPS require "full network access"? If not, then where is this documented?

    1. Re:For both OOM killer and battery use by Aighearach · · Score: 1

      sqlite doesn't work that way, and file write buffers don't disappear and lose data when an app is killed. That is LOL-level stuff, man.

      Googling the details of a specific issue in programming for an API may not return useful results when you're not a programmer in that area. However, your ignorance doesn't demonstrate anything. It actually refutes the idea that you're even disagreeing with me, or participating in the conversation. You don't understand the details, so you'll have to take my word for it; or not. But it won't affect me, and it won't contribute anything to the discussion for you to choose a side you don't understand.

      If an app is claiming not to need or use personal information, why would the programmer be worried that it has to download its publicly, anonymously available data files over HTTP? A sensitive user would be using a VPN anyways, and the apps wouldn't need to worry about it. A user whose HTTP traffic just goes out the default unencrypted connection, they're not benefiting by somebody asking for extra permissions to view their private data... in order to hide their anonymous data access. That is a totally absurd combination of claims.

    2. Re:For both OOM killer and battery use by tepples · · Score: 1

      sqlite doesn't work that way

      Let me rephrase in a way that doesn't depend quite as much on the technical details of a particular platform: How many seconds of the most recent work do users expect to accept losing when an app is killed?

      file write buffers don't disappear and lose data when an app is killed.

      My experience differs, at least on a different platform. When I was in college, I used a schematic capture program called LogicWorks on the Windows operating system. If the user added a part to the parts library file or modified a part in the parts library file, and then shut down LogicWorks uncleanly (such as a crash, End Task in the Task Manager, or power failure), LogicWorks would corrupt the parts library file. It appears to have been writing to the parts library file without calling the equivalent of fflush(parts_fp), which caused an inconsistent state on disk when the last part of the update was not committed.

      However, your ignorance doesn't demonstrate anything.

      Nor does your unwillingness to help other readers of this thread.

      If an app is claiming not to need or use personal information, why would the programmer be worried that it has to download its publicly, anonymously available data files over HTTP?

      My assumption was that the user would create a username and password and then decline to specify any real-world personal information for account recovery. The user still expects that the communication be authenticated and private even though not associated with a real-world identity.

    3. Re:For both OOM killer and battery use by Aighearach · · Score: 1

      sqlite doesn't work that way

      Let me rephrase in a way that doesn't depend quite as much on the technical details of a particular platform: How many seconds of the most recent work do users expect to accept losing when an app is killed?

      LOL no, that won't help you understand any better. At best it helps you sound less ridiculous. What would the use of making technical comments with less understanding be?

      file write buffers don't disappear and lose data when an app is killed.

      My experience differs, at least on a different platform. When I was in college...

      Woah there cowboy, maybe the crap you used in college just sucked, eh? You mention windows, so I have to tell you... other platforms already had buffers and shit that didn't suck. Sorry you had... whatever it was... happen to you. But it doesn't help you understand the issue on the Android platform where you have to expect things to get killed on you at any time, and you won't get warning. Your fantasy that people ask for phone status in order to flush their buffers is funny. But it is not correct, or close, or even a small part of what is happening here. And Android does usually give you a small window of time to flush your shit before it kills you. But guess what? When you get the status change, that stuff already happened. That is information you get afterwards, not information you get in advance. It isn't helpful in the way you imagine.

      If an app is claiming not to need or use personal information, why would the programmer be worried that it has to download its publicly, anonymously available data files over HTTP?

      My assumption was that the user would create a username and password and then decline to specify any real-world personal information for account recovery. The user still expects that the communication be authenticated and private even though not associated with a real-world identity.

      Well, then your assumption is invalid wherever the app doesn't require a login. So if you have to concede that my point is sometimes valid, you can then also address your arguments about it to the cases where it is valid. You know, the cases I was talking about.

    4. Re:For both OOM killer and battery use by tepples · · Score: 1

      LOL no, that won't help you understand any better.

      Then what would help me understand better? I'm trying to be sincere here. How do apps normally avoid loss of the most recently entered data in case of a shutdown that effectively already happened, such as the last keystrokes before the app is killed? The sequence is supposed to be pause, stop, destroy, but I've read that the OOM killer occasionally skips these steps when under severe memory pressure.

      Well, then your assumption is invalid wherever the app doesn't require a login. So if you have to concede that my point is sometimes valid, you can then also address your arguments about it to the cases where it is valid.

      Apps that do not require any login whatsoever are likely to be read-only. Read-only apps can use ad-hoc encryption and signing of responses tunneled over cleartext HTTP. I concede this.

      But I still see no evidence for your claim of being able to communicate using cleartext HTTP without the INTERNET permission. An answer to this question states that HttpURLConnection requires INTERNET. Google's networking tutorial mentions techniques that require INTERNET. The answer to this question states regarding INTERNET: "Any application that accesses the internet for any reason will have to request this permission."

      I concede that I haven't read the entire Android API docs from cover to cover. Is that required before you're willing to begin to help me? If not, what level of familiarity is required?

    5. Re:For both OOM killer and battery use by Aighearach · · Score: 1

      Because in Android development you're required to use a different paradigm that assumes the app the user is interacting with will be killed at any moment. So there is no important work being done in that process. The important work is being done in a background process that is lightweight and doesn't need to get killed when the app interface is killed.

      If the phone status changing causes the app you were using to be killed (the most recent app used will actually not be killed then, but the penultimate app is likely to be) then that user interface just gets whacked. But the background process of the app won't get killed then; that only happens if the OS is truly out of resources and apps are crashing from lack of RAM. And even then, it triggers a callback and you have a few milliseconds to save your stuff in the background app.

      So there is no connection between the phone status and saving stuff; and when there IS a need to save stuff, you get a callback activated. You would never be able to monitor the phone app from the front end process that gets killed, because the status would change first; the phone rings, the dialer app preempts your user interface, and you interface is already gone (if you're out of RAM) or switched to the background if not. And the backend already can get a callback to tell it that the front end went away; there is no utility in trying to figure out "why" because the whole programming paradigm requires assuming the front end interfaces will be killed frequently, and without notice. This is why there is a lot of emphasis on XML layouts. Traditional GUI apps it doesn't matter, you can generate widgets programmatically at application start. But with Android those would be regenerated constantly because the GUI part of the app is killed and restarted frequently.

  25. It's about saving battery power by tepples · · Score: 1

    A key thing to understand is that checking if the OS says a connection is up doesn't mean your connection will succeed or that there is really a real connection.

    I'm aware of that. I just wanted to find a way for the app to know when it is worthwhile to spend the device's battery charge on attempting to sync.

    The way to find out if you can connect is by connecting.

    Every five seconds? If not, then how often?

    That is the same as on a desktop computer.

    The key difference is that unlike a mobile device, a desktop computer has essentially unmetered energy. In addition, a desktop computer's Internet connection is far more likely to be always-on, unlike a laptop or tablet that gets used in a moving vehicle.

    And maybe they're happy with it trying again after a minute.

    If the app keeps "trying again after a minute" for four hours, some people might argue that that's 240 wakeups too many.