Android Permission Complications

I previously wrote about the new Android M Permissions scheme and how, while more transparent permissions is good for everyone, they introduce a lot of complications. These complications are yet another example of something that developers usually know a lot about but their product managers and some designers won’t know how to resolve. This leads to lots of trouble agreeing/deciding how screens and messages should look and feel, especially when developers aren’t included in the pre-development stages of a project.

There’s discussion that even top apps might be avoiding the move to targeting Marshmallow so as to avoid the complications. I have one such client project where I did some small changes that involved fixing on M devices but I didn’t have the time budget to go through the new permissions implications with my client. Hence the app stayed targeting Lollipop. I have another client who isn’t interested in M at all until it is seeing a greater uptake on devices. I suspect these scenarios are typical at the moment. However, most apps will one day have to ‘bite the bullet’.

This week’s Android Dev summit, particularly day 1, has some great recommendations on to how to handle the new permissions scheme. However, the real problems are with edge cases that can seriously bazooka your app. The first was an Android Dev summit audience question and involves what happens if the user taps “Don’t ask again” and the user then has to go to App… Settings to fix the problem, The Android team said that if this happens, you have lost the trust of your user and that’s that. However, Manideep Polireddi has some thoughts on how you might recover from this situation. Another edge case is if the user does “Reset app preferences” as explained by the CommonsBlogs.

Stepping back, is all this worth it? What is this all about? There’s a very recent article on the Forrester blog where it says…

“Consumers are more willing than ever to walk away from your business if you fail to protect their data and privacy”

Some might say that this is something for older users and that younger millenials have a different attitude to privacy. However, the Forrester research shows this isn’t true…

forresterprivacy Forrester says that privacy concerns are very much alive and are set to be a competitive differentiator in years to come. For apps, this means that those that do it well will be rewarded with better user retention.

Insights for Mobile Developers from Ericsson’s Mobility Report

ericssonlogoEricsson has a new free Mobility Report (pdf). Ericsson expect smartphone subscriptions to achieve 10% compound annual growth between now and 2021 while mobile data traffic will increase by 50% compound annual growth. That will be x10 increase in data traffic by 2021 mainly driven by video.

The report has an interesting section on smartphone switching patterns…

“82 percent of Android users and 73 percent of iOS users selected a smartphone with the same operating system when switching to a new device”


Note that this analysis pertains to switching trends from old to new devices, where users remain with the same operator.

As might be expected, analysis of mobile data traffic consumption on days following a device upgrade shows a significant surge in software download traffic share from app stores after a device switch.

This might give us a clue as to when promoting and marketing our app might be of most influence – when there’s a major new phone on the market or during the holiday season.

The Latest from Blackhat

blackhateurope15If you are a mobile developer, you should take a look at the white papers and presentations that have become available following the recent blackhat Europe 2015.

Of particular interest to Android developers is (In)Security of Backend-as-a-Service (pdf) that shows how hard-coding service credentials for services such as Parse, Cloudmine and Amazon AWS not only puts particular user’s data at risk but the whole platform at risk. The easily-obtained credentials can be used to access huge amounts of sensitive data. The apparent ease of using BaaS has caused mobile developers to cut and paste sample code without thinking of the security implications.

Wondering what else your app might be doing wrong? The AndroBugs framework presentation allows you to scan APKs for known coding mistakes. It decompiles the app and looks for bytecode patterns that signify vulnerabilities in the code. Androbugs has recently become open source on GitHub.

Another way your app data might become visible is if it’s stored in the OS sandbox and subsequently backed up either on a rooted device or via ADB. The presentation on Authenticator Leakage Through Backup Channels on Android (pdf) goes into a lot more detail.

As usual, black hat activities look into the problems but don’t give many ‘white hat’ recommendations how to fix apps. It’s easier and more fun to find problems than it is to provide fixes. If you are looking for some answers then my site provides some recommendations.

Flutter – Cross Platform App Development from Google

fluttericonFlutter is a new cross platform app development framework from Google that allows apps to be created for both Android (KitKat or later) and iOS (iOS 5 or later). It’s still being developed, primarily by engineers at Google.

Flutter is a high performance (60fps) 2D rendering engine with framework and widgets on top. There are also Material Design widgets. It’s all open source.

Internally, Flutter is a mix of C, C++, Dart and Skia (the 2D rendering engine). On Android, there a Dart VM that isn’t an interpreter. Instead, the Dart VM generates JIT-compiled optimized native code. On iOS the code is compiled with LLVM and Dart code is AOT-compiled into native code. On either platform you can call native services via IPC.

The programming language used is Dart which is also open source. Dart, which became available about a year ago, was once thought to be a future replacement for Javascript in the browser but now seems to have taken a new direction. Dart is a mix between c++ and Java and supports classes with single-inheritance. It supports interfaces, abstract classes, reified generics and optional typing.

Flutter isn’t suitable for production apps just yet and you can’t yet produce installable apps that easily. On the plus side I can see it will be enable us to produce high performance, cross platform apps with much less effort and cost. However, I have some reservations.

The first is that the widgets don’t use the respective system’s underlying widgets. There are Material Design widgets but who is going to want these on iOS? iOS look and feel widgets are needed. Even if these were available, it will create ‘look and feel’ problems when Apple and Google update the system widgets in the future. Also, I can’t see how Flutter widgets would ever provide for all the theme/style customisations provided by the native platforms.

Of course, we have been here during Nokia’s ownership of Qt. Providing for respective platform UIs, especially over time, is a monumental task. Getting developers to learn a new language also requires some sort of motivation. Apple is managing it with Swift but people are coming from the much more unfriendly Objective-C. Another unknown is the Google internal politics of where this fits into existing Android dev tools. Again, internal politics helped to kill Nokia Qt. However, the wildcard is Oracle that could tip things the other way. Much longer term, there’s a (small?) chance Oracle’s continual battles over Java IP could tip Google into using an alternative.

Finally, Flutter isn’t the only cross-platform framework trying to use Dart. Fletch is also based on Dart.

Mobile Programming at a Higher Level

tranqltrnql has become available today for iOS and Android developers that aids programming contextual things (e.g. location, weather, database, server) at a higher level than using a multitude of libraries and APIs. For example, you can determine whether the user is in a vehicle, with just one API call.

trnql was founded by former Google and Yahoo veterans and aims to simplify the developer experience. For product owners, this means much quicker time to market and less expensive development – but you will, of course, have to pay for the trnql API longer term.

Mobile development is reaching ever higher levels of maturity. At first there were just the OS APIs. Then came the many libraries, for example the many Android libraries listed on Android Arsenal. We are starting to see even higher levels of abstraction such as Android Templates and now trnql that enables writing of much less code.

The main problem with abstraction is that the higher you go, the more you become constrained to a particular way of doing something. That particular way is usually tried and tested so it’s a compromise of reliability/time-to-market vs flexibility.

As your app matures, you will probably find you will want to do things differently or implement lower level things yourself to own the responsibility for aspects such as security. Starting simple, maps well onto the lean startup way of doing things as it maximises learning velocity.

Security As a Differentiator

blackberryEngadget posted an interesting article today on ‘BlackBerry reveals the lengths it went to make Android Secure’. This is after BlackBerry CEO John Chen previously revealed that BlackBerry could quit the handset business next year if it doesn’t sell enough handsets.

With the new Android Priv device, BlackBerry is trying to use its reputation as a secure device vendor to differentiate itself from the very many other Android vendors.
Security researchers will, no doubt, be eager to test the security claims and hence it remains to be seen if BlackBerry championing a secure Android handset is a wise or foolish endeavour.

This got me thinking about security as a differentiator. This might equally be applied to apps as well as handsets. Consumers are becoming ever wiser to privacy and security concerns and in the right circumstances this might be able to be used to tip the balance in favour of the app you are creating. However, as with BlackBerry (and indeed Snapchat), it really depends on how secure your solution really is.

Android (and Mobile) Security

universityofcambridgeUniversity of Cambridge’s latest research into Security Metrics for the Android Ecosystem (pdf) has had the technical (and non-technical) media writing about Android security over the last few days.

Most of the research findings were already known. That is, the security of Android “depends on the timely delivery of updates to fix critical vulnerabilities” and “the bottleneck for the delivery of updates in the Android ecosystem rests with the manufacturers”. However, one interesting fact is that, ignoring Nexus devices, LG is the best manufacturer when it comes to updates.

So what are the vulnerabilities? The most serious ones are privilege escalation that allow code to gain more capabilities than were originally granted by the OS. For more information on this, take a look at a recent presentation from HITB GSEC by Ryan Welton and Marco Grassi on the Current State of Android Privilege Escalation (pdf).

Frederic Jacobs has an interesting article on Medium where he says the problem has come about due to manufacturers having no financial incentives to provide updates.

However, we probably need to put this into perspective. As Markus Vervier said today, “100% of Android and 100% of iOS devices are insecure. We just did not find all the bugs yet (and we never will).”

Single Use Android Devices

lightI am a great fan of using Android for vertical single-use purposes. I have worked on several projects on camera-specific and Android TV devices that stretch ways in which devices and the Android OS were originally intended to be used.

Today, I came a cross a new usecase – camera only (without phone). Imagine an Android-based camera that has 16 sensors, 10 firing simultaneously to achieve multiple focal lengths all at the same time. Imagine software that stitches the images together to achieve a 52MP image. This is the Light L16, which has effectively a 35-150mm optical zoom and an aperture of f1.2.


It has been said that this device has the potential to disrupt D-SLRs – all powered by a smartphone OS.