Security Incentive For Device Upgrade

November 21st, 2014

android.gifTwo Android security problems have hit the news over the last few days. The first is a problem with on ALL devices prior to Lollipop. It’s not a problem in itself in that the user needs to somehow accidentally install a malicious app. The second is one such app, NotCompatible, that has been around a long time but has recently made the news due to some posts on popular sites.

The thing is, the user has to actually say yes to downloading and installing an app when they are web browsing. A bigger question is why Android’s anti-malware tool, Bouncer, hasn’t detected this side-loaded app. I suspect it has. Bouncer has only worked on side-loaded apps since Android 4.2 and I suspect the majority of infected devices use earlier versions of Android.

The best defence is probably to only use devices running Lollipop. As I have previously observed, 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:

Web Access From Devices

November 20th, 2014

scientiamobile.pngScientiamobile has a new free MOVR report (PDF) for Q3 2014 showing device usage trends, particularly related to web access from mobiles. There’s lots of data on form factors, top smartphones, top tablets, top OSs for browsing across different continents. A chart that caught my attention was one that showed the use of WebViews within apps to view web pages…


Why does Android have a much higher proportion of web page views from WebViews? I’ll be contentious and guess it’s because developers put in less effort on Android. WebViews are the quick and easy route to getting an Android app with the compromise of poorer usability. I guess it’s because companies/developers tend put less effort into Android apps than iOS apps.

On a recent project, I argued (unsuccessfully as they are still there) that WebViews make a very poor substitute for real screens (Android Activities). Without a lot of effort creating a responsive server-side, the web pages don’t look like app screens, the app vs web navigation breaks down, you get links rather than buttons/list items, you open up many complex security vulnerabilities and content authors end up thinking it’s ok to add arbitrary server-side content. For example, I saw content being included that had sharing buttons and feedback forms that looked alien in the app and didn’t work well. It made me uncomfortable that the app I had written had become something I wasn’t proud of.

Meanwhile, Google are trying their best to make Chrome and by implication, WebViews feel more like the platform you are running on. This started with Material Design which they hope will unify the look and feel cross platform. Google are pushing to reduce the distinction between app screens and web screens. The Lollipop Launcher (Home screen) includes cards that can be web pages. Chrome Developers Tweeted from the Chrome dev summit yesterday…


Google are also working on Chrome rendering performance, push messaging, Bluetooth, notifications, access to camera, geofencing and background sync as well as corresponding web site permissions to control access to these new features. All these things will eventually help the web become more like an app.

However, all this is very Chrome centric. Consistent design and available functionality will only work if you use Chrome and implement Material Design cross platform and even if you did, Material Design web pages aren’t going to look good on iOS. Even the example in the above tweet shows a Navigation Drawer (hamburger menu) on the right hand side in the wrong place. In reality, Android Chrome users are more likely encounter iOS idiom-based web pages with disclosures than Material Design web pages. I anticipate the web and WebView content/functionality will continue to be an idiomatic mess. 

Related Articles:

Wearables Bigger Than I Thought

November 19th, 2014
canalys.gifI have been watching wearables, from the sidelines, with the view that it’s probably not worth investing effort in this area until volumes prove it’s something people actually want. Well, today I was surprised to learn from Canalys that nearly 5 million smart and basic wearable bands were shipped in Q3 2014. This a large number given the platform is so young. The Moto 360 represented 15% of the market. Samsung took 52% market share.

That’s 5 million in one quarter. Certainly over 20 million over the next year. Suddenly, wearables seem to have more traction than I had envisaged. Wearables are bigger than I thought - in more ways than one.

Forked Android Growth Slowing

November 18th, 2014
abiresearch.gifABI has research that shows forked Android growth is set to slow in 2015. China’s growth is slowing and Google’s Android One initiative is "seeing some significant wins among Indian manufacturers like Micromax, Karbonn, Spice, Intex, and Lava, as well as some of the more International Chinese brands like Lenovo and Alcatel."


This is good news for developers as, in time, it will reduce the number of devices that don’t have Google Play Services. Google Play Services is becoming more and more important to developers as components get unbundled from the OS into Play Services and the Play Store.

It seems Android One will be more successful than I expected. I was sceptical. Getting ‘low cost’ OEMs to use Android One is being driven by the availability of low cost reference designs from Qualcomm and MediaTek. In the distant past we saw similar efforts by Symbian and Microsoft meet with only partial success. This time it seems Google has the momentum to see this strategy through. 

Related Articles:

Majority of Top Paid/Popular Apps Have Been Hacked

November 17th, 2014

arxan.pngArxan has a free State of Mobile App Security research report (pdf) that claims a very large proportion of the top paid/popular Android and iOS apps have been hacked. Hacked apps either have IP stolen that’s used in other apps, have clones created or the apps are modified to remove payment mechanisms.


