Android Device Churn

October 7th, 2014

bidouulle.pngBidouille has some great charts showing how Android version distribution has changed over time. They are based on values taken, over time, from Google’s own Android dashboard. However, remember there’s possibility that these charts might not represent the actual distribution of devices as not all devices (or users) access the Play Store.

androidversiondistributionhistory.png 

What with few manufacturers updating older devices to newer versions of the OS and those that do taking a long time to do so, it’s surprising to me that so many devices now run 4.0.3 or better. So what has been causing people to change their devices so soon? It might have something to do with tariff contract lengths. It might even have something to do with the use of contract-free SIMs where people can upgrade their phone any time. It’s almost certainly to do with the enticement of improved devices over the last few years. Looking forward, there might be another driver.

Yetserday, Lookout wrote about the Android browser bug and how it affects about 45% of users. They said…

"If you have a phone that does not have the option to update to a newer Android OS version (4.3), unfortunately you may need to upgrade your device to a newer, more readily patched version"

In some ways it’s odd that one of Android’s failings, that of slow or non-existent OEM OS upgrades, might cause more people to buy a new device to be on a more secure Android version, which, in turn, will reduce OS fragmentation to the benefit of the platform.

Related Articles:

CERT Vulnerable Android App Naming and Shaming

October 3rd, 2014

cert.pngI have previously written (here, here, here, and here) about Android apps that fail to validate SSL certificates. CERT has started to name and shame libraries and apps that their Tapioca tool has detected to be vulnerable to Man In The Middle (MITM) SSL attacks. There’s a blog post on how they have automated the analysis, a vulnerability note explaining the problem and a large spreadsheet of vulnerable libraries and apps.

Libraries that have been found to be vulnerable are Flurry, Chartboost, Adcolony, MoMinis, Inmobi, Tapjoy, Appsflyer, Gameloft, Zopim, Fiksu and Batch of which only the first two, Flurry and Chartboost are noted as fixed.

CERT are testing one app at a time so progress is slow. Nevertheless, over 1000 apps are listed as having failed. However, some of these failed because of the included vulnerable libraries.

If you think this is just an Android specific problem then you might like to consider that Veracode previously found 7% of Android apps and 33% of iOS apps had cryptographic problems. Developers can be inexperienced or lazy on both platforms.

Related Articles:

Another Android WebView Vulnerability

October 2nd, 2014

android.gifAnother day, another Android WebView vulnerability. This time it’s related to users that have enabled accessibility on their phones. This exposes two Javascript objects allowing remote code execution.

You might think this problem has low risk as not many people would enable accessibility features that are intended to assist users with disabilities. However, even I have had this enabled as it’s used by a password store app I use that auto-fills login forms for me.

There’s some new useful advice for developers to invoke removeJavascriptInterface("accessibility") and removeJavascriptInterface("accessibilityTraversal") that I have added to my WebView security guidelines.

Related Articles:

Smartphones and Beyond

October 1st, 2014

symbian.gifOver the last few weeks I have been reading the 800 page book by David Wood on Smartphones and beyond: Lessons from the remarkable rise and fall of Symbian.

It’s fascinating reading especially if, like me, you developed Symbian apps and worked at Symbian. It’s useful reading even if you aren’t in any way linked to Symbian as many of the learnings are just as applicable today. Don’t let the 800 pages put you off. There are lots of press releases, blog and news articles that you don’t really have to read entirely and the latter portion of the book hasn’t much to do with Symbian or necessarily mobile at all and delves into David’s other passion of predicting what might lie ahead. In fact, if you are interested in this kind of stuff you are better skipping this part and instead reading ‘Anticipating 2025′ which is part authored by David and includes similar material.

Back to the Symbian book, it describes how Symbian’s loss of control of the UI, to Nokia, affected the OS. It describes the difficult situation when your customers (licensees in Symbian’s case) aren’t the end user (network operators, consumers). It also shows how there can be conflicts of interest when your shareholders are your customers and how they can prevent the company from exploring what could be more profitable or successful areas. It also demonstrates how it’s easy to under-estimate competitors who have taken up recent easy-to-deploy commoditised solutions for which you have historically had to use a customised solution to which you are now tied. It describes how large software is difficult and differentiates between team agile and enterprise agile. The book also shows it’s possible to consider creating custom solutions for customers but to make them pay through consultancy.

There’s a useful observation that recruiting the best is important. If your don’t then when your recruits recruit further people there can be downward spiral as people recruit weaker and weaker people so as to protect themselves. The book shows how technical debt and strategic debt can cripple a large company (Nokia) thus advantaging faster-moving newcomers such as Google and Apple. There’s also a possible explanation of why Stephen Elop killed Symbian so quickly rather than slowly, a strategy that lead Nokia to financial ruin. You can also learn how David’s openness, while representing the ‘open’ Symbian Foundation, caused him to be asked to leave his job.

Many of the insights can be used to provide advice to today’s startups. For example, if you are thinking you can’t compete with an incumbent, there’s a possibility you can. They will be much much slower, especially if you can use commoditised solutions while they use custom solutions.

Related Articles:

Same Origin Bypass and Android Apps

September 30th, 2014

trendmicro.pngThere has recently been a high profile ‘Same Origin Bypass’ security issue regarding the Android browser, prior to Android 4.4 KitKat, that allows a client session on one site to affect a client session on another. TrendLabs have just posted some information that shows that this vulnerability has wider reach than first thought. Like me, you might have thought it was only a web browser problem in that visiting one infected site can then cause problems when you visit further sites. However, as TrendLabs state… 

