HiQES Larry Schiefer

Android M Permissions Overhaul: the Good, the Bad and the Ugly

For those who may have missed the announcement at Google I/O: Android M permissions handling will introduce new handling and behavior. The new Android M permissions system support allows apps to be installed without requiring user review and grant of permissions. Instead, most permissions are disabled by default when an app is installed. When the user starts the app and it requires a feature which requires a permission, the user must grant it. The user can also go back at any time and either grant or deny permissions to individual apps.

While this type of functionality has been available in other AOSP derived versions of Android, such as CyanogenMod, it has not been part of the official Android open source codebase. This is quite a departure from the original permission paradigm used in Android. I’ve talked about the original Android permissions system in my previous article on Android Permissions, in case you are unfamiliar. This auto-grant/revoke with user interaction sounds like a very simple change, but trust me when I say it is not a simple or straightforward for the framework or for app developers.

This is an important step forward for the platform security wise and for the end user. Several reasons for the changes come to mind:

The original user experience of one time grant was better than nagging the user, but was very limited due to the all-or-nothing permission grant at install time with no ability to revoke permissions
Android M permissions support brings it closer to parity with Android’s biggest rival: iOS
As users become more savvy, they are demanding a selective permission control type system. They are finally catching on that malware exists and want to have more refined control over what things apps can use.

Let’s […]

By Larry Schiefer|June 2nd, 2015|Android, Security|2 Comments|

Notifications in Lollipop: Playing Nice in a Legacy App

Notification Changes
Notifications in Android continue to evolve with the platform. New features get rolled in regularly and Android Lollipop (5.x) is no different. Lollipop introduced some great features with regards to notifications. Most of these are focused around user privacy, but there is also a usability factor to consider. But wait, today’s Android dashboard (last updated on Mar. 2, 2015) shows very low Lollipop usage:

So as an app author why should you be concerned about dealing with Lollipop now? There are several very good reasons: 1) it shows the app users that the app is still being maintained and supporting newer platforms, 2) it is better to get ahead now before the roll out numbers take off and put your team under pressure, and 3) there can be some unwanted side effects with the Lollipop changes. A great example is if a legacy app shows a persistent notification. Let’s say I have a legacy app which communicates with my continuous integration build server and tells me the state of the build. If the app isn’t updated with some simple changes, the notifications in Lollipop won’t show their details or up to date info on the lock screen. The good news is that adapting legacy code to handle notifications in Lollipop isn’t terribly difficult In this article I’ll briefly cover some of the new features which are available then address how you can update your legacy app to not just take advantage of these features but also how to make the app’s traditional notifications behave well on newer devices. Note that I’m not going to touch on everything new for notifications in Lollipop, such as Wearable support. Wearables will generally work out of the box with your notifications, […]

By Larry Schiefer|March 12th, 2015|Android, Best Practices, Lollipop|Comments Off|

Android Loaders: the Data Forklift for your App

Android Loaders, first introduced in Honeycomb (API 11), enable app devs to use a more robust pattern for handling data loading. Data loading is (generally) easy, so why was this needed? To answer that, we first have to take a step back and take a glimpse at an app’s internals.

Android App Context of Execution
It’s very common in Android app development to see references to the “UI thread”. This is the main thread of an application and how the framework notifies the app of events. Take an Activity for example: its lifecycle callbacks as well as UI event callbacks (onTouch(), onClick(), etc.) are all executed on the main thread. Why is this relevant to a data discussion? Two reasons:

While executing a lifecycle or UI callback, all other similar events for your app are waiting to be processed
The current state of your Activity (or Fragment can change and has to be coordinated with background threads

Let’s start with the first item. If the Activity is in the running state (e.g. onResume() has run) and a click listener’s onClick() is called, any additional touch, click or lifecycle changes are queued for processing after the listener returns. If the onClick() takes a long time to complete, the other events are sitting in the queue waiting to be processed. If we have even a moderately sized app there’s a chance we also have a BroadcastReceiver or Service which could have events pending as well. These components are also called on the main thread of our app’s process. It should be pretty obvious how long running operations on the main thread can cause problems. Even small data loads, such as from an internal SQLite database, can take time due to I/O or processing. So, […]

By Larry Schiefer|December 15th, 2014|Android, Best Practices, Design, Thread|Comments Off|

Android Animation – Part 3: Advanced Animators

Advanced Animator Use
The previous two articles on Android animations covered the basics of the Animation, AnimationDrawable and Animator classes. These classes provide a great starting point for introducing animations into your applications. As mentioned before, the preferred way of handling animations is to use Animator classes whenever possible. Let’s take a closer look at this generic class and more advanced Animator use.

Animating Arbitrary Properties
During our exploration of the Animator class, we examined the ValueAnimator as well as the ObjectAnimator. The ObjectAnimator always has a target object and manipulates an attribute of the target with each step of the animation. What if you wish to animate a property which is not a simple int or float value? This is where the power of the android.animation really gets to show off.

In our previous example we used an ObjectAnimator to animate the alpha value of a View object, which is simply a float value. What if instead we wanted to “wash out” the background color of a View during our animation? We can easily set the background color using the View.setBackgroundColor() method and it is just an int, so how is the different? If we were to animate the color as just an integer, it would not give us the desired result and instead just cycle each of the colors on the way to our final color. Because the range is so large (looking at it as just an integer) the animation happens extremely fast.

public class ColorWashAnimatorActivity extends Activity implements
[…]

By Larry Schiefer|November 10th, 2014|Android, Design, mobile|2 Comments|

Android Animation – Part 2: Animators

Introduction
In Android Animation Part 1 we started to examine animation capabilities within Android using the capabilities defined in the android.view.animation package. These include tween and drawable based animations. Both of these have been in Android since API level 1 and provide basic animation support. Creating custom animations is straightforward for both, but have their limitations. With drawables you have a series of pictures which are shown in sequence, like an animated film. Using tween animations you can alter the way a view (and its hierarchy) is drawn by transforming certain characteristics. This is great for simple things, but shows its limitations once you really start working with it.

In order to allow more advanced functionality, Android received an update to its animation support in Honeycomb (API 11) with the introduction of the android.animation package. The package adds a more generic Animator base class, some versatile child classes and a highly customizable mechanism for evaluating changes. Let’s take a closer look at this package, how it compares to the view based animations and how to use it.

Animator
At the core of the android.animation package is the Animator base class. This base class gives us a common set of APIs for setting and getting parameters for the animation, such as the duration. It also defines the APIs used to start, stop, pause and resume the animation. Additionally, it defines an inner AnimatorListener interface which is used to callback registered listeners during these animation points, similar to the listener interface used by the Animation class. The vast majority of the methods defined by the Animator class are abstract and must be implemented by the subclasses. When using an Animator at this high level, the listener interface is critical for […]

By Larry Schiefer|October 17th, 2014|Android, Design|1 Comment|

Android Animation – Part 1

One visual aspect of an app which can make or break the user experience is the use of animations. They can add that bit of pizazz which really makes an app look polished and refined. Or, they can overburden the user and the device with too much going on and kill the app’s visual appeal. Like other modern UI driven platforms, Android does include animation support. However, Android animations are interesting and have evolved over time. This has brought app developers more power and flexibility, but like any API it can be difficult to navigate. This is especially true with regards to the use of the different techniques and APIs exposed by the framework. The different mechanisms have subtly different names and can use XML configuration which can look very similar. Android animations can be categorized in three basic buckets: tween, drawable sequence and property animation. In this first article in this multi-part series we’ll start our examination of Android animation capabilities by looking at the original ways to animate things: tween and drawable animations.

Note that when I say animations, I’m referring to view or screen type animations, not 3D graphics or OpenGL based animations. Diving into OpenGL is a much bigger topic and is separate from animating all or part of our app’s UI.

Tween Animation
A tween animation is also called a view animation. This type of animation is performed on the content of a View. A tween animation applies one or more transformations on the content of a view, such as its position, size or rotation. Tween animations are simple to use and understand, so for developers just getting started with Android animations in their apps it is a great option. But, the tween […]

By Larry Schiefer|October 10th, 2014|Android, Design|Comments Off|

Android Alarm Ins and Outs

Android apps often need to perform actions some time in the future. This can be “one shot” type operations or periodic tasks. For simple needs while an app’s Activity or Service is in the running state, this can be done using a few different mechanisms such as a CountDownTimer or the old standby Timer. If your app has actions to perform regardless of the state of your components, you need to harness the power of the Android alarm.

Android Alarm: What It Is
As the name implies, an Android Alarm is something which wakes your app at some point in time. But, it wields more power than just that: it can wake your app regardless of whether it is running or not and it can wake the entire Android device if it is asleep. So this isn’t just a way to wake up a paused thread in your running app. This is the software equivalent of an air-horn used to rouse your Android app out of bed to get moving and even get the whole device up and running if it is sleeping.

There are essentially two different types of alarm instances: one which wakes your app the next time the device is awakened and one which wakes both the device and your app. Let’s call these the “get up when you can” type and the “get up, the house is on fire” type. Ok, that was a bit much, let’s just call them “gentle” and “aggressive”. Either type can have their time specified by either the elapsed uptime of the Android device or via calendar time. They also can be setup to be periodic.

It’s worth noting before I go further that the use of alarms isn’t a […]

By Larry Schiefer|October 2nd, 2014|Android, Design|Comments Off|

Gradle Update to 2.1 Impact on Android Builds

As many of you are already aware, Android Studio is using Gradle behind the scenes to build your applications and libraries. Over the last year and a half, both Android Studio and Gradle have matured significantly. With the recent Android Studio 0.8.11 release, there was a Gradle update of major versions from 1.12 to 2.1. While most devs won’t notice a difference other than Studio telling you the newer Android plugin (version 0.13.0) requires 2.1, the jump forward can affect your Gradle based builds. The impact comes both from the version shift from 1.x to 2.x and the Android Gradle plugin. Let’s start with a look at the 2.0 release of Gradle.

Gradle 2.0
The Gradle update to 2.0 was a major step forward for the build tool. Like many tools it introduced a number of improvements and fixed issues along the way. In the Gradle team’s announcement about 2.0 it was stated that the major version bump is being used as a clear signal that there will be compatibility shift. The Gradle team has done an outstanding job of maintaining backwards compatibility throughout its lifetime. But, like any good software project, it continues to evolve and often features which are not widely used or deemed unmaintainable are dropped. Gradle’s team indicates these features to be culled by marking them as deprecated in the documentation as well as within the tool itself. Thus, the 2.x release indicates a clean break where things will no longer be fully compatible with previous releases.

By and large this Gradle update should have minimal to no effect on simple Android builds. Most of the changes really had an impact on the plugin developers. But, I did say, “minimal to no effect,” which means there […]

By Larry Schiefer|September 25th, 2014|Android, Build automation, Gradle|Comments Off|

Android and Linux Kernel Drivers

One of the questions I’m asked most frequently when giving training on Android’s internal workings is how to write a kernel driver. What makes this question interesting is it’s not always clear what the person asking the question means and usually requires additional conversation. Generally speaking, it boils down to one of two things: 1) how do I make device hardware work on Android or 2) how do I write a driver for the Linux kernel powering Android. While there is no doubt these two things are related, the answers are not necessarily the same. This really stems from how hardware devices are handled in Android and how it is different than traditional Linux systems. We can answer this by looking at three basic concepts for Android hardware handling:

The Linux kernel is used on Android in part because of its large base of existing drivers as well as easy programming model
Android handles hardware both in the kernel drivers as well as via the Hardware Abstraction Layer (HAL) at the native level
Drivers and HAL modules must be included with the device, they cannot be installed by the user

Linux Kernel Drivers
The Linux kernel provides a robust, extensible and well understood kernel environment. It’s been around for nearly 25 years and continues to evolve as time goes on. Android utilizes a forked Linux kernel: there are numerous additions made to the kernel which are Android specific and essential to its operation. However, in the grand scheme of things the number of changes is quite small. The Linux kernel has a well documented driver model and includes a multitude of drivers supporting various CPUs, SoCs, controllers, busses and devices. So what does this mean for Android? It means if […]

By Larry Schiefer|September 18th, 2014|Android, Drivers, Linux|2 Comments|

Gradle Primer

With the introduction of Android Studio at Google I/O in 2013, many developers were seeing Gradle for the first time. This build system, while relatively young, replaced Ant as the defacto build system for Android apps. But, just like Ant and other build systems, Gradle is constructed to be a generic build platform, not just for Android apps. Gradle is different, though, in that it uses convention over configuration coupled with scripting via Groovy. It isn’t as daunting it sounds, once you understand the basics.

Groovy
The first thing to understand about Gradle is the language used by the scripts themselves: Groovy. Groovy, also a fairly new technology, is a dynamic language based on Java. The syntax is very Java like, though it makes the line ending semi-colons optional and adds some new syntax twists. In essence, Java code can be treated like valid Groovy code, but not the other way around. In fact, you can utilize standard Java libraries in Groovy code!

One of the most heavily used features of Groovy within Gradle is the closure. A closure is an executable set of instructions which can be assigned to a field or variable, is contained within the declaring lexical scope and can also access non-local variables outside of its own lexical scope. It’s similar in concept to an anonymous class in Java, but with some subtle differences. This wikipedia article does a great job of explaining the subtle differences. Often you will use a Groovy closure within Gradle to override or specify parameters for objects. With regards to function closures, you can think of them like Java 8’s lambda functions (in face the syntax is essentially the same.) For example, let’s take a very simple Groovy […]

By Larry Schiefer|September 11th, 2014|Android, Build automation, Continuous integration, Gradle, Software|2 Comments|

12 3 Next