Connection Quality Specific Downloading

Thinking about app download speeds, have you worked on a project where, having completed an app, a few people with what I call ‘intermediate quality’ connections, neither good nor bad, complain it downloads data slowly? The problem with intermediate quality connections is that they don’t complete fast and also don’t fail quickly due to not hitting timeouts. If you are downloading lots of things, slowly, the consequence of ‘only just’ not hitting http timeouts can result in the user perceiving downloads as slow.

The question then often becomes can we download different quantities or types of data for different users? Users on high end phones and good connections might be served richer data or more data at once while those with poorer connections might be served minimal or indeed no data. The problem is that it’s very hard to quantify all this and base your functionality on quantitative data.

Facebook has just made this problem a lot easier on Android because they have open sourced their Year and Connection classes. These can provide insights on how use varies with network performance and can allow you to vary functionality based on that performance.

Incidentally, Facebook have also just open sourced Fresco, a new image library for Android. Interestingly, it uses NDK (c native) memory techniques to store bitmaps, a technique I also happen to have used on a past project. I used this technique on a ‘kiosk’ single use device where it wouldn’t affect the memory available to other apps (because there weren’t any others). I am not so sure whether it’s right to use it on a general purpose device unless you carefully limit how much native memory you actually use. Jumping back to quality of connections, Fresco also provides for lazy loading of images from the network in a fast and smooth way.

Android for Embedded Projects

linuxdotcom.pngThe use of Android as an embedded platform interests me as I have worked on three such projects and those projects seem to have the most potential. Embedded projects are those that use Android to power a single-purpose device where the user interacts with just one app. According to VDC Research

“Embedded products running Android will gain share over the next few years. Over the last three years, Android shipments that did not include smartphones, tablets, and E-readers grew at a CAGR of 149.2 percent, culminating in about 15 million units shipped in 2014.”

VDC say that Android is currently eating into the share of Windows Embedded rather than Linux in areas such as automotive infotainment, medical devices, military handhelds, retail and signage. However, Android isn’t currently being used in areas more typically labeled IoT such as connected home and industrial automation.

Google’s Android for Work is Insecure

androidsecuritylogo.pngThere’s a very interesting article on "Android for Work: Demystified" that dissects Android for Work and concludes it isn’t that secure. The repercussions provide some important learnings for all apps that need to handle sensitive data.

Android for Work and Android disk encryption in general, suffer from a similar expectation and affliction. The expectation is that encrypted drives protect data which isn’t fully true. The affliction is that they only protect data ‘at rest’ while the phone isn’t running. Once the phone is running the drives are seen decrypted from software and can be accessed via root or via exploits that provide access as root.

The solution to the problem is, as the article hints, to encrypt the data itself and not just rely on the drive encryption. This is the crux of the message on my Android security web site. You need to define what data needs to be kept secure and protect it appropriately. Assume your app can and will be attacked and do your best to secure only the data that has to be secured. Don’t solely rely on mobile device management (MDM), drive encryption, apk re-packaging or any other higher level wrapper.

App Security Requirements

androidsecuritylogo.pngI believe that many Android (and iOS) developers have a blind spot for app security. Clients, product owners, product managers or whoever is responsible for the app rarely have security requirements and time-starved developers tend to ignore the problem.

What’s the problem? Well, on Android (see later for iOS) there are so many ways attackers can attack your app. Whether it’s re-packaging your app with malware, repackaging to circumvent functionality, stealing ip or stealing secure data an attacker has many choices of ways to attack. Methods include:

  • Unzipping, decompilation, recompilation and re-packaging of your code
  • Patching Android OS calls at runtime to intercept data
  • Examining runtime memory to see data
  • Taking a backup of app data and reading it offline

Some of these things are possible on unrooted devices and all these things are possible via a rooted device or, more seriously, via exploits that allow temporary access as root. Determined attackers can also create custom ROMs or emulator images that can intercept your app at given points in its lifecycle.

I encourage all Android developers to do some background reading. The droidsec Wiki is a great place to start to see the scale of the problem and the tools available. Unfortunately, there’s a lot more information on how to hack than there is on how to prevent hacking presumably because it’s more fun to break things than fix them. My Android Security site offers a ‘coding first’, guideline-based approach to prevent, as opposed to detect, security problems.

If you are a product owner or product manager I suggest you also research this area, define your secure data and, if necessary, uncover security requirements for your app.

For those iOS developers thinking, "Oh that’s Android, we are safe on iOS", you might like to take a look at Lookout’s latest assessment of iOS security and my previous post on Android vs iOS security.

CSS Tablet Forecasts

cssinsight.pngCSS Insight have some interesting forecasts for tablet shipments. They claim that tablet sales will double over the next four years as more first-time users appear and existing owners replace older models.

csssalesoftablets.png 

They also say Windows will claim a larger market share. I think this might even happen. People in our ‘IT world’, most of which now use Macs and Macbooks,  under-estimate the reach of Windows. However, in the ‘real world’ many people still use PCs. Take a look at NetMarketShare browser stats that cover 40,000 sites across the world. A very large number of people are still using Windows.