"A more significant problem right now might be apps that show a website within their own user interface. Messaging apps, or other apps where users can view an arbitrary URL, are a particular problem if the site is opened within the app and not sent to the user’s default browser."

I guess what they are getting at is that opening one infected URL followed by other uninfected URLs can compromise the security (data and behaviour) of the later sites. I urge you to think about if your Android app opens arbitrary URLs or even defined URLs, the content of which, you have no control over. Opening them into a WebView can cause unintended Javascript to be run. I have some further guidelines for using Android WebViews where I already advise not to use WebViews if your app involves processing any data that needs to remain secure.

Related Articles:

Permissionless Innovation

September 29th, 2014
Steve Cheney Technologist, thinker and doer and co-founder of Estimote, has an interesting, pro iOS, post on The Future of Apple and Google. In his summary he says…

"It’s provocative to think about where Apple and Google each go next. In mobile there’s a term called ‘permissionless innovation’, the basic  premise of which is you don’t need anyone else’s permission to innovate. The beauty of the modern mobile era is that it isn’t held back by anti-innovators like the carriers or monopolists like Microsoft and Intel who gated the pace of innovation in previous platform eras. The mobile stack has decoupled these previous incumbents from control."

While things are more open than say 10 years ago, I believe progress in areas such as mobile payment and use of NFC have been held up by Apple. Steve says "Apple Pay is 3 years ahead of Google in almost every regard". This might be so for Apple’s small scale Apple Pay. Meanwhile, the World needs something more universal.

Apple Pay is half way there but has Apple’s characteristic ‘let’s do it our way’. Another example, a client I am currently working with creates NFC tagging solutions that they would love to offer across iOS and Android. For now, it’s Android only even though iOS now supports NFC. It’s similar with iBeacons. iBeacons are based on Bluetooth LE. On Android it’s possible to detect all Bluetooth LE devices in the vicinity, including iBeacons. On iOS you have to know the beacon (id) you are looking for before it can be detected. Again, Apple have implemented something to satisfy just their needs. This isn’t an Android vs iOS thing. Businesses want and need to innovate across all mobile platforms. A 3rd party solution offered across all platforms will benefit everyone.

Another small thing and a bit of a curiosity, even Apple’s USB extension cables are protected against use with other cables.

In this post I have perhaps unfairly targeted only Apple. To redress the balance, latest news of tighter control of Android hardware OEMs and controlling developers  suggests that ‘permissionless innovation’ is starting to undergo lockdown even within Google. On the latter issue, Al Sutton has contacted the EU competition commission asking how Google can enforce a SLA on developers when Google themselves don’t have an SLA for developers. It’s an interesting question, especially when a problem might originate at Google rather than be within the app itself.

UPDATE: Mark Murphy has predictions of the Play Store fallout. He anticipates more intermediaries will end up selling apps but he says "Some agents will likely be scum, if for no other reason than middlemen tend to run the gamut from sensational to scum in other places".

UPDATE: Meanwhile, the EU Director-General for Competition is probing Android OEMs on their contracts with Google.

The Best Way of Doing Things

September 26th, 2014

uxmagazine.pngUX Magazine has a recent article on balancing product User Experience (UX) and lean execution. It describes how effort put into the UX should vary depending on the stage of product development. For example, if you are at the initial ‘Technology Stage’ you probably need little UX effort and should be concentrating on a minimum viable product (MVP). Conversely, if you are at the ‘Experience Stage’ you need to concentrate heavily on the UX.

There’s more to learn from this. The preponderance of conferences, articles, webinars, blogs and even my sites describing how things should be best done are often taken to be the way they should be done. People love to latch onto the ‘best’ way when, in fact, the best way depends on the situation. You can usually recognise this when someone says ‘that’s the accepted/standard/best way’ in response to a discussion, with no further justification.

This doesn’t just apply to UX. In app development it applies to many other areas such as what server backend to use, what 3rd party libraries to use, how secure the app has to be or even what mobile OS platform to use. The next time you have a choice how to do something don’t just look at reviews/comments on the technologies available but also think about the project situation. This includes the stage of product development, the team’s skills, the budget and timescales.

If you are a startup creating a team, remember that some seemingly clever but pedantic people can send you down an expensive and deep back hole. Instead, search out cleverer pragmatic people who have previously demonstrated they can balance implementation with the needs of the company.

Related Articles:

Android vs iOS Development and Ageing Apps

September 23rd, 2014

gqueues.pngI came a cross an article today comparing the development of the same app, across iOS and Android, by a programmer not experienced in either platform. There are some useful insights such as both platforms took approximately the same time, needed a similar number of lines of code and that neither platform outshone the other.

One aspect I find interesting is that iOS took longer to learn due to the quantity of outdated documentation. This is a problem on any platform, especially for newcomers. It can take a long time to assess what’s an old way of doing things, what’s a newer way and what’s best given interoperability with other parts of the app. Android apps I wrote in 2008 used some internal mechanisms that, while recommended by Google at that time, are now frowned upon. Developers such as myself need to keep up-to-date but interestingly, old apps don’t tend to need to keep up-to-date unless they are successful enough to warrant being updated. Apps age if not updated.

Apps can also age when their look and feel no longer fits the latest update to the OS. They can even occasionally but rarely die if a new API is different or, more commonly, the OS changes to do the same things but in a different order.

The effort required to keep apps up-to-date shouldn’t be under-estimated. Often companies only financially plan for initial development when, in fact, they usually have to be maintained to at least support new phones and screen sizes. I have even had a few cases, particularly when the app has been successful, where the ongoing development has been orders of magnitude greater than the original development. Another related question to ask yourself is whether your developer will still be around to do such changes.

Related Articles: