Gradle for Android Online Course
Just a reminder: I am teaching a half-day online course on behalf of Gradleware, covering the basics of Gradle for Android:
- How to get it set up
- How to get your first Gradle build file working
- How the new project structure works
- How to take advantage of build types and product flavors
- How to integrate other projects and third-party code as dependencies
- How to use Gradle for Android to automate other aspects of your project builds
You can see a larger outline of the virtual course on the Gradleware Web site.
The course is Tuesday, August 19, 2014, from 8:30am to 12:30pm (Pacific Standard Time).
—Jul 21, 2014
Webinars: Memory and Security
A pair of webinar topics have been added to the roster for August through early October.
One is a two-hour Webinar on memory management, a trimmed-down and slightly-updated version of a presentation that I delivered at AnDevCon Boston 2014. Here we will examine why you have as many problems as you do, what tools exist to help you determine if you have a memory problem (and where that problem may come from), and some tips for better managing the memory that you have.
The other is “The Security Problems You Aren’t Thinking About”, reviewing a variety of ways in which your app could have security problems, particularly using APIs and Android capabilities that you might think would not present such problems. This is based in part on a conference presentation I delivered at DevWeek 2014 earlier this year.
As with past webinars, these are each scheduled for four different dates and times, to try to provide you with enough options to find one that you can attend.
Subscribers can visit their Warescription page to get the discount codes for these and the other scheduled webinars, though they are also open to the public.
If you have any questions regarding the webinars, let me know.
—Jul 08, 2014
A Uri Is Not (Necessarily) a File
Google is advising developers to stop sending
Uri values to other apps, whether via the
data field in an
ACTION_VIEW) or via an extra (e.g.,
ACTION_SEND). There is no guarantee that the other app will have the ability to access that file, and making the file
MODE_WORLD_READABLE is not great from a security standpoint.
Instead, you will increasingly need to handle the receipt of
Ideally, nowadays, those
Uri values are “openable”. You can perform the following operations on such
Open them via
openInputStream() (and occasionally
Find their MIME type via
Find out their
SIZE — the
OpenableColumns — via a
query() on the
Uri (again, using a
ContentResolver, or in theory a
FileProvider from the Android Support library serves openable
Uri values from files on internal and external storage. My
StreamProvider serves openable
Uri values from more locations, including assets and raw resources. The Storage Access Framework is designed around openable
Uri values. And you can create your own
ContentProvider that serves up openable
The legacy convention was that a
Uri might not be openable directly. Instead, it pointed to a database row, retrievable via
query(), and you would look in the
_DATA column for how to access the actual data. Some providers no doubt continue to use this pattern. The rules for what the
_DATA column would be were not well documented, but by convention they tended to be a path to a file. The problem is that this runs afoul of Google’s current guidance, as there is no guarantee that other apps can access such a file.
Do not blindly assume that if you get a
Uri that it is for the
_DATA pattern. If you
Uri and do not get a
_DATA value back, try using the
Uri directly with
ContentResolver. Or, perhaps do the inverse: try to open a stream on the
Uri, and if that fails, then see if the
_DATA pattern is in play.
An increasing percentage of the
Uri values you get will be openable, as more and more developers adopt
FileProvider, the Storage Access Framework, and other things that adopt the openable-
Uri pattern. Ignoring such
Uri values, such as by crashing or rejecting a request when you do not find a
_DATA value, will diminish the value of your app.
A hat tip to Stack Overflow users iforce2d and matiash for spurring me to do more analysis of some prominent Android apps that crashed when accessing
—Jul 04, 2014
Consuming AARs from Eclipse
Increasingly, you will find that libraries for Android developers come only in AAR form. For example, many of the libraries that are part of the “L” Developer Preview have only been shipped to date in AAR form.
This is wonderful if you are using Gradle for Android, with or without Android Studio. It is less than wonderful if you are using Eclipse/ADT.
UPDATE: If you are using Eclipse/ADT with Maven, the
android-maven-plugin supports AARs, which I had forgotten when I originally wrote this post. Many thanks to William Ferguson for slapping me with an appropriately-sized trout for missing that.
Fortunately, a StackOverflow user named
FD_ came up with a basic recipe for converting an AAR into an Android library project, one that can be used from Eclipse/ADT. I have tested the recipe, have confirmed that it appears to work, and have created a Ruby script to automate the conversion.
The steps that my
deaar script goes through are reminiscent of
UnZIP the AAR into some directory.
Create an empty directory that will be the home for the Android library project. For the rest of these steps, I will refer to this as “the output directory”.
assets/ directories from the AAR into the output directory.
libs/ directory in the output directory. Copy into
classes.jar from the root of the unZIPped AAR, plus anything in
libs/ in the AAR (e.g.,
mediarouter-v7 has its own JAR of proprietary bits).
Decide what build SDK you want to try to use. You might just choose the highest SDK version you have installed. Or, you can use the
android:minSdkVersion and the
-vNN resource set qualifiers to get clues as to what a good build SDK might be. If desired, create a
project.properties file with a
target=android-NNN line, where NNN is your chosen build SDK. Or, you can address this in Eclipse later on.
Import the resulting project into Eclipse, and if needed adjust the build SDK (Project > Properties > Android). Also, you will need to attach to this library project any library projects it depends upon (e.g.,
mediarouter-v7 depends upon
This is all based on the current AAR packaging, and therefore is subject to change.
Also, be sure to see if the AAR is natively available as an Eclipse-friendly Android library project, such as from an open source project’s repository. For example, all of my CWAC libraries ship as Eclipse-friendly Android library projects, in addition to AARs (and, for those not needing resources, JARs). This sort of AAR conversion should be an avenue of last resort, not the first thing you try.
If you try the
deaar script and run into problems with it, please use the support options listed in the project’s
README. If you run into AARs that do not appear to work using this script, drop me a line.
—Jul 03, 2014
The Busy Coder's Guide to Android Development Version 5.9 Released
Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 5.9, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!
This updates begins the Big Book Pivot of 2014. Of note on the pivot:
All of the samples in the trails chapters have been de-Sherlocked, using the native action bar and fragments. They also all have
build.gradle files, albeit ones using the classic Eclipse project structure and relying upon
libs/ instead of Maven dependencies.
The tutorials have also been de-Sherlocked, using the native action bar and fragments. They also have been updated to simplify them somewhat (e.g., get rid of
DownloadManager dependnecy) and use better techniques (e.g., event bus instead of broadcasts).
For those of you who are part-way through the tutorials using an earlier edition of the book, you are probably best suited to continue using the earlier edition. Your alternative will be to start over.
Also, the sheer number of changes means that it looks like a lot of the chapters were updated, though in many cases it is mostly just changing superclasses, imports, and the like.
Beyond the pivot work, this update includes:
A new chapter on the Android 4.4 printing framework
A new chapter on creating a
MediaRouteProvider, to allow
RemotePlaybackClient-enabled apps to work with your own custom remote media player
A completely rewritten chapter on BlackBerry, to bring the coverage up to speed for the 10.3 BlackBerry OS and its Android runtime
Improvements to the coverage of Gradle,
inSampleSize, and Fire TV
Various errata fixes
The next update will be the milestone Version 6.0 (“Motto: Trying To Stay Ahead of Android Version Numbers”). This update will include Android Studio coverage, specifically:
Android Studio instructions will be added to the tutorials, along with changing the tutorials’ command-line instructions to move to Gradle and away from Ant
Covering Android Studio equivalents to everything in the book that covers Eclipse
Adding Gradle build files for all of the core chapters’ samples, and ensuring that all of the projects can be loaded into Android Studio (despite using the Eclipse project structure for most of them, to maintain compatibility with Eclipse)
I also plan to clean up all of the core chapters, with rewrites as needed.
I will cover bits and pieces of new material, but not that much, along the lines of today’s Version 5.9. Once the pivot is behind me, I can return to my regular focus on expanding coverage in new areas, with a particular 2014 emphasis on “L”.
Version 6.0 is tentatively slated for release in early September.
—Jul 01, 2014