HiQES Blog - Page 2 of 3

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|

Android’s AsyncTask Explained

The AsyncTask is one of the handiest classes available in an Android developer’s toolbox. The simple background threading it can add to your app is invaluable, especially for short lived work. However, it is often a source of pain for new and experienced developers alike. This is due in part to not understanding Android’s threading mechanisms, lifecycle events, and understanding what AsyncTask does and does not do for you. I’m going to start with some background then explain AsyncTasks to help you better leverage them in your code.

Android Threading
Before we dive off into the details of AsyncTask, let’s take a quick look at Android’s threading model. Android applications (generally) run in their own separate process space. This is done for security isolation and stability and allows each app to have its own instance of the Dalvik or ART virtual machine. However, it doesn’t stop there. Every application has several threads running by default.

The screen cap above is from Android Studio’s debug view when attached to a very simple “Hello World” type application. You can quickly see in the debugger pane’s “Threads” tab at the bottom there are a total of 11 threads running in this simple application! For the new Android developer, this is likely very unexpected. The Android folks weren’t kidding when they said there’s no Java or C style “main” entry point. These threads are all managed by the system, some of which are owned by the virtual machine (e.g. the GC, or garbage collector thread) and other parts owned and managed by the Android framework itself. Note thread number 1, the “main” thread. You may have seen or heard of this in your reading or development. It’s also commonly referred to […]

By Larry Schiefer|September 4th, 2014|Android, Best Practices, Design, Thread|1 Comment|

Mobile Presence via Custom App

Every few weeks we are presented with updated market research showing that mobile technologies are steadily taking over the computing world. In fact, in terms of technology adoption, mobile is moving faster than any technology before it. This mobile growth statistics infographic from 2013 is very telling and shows some staggering numbers.

The chart showing the time it took to reach 50m users is quite telling: the Internet boom of the late 90’s and early 2000’s took 4 years to reach 50m users, the “Draw Something” app took 50 days. That’s the same number of users is less than 5% of the time. Obviously, not all apps have that kind of success. But, the potential is certainly there so it becomes a matter of how to tap into it.

What does this really mean for businesses? It means a mobile strategy. This large and expanding environment is ripe with opportunity and without a strategy your business is missing out. Broadly, the obvious strategy items to tackle are:

A mobile website. All businesses need one.
A mobile presence, more than just the website.

While the mobile website is important, other stats show user’s preference toward mobile apps rather than mobile websites. Obvious, you could choose to up your business’ mobile presence by spending your marketing budget on mobile ads as well as using social media. However, that’s not really what your business is after: your business needs a custom app. But throwing any old app up with your business name on it is not likely to make a huge impact by itself. This type of custom app can lead to some initial interest but very quickly get poor reviews or no adoption. We’ve seen this in the mobile marketplaces with […]

By Larry Schiefer|August 28th, 2014|Android, Best Practices, Design, Enterprise, mobile, Software, Tablet|Comments Off|

Android Security Part 2: Android Permissions

Welcome to Android Security Part 2. Previously, I discussed some of the basics you as an app author can do to better secure your apps. This simple steps can go a long way to secure your app and its data on the device. In this installment, I will discuss Android defined permissions and how you can use them to secure your apps.

Android Permissions vs. Linux Permissions
In Android Security Part 1, I outlined the Android App Sandbox, which is the base of security within the platforms. The sandbox enforces permissions at the user/group level for an app process. As you recall, this is managed by the Linux kernel which is powering our Android device. Linux kernel defined user and group IDs are used along with filesystem permissions to keep an app contained to its memory and storage areas. But what happens when you have app components which are exposed using Android facilities such as Intents or Binder? This is where Android’s permissions architecture comes into play.

The Android framework builds upon the base security model by defining additional permissions which are required to use certain features. For example, in order to use the GPS on the device, your app must hold the Manifest.permission.ACCESS_FINE_LOCATION permission. If we look at this definition in the Android documentation, you can see that it is defined to be a String: “android.permission.ACCESS_FINE_LOCATION”. This permission, like many others, are defined by the framework and enforced appropriately. They provide finer grained control over protected resources or features in the system. These permissions are “granted” by the user when they install an app. The biggest complaints about the permissions system are that it is a blanket “all or nothing” at install time and there are […]

By Larry Schiefer|February 25th, 2014|Android, Best Practices, Security|1 Comment|

Android Security Part 1: App Basics

I recently had the opportunity to work with an exceptional group of engineers deploying Android on a new device. One of their biggest concerns was security of the platform. The reason? Their device has specific requirements for the protection of data and platform integrity. They had some great concerns (and attack techniques) regarding platform as well as app security, which many vendors do not consider. Often, vendors are in such a rush to get product to market, security is glossed over. In this multi-part series I’m going to cover Android security options for Apps, SDK vendors and platforms.

Android Security Foundation: The App Sandbox
Android’s app model provides developers with a rich set of features and a relatively secure environment, particularly for simple apps. Every app under Android is “sandboxed” into its own process and filesystem space. Taking advantage of the Linux kernel’s process space protection mechanisms, Android assigns each installed app a unique user ID. Unlike traditional desktop operating systems (Linux, Windows, Mac, etc.), Android (generally speaking) uses the concept of the user ID to represent an app rather than a human user. This allows the kernel to keep apps confined in memory, restrict access to underlying hardware or services, and restrict access to the filesystem on the device. By default, each app’s data and resources are contained in a location which only the app and the core framework can access. This design is central to the Android security model.

More advanced apps are becoming commonplace, these apps communicate with each other or with devices/servers via networks. Let’s take a look at some basic security items for your apps which you may be omitting.

Exporting Components
At the highest level, Android apps are made up of one or more of four basic components: Activity, Service, ContentProvider or BroadcastReceiver. These are building blocks which apps use to provide their functionality. […]

By Larry Schiefer|February 3rd, 2014|Android, Best Practices, Security|2 Comments|

ChromeOS to take over Android? Not likely.

I recently read an article where a technical reporter was speculating that Google’s next big move would be for ChromeOS to make inroads into the Smartphone market, essentially replacing Android for higher end devices. The argument was based upon these points:

ChromeOS is gaining in popularity, so manufacturers will find it compelling to use
The new system-on-a-chip (SoC) devices used to power our mobile devices are ever increasing in computing power
Google’s recent Android 4.4 (KitKat) release actually reduced the hardware requirements for new platforms, making it prime for low end devices (i.e. feature phones)

Just look at the latest offerings from Qualcomm, Intel, Nvidia and TI and you can see why the reporter might think this. Each of these vendors is rolling out chipsets with multiple processing cores plus hardware acceleration for graphics, encryption and multimedia. As of Nov. 2013, smartphones accounted for just under 64% of all mobile subscribers in the U.S. Worldwide, the numbers drop by about 1/3, putting the total smartphone market size around 22%. Using the previous data source, we can see that tablet numbers are much lower, at only about 6% of market penetration; but, the tablet market has made it to the 6% mark faster than the smartphone did. The tablet market is exploding, which explains why it seems there is a new tablet every other week on the market.

Both the smartphone and tablet markets are ripe with opportunity. Chips are getting faster, tablets are taking off and people expect more out of their connected devices. Couple this with Android 4.4 dropping the minimum memory requirement to 512MB and it certainly makes you think. While this sounds interesting on the surface, the real likelihood of this happening is not very high. To explain why, you have to look closely at each OS, the markets they serve and the backing technology. First, for those not […]

By Larry Schiefer|January 28th, 2014|Android, ChromeOS, Design, mobile, Software, Tablet|Comments Off|

Android Developer Conference San Francisco 2013 HIQES Presentations

For those interested parties who were not able to attend AnDevCon in San Francisco Nov. 13-15, my presentations and demo code can be found at the links below.
A Deep Dive into RenderScript
RenderScript is a computing platform available in Android starting at API 11. It has since been added to the support library for devices starting at API level 8. This this class we cover some background, how to write RenderScript and even some internals. The demo code is a Mandelbrot fractal generator and is also used to gather performance numbers between Java, multi-threaded Java, RenderScript, native and multi-threaded native implementations.

You can find the presentation and demo code here.

Exploring SDK Add-ons and Extras for Devices
SDK add-ons provide a mechanism for OEMs to support their value added features for end developers in an extensible way. Additionally, 3rd party software providers can provide SDK extras to developers to leverage their features and functions. Some great examples of these are the HTC Sense SDK and Google AdMob. In this class we cover the details of SDK add-ons and extras, how to create platform SDK add-ons and how to make these available to developers for easy integration into the Android SDK.

You can find the presentation and demo code here.

By Larry Schiefer|December 1st, 2013|Android, Software|2 Comments|

Android Processes and Threads: New Pluralsight Course

Do you know what is going on under the hood of your Android app? Do you know how to effectively use threads and processes to get the most out of your apps?

Android Online Training!
Pay our good friends at Pluralsight a visit and watch my new course on Android Processes and Threads. In this course I explore the variety of threading options you have available to you as a developer as well as cover the details of some subtle process characteristics and how to leverage them. This is not just a boring lecture, but a great dive into the platform features with working demos. And all of this in under 2 hours! Whether you are an old hat at Android app development or new to Android, this course will give you important details about how to implement effective multi-tasking.

* The Android Student image is licensed under the Creative Commons Attribution 3.0 License and was found here: http://bit.ly/GXexHK

By Larry Schiefer|October 14th, 2013|Android, Software, Training|Comments Off|

Previous 123 Next