Related Articles:

Android White Box Tablets

November 13th, 2014
strategyanalystics.gifStrategy Analytics has new Q3 2014 research on World tablet shipments. Android reached an all-time high of 72% of the market while iOS declined 13% to 22.3% market share.


29.9% of Android’s 72% market share is "white box" manufacturers. A white box tablet is produced by a company (the manufacturer or ODM) that other companies (the vendors or OEMs) re-brand to make it appear as if they made them. These are a big threat to the well-known brands and are increasing being sold by retailers under their own made-up brand names. Many work very well and I have even used some as a basis for client, vertical single-use ‘kiosk’ style products. The down side is that the OS rarely, if ever, gets updated and for developers there’s usually a lack of Android adb drivers.

Related Articles:

MVP What and How

November 5th, 2014

There’s a diagram doing the rounds that demonstrates what a Minimum Viable Product (MVP) is (and isn’t). It shows that a MVP shouldn’t be just about functionality but also about reliability, usability and user experience. Building a MVP is one of the first steps after which you have to measure, learn and iterate. However, just getting to an MVP can be difficult and how you do it can affect ongoing development.


The diagram is a clever way of showing what’s sometimes hidden when first thinking about a new product. It digs deeper into the what side of a MVP. i.e. What the product should be. I have found that, in practice, creating a MVP is a delicate balance because it not only concerns what but also how these things are implemented.

I have seen my clients’ MVPs (server-side and apps) scrapped and started again and I have also seen them used as the basis for further iterations. I have seen large amounts of effort on over-thought through, over-generalised and over-tested MVPs be dropped. Conversely I have seen under-thought through, under-designed, under-tested MVPs with lots of technical debt become the basis of future development. Perversely, the flexibility of the latter approach seems to foster more success and these are the projects that then end up having to build on sand. So, also think how (well) as well as what.

Related Articles:

iOS <-> Android Native App Conversion

November 4th, 2014

myappconverter.pngOne of the problems of mobile development is that it’s a human resource driven activity that’s expensive. Multiply that by iOS and Android and the costs double (or more). Wouldn’t it be good if you could develop on Android or iOS and a tool could automatically generate for the other platform? Well, MyAppConvertor has that ambition. Really. This isn’t some limited, poor html-based or intermediate language-based ambition. It’s the real thing - Objective c to Java and vice versa.

MyAppConverter presented at the recent DroidCon UK 2014. You can signup with SkillsMatter to see the presentation.

MyAppConverter is currently in beta and is limited to online conversions via their web site. It only works for games, only converts from iOS 7.1 to Android 4.4.2 and only on Samsung Galaxy S5. However, the aim is to eventually support IDE-based conversions, for all types of app, to and from all major mobile platforms and versions of those platforms.

The presentation outlines their approach based on models and meta models to not only directly map code but to also do it in such a way that creates the right algorithmic and UI idioms/patterns on the respective devices. While the converter can create source code for completion by a developer, they are aiming for 100% conversion so that anyone can use the tool. Anything less is much less useful as it then needs a developer and the ‘extra stuff’ the developer adds needs to be somehow added every time there’s a new version of the app which would get difficult to manage.


The intention is impressive and hugely ambitious. However, it’s so ambitious I question whether it’s viable. The Droidcon presentation hints that they have already spent 5000 man days on iOS to Android transformations, just for games APIs. Games are the simplest, low hanging fruit, case as they don’t use that many APIs and are mainly drawing code.

This isn’t just about mapping APIs which is complex in itself. It’s also about knowing all the nuances of the APIs that are documented in places like stackoverflow. It’s also about mapping idioms and patterns of doing things, somehow mapping 3rd party libraries, knowing fragmented differences between (target) devices and knowing differences in APIs across OS versions. Even then, it won’t cover apps that use ‘real native’ c/c++ NDK code - previously estimated by Intel to be of the order of 25%. Once all this is solved, consideration has to be given to keeping all this up to date into the future. APIs can become deprecated over time and new API’s are created. For example, in Android Lollipop there are over 5000 new API’s. New devices will also become available with new nuances.

I don’t think what they are trying to achieve is possible in a reasonable time and/or with a reasonable team size. The World really needs tools like MyAppConverter. I sincerely hope they prove me wrong.

If I am wrong and the tool comes to fruition then there are some interesting possibilities MyAppConverter might not have considered. It might be possible to create a new tool to create apps by visually (or otherwise) building up the pre-existing meta models. These meta models, together with some kind of configuration data (the static, unchanging data in an app), would then be able to auto generate to multiple platforms with no actual developer coding thus putting developers such as myself out of business. Lay people, capable of wiring things together, could create complex apps.

Related Articles: