Android Permissions Talk from Droidcon NYC (Video) – Android, May I?

Our CTO and Google Developer Expert (GDE) for Android, Larry Schiefer, recently spoke at Droidcon NYC about the permissions model changes in the upcoming Android M release. In this talk he covers some background on Android’s security architecture, the issues with the existing Android permissions system, and how the new permissions model changes will affect end users and developers.

The slides and sample code are both available at the links below.

Sample code:

By |September 14th, 2015|Android, Security, Videos|Comments Off on Android Permissions Talk from Droidcon NYC (Video) – Android, May I?|

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 […]

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 |March 12th, 2015|Android, Best Practices, Lollipop|Comments Off on Notifications in Lollipop: Playing Nice in a Legacy App|

Android Advanced Sensor Usage

In the previous article, We learned about the basic properties of the SensorManager, SensorEventListner and Sensor objects along with their usage. In this article we will look closer at some of the more advanced sensor properties and processing sensor data.

Trigger Events
In addition to the previously discussed SensorEventListener, Android 4.3 introduced an additional mechanism for receiving sensor data: the TriggerEventListener. TriggerEventListener is mainly used for a special sensor type called significant motion. The signification motion sensor is a software sensor derived from hardware sensors present on the device. The only allowed value the sensor can return is 1.0. So what does this sensor actually do? It detects when the Android device has a sudden motion or jerk.  Unlike SensorEventListener, the TriggerEventListener is a one shot: it is automatically canceled after the trigger.  At the Java level, one major difference between the two listener types is that TriggerEventListener is a class not an interface, so we need to extend and implement the overridden method onTrigger().  The onTrigger() method receives a TriggerEvent object as a parameter. The TriggerEvent class is nearly the same as the SensorEvent class, except it doesn’t have onAccuracyChanged() method.  This is because the trigger event is only fired a single time, after that it will unregister itself.  Here’s a brief example of using TriggerEventListener:

public class TriggerListener extends TriggerEventListener {
private TextView mText;

public TriggerListener(TextView textView){
this.mText = textView;

public void onTrigger(TriggerEvent event) {
Log.i(“TriggerListener”, “Name:” + event.sensor.getName());
Log.i(“TriggerListener”,”Type:” + event.sensor.getType());

mText.setText(“Name: […]

By |February 4th, 2015|Android, Lollipop, mobile, Tablet|Comments Off on Android Advanced Sensor Usage|

Android Sensor Support: Tap into the Device’s Environment

“A sensor is a device that detects events or changes in quantities and provides a corresponding output, generally as an electrical or optical signal; for example, a thermocouple converts temperature to an output voltage.” – Wikipedia

Before we jump into the Android Sensor Framework, let’s take a brief step back and examine some basic concepts with regards to sensors. As humans, we have five senses: sight, hearing, taste, smell and touch. These give us the ability to receive input of various kinds to understand and analyze the world around us. The same principle applies to a mobile device. Mobile devices have lots of sensors which allow them to understand and analyze the world around them. However, unlike human senses, smartphones have many more sensor types available. There are over three hundred different types of sensors which exist for different domains and industries. Smartphones today contain just the bare minimum of these various sensors. In the near future mobile devices will likely have many more sensors built in., In fact, few companies like Samsung have started mounting more and more sensors in the device. For example, the Samsung Galaxy S5 contains ten different sensors. Sensors are becoming an essential part of the mobile device. If you ask me what the major differences are between a feature phone and smartphone, my first response would be “sensors.” Sensors are one of the main features that distinguishes a feature phone and a smartphone.  One way to interpret the “smart” in smartphone would be:


S = Sensors
M = Multi-Tasking
A = Applications
R = Real-Time (almost)
T = Touch Screen

Android Sensor Concepts
Android devices have many sensors, such as an accelerometer, a light sensor, or a proximity sensor. Availability of sensors are different per model […]

By |January 12th, 2015|Android, mobile|Comments Off on Android Sensor Support: Tap into the Device’s Environment|

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 |December 15th, 2014|Android, Best Practices, Design, Thread|Comments Off on Android Loaders: the Data Forklift for your App|

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

Android Animation – Part 2: Animators

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.

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 |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 |October 10th, 2014|Android, Design|Comments Off on Android Animation – Part 1|

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 |October 2nd, 2014|Android, Design|Comments Off on Android Alarm Ins and Outs|