Allied to this are Microsoft’s new strategies. They already give away Windows free to OEMs on low end devices. They have also promised to upgrade Windows 7/8 free of charge when Windows 10 ships. The start menu will also make a comeback. In the longer term, these changes might help consolidate and retain existing users onto Windows 10 and sell more tablets. However, I still believe Windows on phones is probably a lost cause.

Thoughts on Android Studio

androidstudio.png

If you follow Android you will probably already know Google deprecated Eclipse and Android Studio is now the recommended IDE for Android development. I migrated all of my current clients’ projects last December. I hadn’t previously migrated them as I have a policy of not using beta tools on client projects – more to conserve development time as opposed to avoid introducing problems. I had used Android Studio, as a learning exercise, for some simple personal projects but had held back writing about the problems until v1.0 shipped and I had more experience of using Android Studio across several client projects. I am at that point now so here are my latest impressions.

The Good

  • First of all and importantly, it’s very easy to import Eclipse based projects.
  • IntelliJ IDEA has far superior code completion. It’s a lot quicker to code when you don’t have to go to other files/places to determine APIs and constants. It also seems to be very intelligent at offering a sorted list of the most likely code completions with the most likely first.
  • It’s good to now be able to easily create custom variants of apps via Gradle.
The Bad
  • It has poor NDK support for non-trivial NDK builds. You end up having to not use the built in Android Studio support for the NDK and instead configure Gradle to do a separate NDK build. This makes using NDK code less integrated and less visible in the IDE than it was with Eclipse. One of my client projects makes extensive use of the NDK so this issue is a larger problem for me.
  • Unlike Eclipse, you can’t have more than one project (that generates an apk) open at once thus making switching between projects inconvenient. To be fair, there’s less need to switch between projects now that it’s easier to have build variants.
  • Some run configuration parameters aren’t persistent between successive Android Studio sessions. Specifically, if a particular device is selected for debugging this isn’t saved between Android Studio invocations. You will be asked again next time.
  • There are still some bugs in frequently used features. For example, on loading an existing project, some projects refuse to see the ‘app’ part of the project until there has been a Gradle sync.
  • Unlike Eclipse, Android Studio doesn’t ‘compile as you go’ to produce issues in the ‘problems’ tab. Instead you have to build to see problems. This is a backward step. There’s a 3rd party plugin that enables auto-compilation if you dare (it hasn’t been updated for a long long while).

The integration with ADB is poorer than with Eclipse…

  • The logcat Window seems to periodically stop working and ends up in another logcat Window somewhere deep in the Android DDMS Window hierarchy. If you have multiple monitors and are used to dragging the logcat window out to a separate screen you will soon be frustrated when the logcat stops and ends up coming out in some other window. I’d say this is the most annoying problem of all.
  • There’s no ADB file explorer. You can now use the separate ‘Android Monitor’ application that gives essentially what you had under Eclipse. However, using this cuts off the ADB connection in Android Studio as only one thing can have a debug connection at any one time.
  • Selecting Stop doesn’t kill the app being debugged. You have to manually do this via the device Android task manager (or use ‘adb shell am force-stop <packagename>’ for Honeycomb and above).

Unfortunately, there’s more bad than good. As ex-Googler Jean-Baptiste Queru said yesterday "Working with Google tools: there’s the one that’s deprecated (Eclipse ADT) and the one that’s not ready yet (Android Studio)."

If you are interested in the ‘Present and the Future of Developer Tools for Android’ you might also like to read a very recent interview with Tor Norbye.


Some Android Apps Going Backwards

android.gifI have recently been disappointed with the changes the BBC made to the BBC News app. I used to use this app every day until, very recently, they updated it to use Material Design. Along the way, they removed the easy-access single screen of stacked scrolling, themed news items and instead you now have to pick your way through a navigation drawer (hamburger menu) and view pager screens. The app has lost it’s primary purpose for me to easily browse through news. I am not the only one. The Play store reviews concur…

"Agree with everyone else. Bring back the old version, please. Used the read that one frequently but don’t even want to open the new one because it’s such a chore to find things."

"Too complex. To much jumping from stories to videos. "My news" seems duplicated somehow with my news combined in one tab then duplicated in multiple tabs, one for each news feed chosen. Needs simplifying."

"Bring back old version plz Hard to find news your looking for too much content that’s displayed in confusing manner bring back old version that just had one scrolling screen so fluid an easy to use hate this version so much"

Now on to Google’s Gallery app. Why was it replaced with the Photos app that needs Google+ enabled to use it to set a phone background? I disabled Google+ on Android a long while ago as it consumed excessive power even though I never used it. 

On to Google Calendar. Why was month view removed? Who decided to put a wasteful graphic at the top when, in Calendar apps, the most precious resource is screen real-estate?

What’s caused all this? There seems to be a growing trend to make apps more Material Design compliant. While the Material Design isn’t particularly at fault, it seems in slaving over the new look and feel, other things has been lost. The apps might look better but noone has thought deeper than that.

So, if you are thinking of moving your app to Material design, don’t let it divert your time from thinking about other things that are just as and maybe more important. Also, while hamburger menus have legitimate use in some (more complex) apps, you should realise they can end up making things more difficult to use in simple apps (yes, it’s an iOS article but the principles are the same).

UPDATE: Also read Side drawer navigation could be costing you half your user engagement