Showing 23 posts tagged android
Showing 23 posts tagged android
What are Google’s Nexus devices for if not to be purchased by large numbers of consumers? Google’s take on that issue has been consistent: they’re “halo” devices meant to educate the rest of the ecosystem. Burke put it to us this way: “Basically what Nexus allows us to do is set the standard … [we can] demonstrate how Android runs and hopefully influence other device manufacturers to take what we’ve done and do even better.”
That explanation has often been difficult to take at face value. Though the phones have usually been elegant devices, they typically launched with specs that were behind the curve. The Galaxy Nexus had a pretty terrible camera, for example, and the Nexus 4 lacks support for LTE. Now that Google sells top-end “Google Play edition” phones that run stock Android, the Nexus line seems more irrelevant than ever.
That brings us to the other — and more important — reason the Nexus line exists: Google simply needs hardware on which it can develop Android. Burke says “as an engineering team creating a mobile platform — we can’t do that in the abstract. We need to do it on a real device that we’re carrying with us.” When people ask me about the Nexus line, I like to joke that if you need to create a few hundred polished and usable devices for Google engineers, why not make a few hundred thousand more and sell them to hardcore users?
– I think that acknowledging Google wants to control some of its own hardware for internal development purposes - as well as to better enable external developers to produce software for Android - continues to strike to the heart of why the ‘Nexus’ line exists. Arguably the recent ‘Play Edition’ of manufacturers’ flagships phones could address consumers’ desire for stock Android experiences, but I don’t think that the Play Editions will fully satisfy developers’ interests in working from a stock, no-nonsense, quickly updated platform.
Android fragmentation is a very real problem; not only does it hinder software developers’ abilities to build and sell apps but, also, raises security issues. In a recent report from Open Signal, we learn that 34.1% of Android users are using the 2.3.3–2.3.7 version of Android, whereas just 37.9% of users using 4.x versions of the operating system, most of whom are themselves using a years-old version of Android. In effect, an incredibly large number of Android users are using very outdated versions of their mobile phone’s operating systems.
It’s easy to blame this versioning problem on the carriers. It’s even easier to blame the issue on the manufacturers. And both parties deserve blame. But perhaps not just for the reasons that they’re (rightly!) often crucified for: I want to suggest that the prevalence of 2.3.x devices in consumers’ hands might have as much to do with consumers not knowing how to update their devices, as it does with updates simply not being provided by carriers and manufacturers in the first place.
Earlier this month I spent some time with ‘normal’ gadget users: my family. One family member had a Samsung Galaxy S2…which was still using version 2.x of the Android operating system. Since February 2013, an operating system update has been available for the phone that would bring it up to Android version 4.1.2, but my family member neither knew or cared that it was available.
They didn’t know about the update because they had received no explicit notice that an update was available, or at least didn’t recall being notified. To be clear, they hadn’t updated the phone even once since purchasing the device about two years ago, and there have been a series of updates to the operating system since purchase time.
The family member also didn’t care about there being an update, because they only used the phone for basic functions (e.g. texting, voice calls, the odd game, social networking). They’re not a gadget monkey and so didn’t know about any of the new functions incorporated into the updated Android operating system. And, while they appreciate some of the new functionality (e.g. Google Now) they wouldn’t have updated the device unless I had been there.
A key reason for having not updated their phone was the absolute non-clarity in how they were supposed to engage in this task: special software had to be downloaded from Samsung to be installed on their computer, and then wouldn’t run because the phone’s battery had possess at least a 50% charge, and then it took about 3 hours because the phone couldn’t be updated to the most recent version of Android in one fell swoop. Oh, and there were a series of times when it wasn’t clear that the phone was even updating because the update notices were so challenging to understand that they could have been written in cipher-text.
Regardless of whether it was Rogers’, Samsung’s, Google’s, or the tooth fairy’s fault, it was incredibly painful to update the Android device. Painful to the point that there’s no reason why most people would know about the update process, and little reason for non-devoted Android users to bother with the hassle of updating if they knew what a pain in the ass it was going to be.
The current state of the Android OS ecosystem is depressing from a security perspective. But in addition to manufacturers and carriers often simply not providing updates, there is a further problem that Android’s OS update mechanisms are incredibly painful to use. Only after the significant security SNAFUs of Windows XP did Microsoft really begin to care about desktop OS security, and Google presently has a decent update mechanism for their own line of Nexus devices. What, exactly, is it going to take for mobile phone manufacturers (e.g. Samsung, HTC) and mobile phone carriers (e.g. Rogers, TELUS) to get their acts together and aggressively start pushing out updates to their subscribers? When are these parties going to ‘get’ that they have a long-term duties and commitments to protect their subscribers and consumers?
In theory there is an over the air update system that should have facilitated a system update in a relatively painless way. Unfortunately, that system didn’t work at all and so Samsung’s software had to be used to receive the updates. ↩
Really, this made no sense. To update the device it had to be plugged into a computer; why, then, did the phone (which was charging because it was plugged into the computer) need to have a 50%+ charge? ↩
I actually have a few ideas on this that will, hopefully, start coming to fruition in the coming months, but I’m open to suggestions from the community. ↩
I’m really not clear why the hell a fitness application needs to be able to read who is calling me and to be able to track my outbound phone calls.
Thus far I’ve spoken via Twitter with their mobile developer, who says that the permissions request is an error on his part. I’ve also gone back and forth - repeatedly - with Fitbit’s technical support team. The first response wasn’t in parseable English, and the subsequent messages haven’t clarified why this particular permission is needed.
So, after several days of trying to learn why Fitbit is requesting these Android permissions - and what data they’re collecting - I’m not really any closer to understanding the situation than I was when I started this whole process. I’m thinking that it’s about time to exercise my rights as a Canadian and start requesting copies of all data that the company has captured about me….and then see if they’re willing to comply with Canadian privacy laws.
So I did one responsible thing today and changed my internet service plan as the 8 month extra fancy retention bonus expired. I found out that I used 7GB yesterday alone though, so I think I need to moderate my netflix usage.
In our case, I’ve found the largest uptick of bandwidth use comes from streaming hi-res images as mobile device wallpapers. To the tune of about 60-80GB a month in images alone!