Scaling Android Development

October 13th, 2014

twitter.png

Most Android apps are created by a single developer or a team of a few developers. However, what happens in a large company where potentially hundreds of developers each want to add their small feature? There’s a new video, from DroidCon Paris, on how Twitter went from a few developers up to of the order of 100.

The video shows how Twitter developers, who were more used to working on the Twitter Web site, had to adapt to working on Android. For example, their ‘web brain’ that previously allowed bugs in the web site to exist, because they could be reverted, had to be modified for Android where a crash usually means the user will install and might not re-engage with the app for another month. Also apps have a longer lifetime until upgrade and Twitter has up to 60 versions of the Android app running at any one time due to people delaying upgrading.

The session shows 50% of Android Twitter users will upgrade within 3 days if no extra permissions are required. 75% will upgrade within 14 days. When new permissions are required manual upgrade can typically take a month.

There’s also useful information on large scale training, test devices, code style wars, testing tools, emulator vs device, remote feature on/off and toolchains.

Apple Pay Limitations

October 10th, 2014
apple.gifThere’s an interesting article on USA Today Money quoting a UBS report explaining problems with Apple Pay that will limit its dominance…
  • Onerous fees charged by Apple
  • Inferior technology
  • Little incentive for merchants to adopt Apple Pay-compatible devices

More reasons then, why Apple should open up NFC before interested parties develop alternative solutions.

Looking wider, this provides learnings for any new venture. Are the fees you expect to charge reasonable in the current (and future market), can people easily circumvent your solution using other technologies and are you expecting too much of third parties to change/update their systems in order to be part of your solution? I suppose it’s really about having an old fashioned business model which is one of the stages of my primer.

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.