[This post is by Xavier Ducrohet and Reto Meier of the Android engineering team. — Tim Bray.]
The Android emulator is a key tool for Android developers in building and testing their apps. As the power and diversity of Android devices has grown quickly, it’s been hard for the emulator keep pace.
Today we’re thrilled to announce several significant improvements to the emulator, including a dramatic performance upgrade and support for a broader range of hardware features, notably sensors and multi-finger input.
The system image we’re shipping today has built-in GPU support (Android 4.0.3 r2). With Android’s growing reliance on using the GPU to improve performance, the difference is significant. In the video below, the emulator is still interpreting ARM instructions; the performance boost is the effect of putting the GPU to work.
As a bonus, since we’re now supporting OpenGL ES 2.0, your OpenGL games can now run inside the emulator.
Please note that there are a lot of GPUs out there, and we haven’t tested all of them for this beta release, so let us know if you have feedback or encounter issues.
The hardware features of mobile devices are a significant part of what makes them a unique platform for development, so we’re also pleased to announce that in addition to the camera support we added last year, it’s now possible to use a tethered Android device to supply inputs for sensors and multi-touch input.
We’re working on providing emulator support for more hardware features including Bluetooth and NFC.
We’ve also improved the CPU performance of the Android emulator. Hardware floating point operation has been available for system images since Ice Cream Sandwich (Android 4.0), allowing CPU operations to be emulated roughly twice as quickly.
Last week’s r17 developer tools release included x86 system images and host drivers (available through the SDK Manager), allowing the emulator to access the host CPU natively and offer significantly faster execution.
This video shows a CPU-bound application on two emulators running the same system image, one with virtualization, one without.
Because the Android platform allows deep interaction between applications, and with system components, we need to provide an emulator with a complete system image. Our emulator virtualizes a complete device: hardware, kernel, low-level system libraries, and app framework.
Of course, the system being emulated typically has an ARM CPU; historically, we’d been emulating those instructions in software, and that worked OK until the advent of tablet support with additional animations and complexity in Android 3.0.
The missing pieces were the completion of Android x86 support, and the GPU support in last week’s release of SDK Tools r17. This works by funneling the OpenGL ES 2.0 instructions from the emulator to the host OS, converted to standard OpenGL 2.0, and running natively on the host GPU.
The Android ecosystem has a lot of devices in many different form factors. Developers need a good way of testing these apps without having to own everything out there and a fast, rich Android emulator is immensely helpful.
We hope that these new improvements will make the emulator a more useful tool in your development and testing, and look forward to improving it further for you.
[This post is by Nadav Aharony, a product manager on the Android team — Tim Bray]
We’re rolling out new developer features for the Gmail Android app: It now includes a public ContentProvider that you can use to retrieve label data. You can use this to access up-to-date unread counts for specific accounts’ inboxes and labels.
To use the API, the Gmail app needs to be at version 2.3.6 or higher on Froyo or Gingerbread; 4.0.5 or higher on Honeycomb and ICS. Before using it, be sure you first check the Gmail app version; we’ve provided a handy GmailContract.canReadLabels(Context) method to help with this. Your app will need the com.google.android.gm.permission.READ_CONTENT_PROVIDER permission.
The Labels API needs a valid Gmail account to build a query for per-label information. Assuming the GET_ACCOUNTS permission, the AccountManager can be used to fetch this information:
// Get the account list, and pick the first one
final String ACCOUNT_TYPE_GOOGLE = "com.google";
final String[] FEATURES_MAIL = {
"service_mail"
};
AccountManager.get(this).getAccountsByTypeAndFeatures(ACCOUNT_TYPE_GOOGLE, FEATURES_MAIL,
new AccountManagerCallback() {
@Override
public void run(AccountManagerFuture future) {
Account[] accounts = null;
try {
accounts = future.getResult();
if (accounts != null && accounts.length > 0) {
String selectedAccount = accounts[0].name;
queryLabels(selectedAccount);
}
} catch (OperationCanceledException oce) {
// TODO: handle exception
} catch (IOException ioe) {
// TODO: handle exception
} catch (AuthenticatorException ae) {
// TODO: handle exception
}
}
}, null /* handler */);Once you’ve got the email account, you can get a ContentProvider URI to query against. We've provided a simple support class called GmailContract.java for constructing the URI and defining the columns and relevant constants.
You can access any label, predefined or user-defined. The predefined labels include (you have to use symbolic constants rather than these strings, see below):
Priority Inbox
Starred
Chats
Sent
Drafts
All mail
Spam
Trash
To obtain a Cursor with information for all labels in an account, your app can either query this URI directly or use a CursorLoader. Here’s an example:
Cursor c =
getContentResolver().query(GmailContract.Labels.getLabelsUri(selectedAccount),
null, null, null, null);You can query and watch for changes on a single label by storing the URI value in the GmailContract.Labels.URI column from the cursor data.
The NAME value for pre-defined labels can vary by locale, so don’t use GmailContract.Labels.NAME. Instead, identify pre-defined labels like Inbox, Sent or Drafts using the String value in the GmailContract.Labels.CANONICAL_NAME column. Here’s an example:
// loop through the cursor and find the Inbox
if (c != null) {
final String inboxCanonicalName = GmailContract.Labels.LabelCanonicalName.CANONICAL_NAME_INBOX;
final int canonicalNameIndex = c.getColumnIndexOrThrow(GmailContract.Labels.CANONICAL_NAME);
while (c.moveToNext()) {
if (inboxCanonicalName.equals(c.getString(canonicalNameIndex))) {
// this row corresponds to the Inbox
}
}
}If you choose to use a CursorLoader, it will keep the label counts up to date as they change over time.
You can find a sample app that makes use of the new API here. The app provides a basic readout of label and message-count information.
People care about their incoming mail; we’re looking forward to seeing what you do with access to this information. We’re also open to suggestions as to how to improve and extend this new API.
