Thursday, June 28, 2012

Android SDK Tools, Revision 20

[This post is by Xavier Ducrohet, Tech Lead for the Android developer tools]

Along with the preview of the Android 4.1 (Jelly Bean) platform, we launched Android SDK Tools R20 and ADT 20.0.0. Here are a few things that we would like to highlight.

    Application templates: Android ADT supports a new application templates for creating new application, blank activity, master-detail flow, and custom view. These templates support the Android style guide thus making it faster and easier to build beautiful apps. More templates will be added over time.

    Tracer for GLES: With this new tool you can capture the entire sequence of OpenGL calls made by an app into a trace file on the host and replay the captured trace and display the GL state at any point in time.

    Device Monitor: To help you to easily debug your apps, all the Android debugging tools like DDMS, traceview, hierarchyviewer and Tracer for GLES are now built into one single application.

    Systrace: Improving app performance does not have to be a guesswork any more. Systrace for Jelly Bean and above lets you easily optimize your app. You can capture a slice of system activity plus additional information tagged from the Settings > Developer Options > Monitoring: Enable traces or with specific calls added to your application code.

To learn more on the layout editor, XML editing, build system & SDK Manager improvements, please read the ADT 20.0.0 and SDK Tools R20 release notes.

Join us today, June 28th, at the “What’s new in Android developer tools” session for some fun tool demos and a sneak-peak into what’s coming next.

Wednesday, June 27, 2012

Introducing Android 4.1 (Jelly Bean) preview platform, and more

[This post is by Angana Ghosh, Product Manager on the Android team]

At Google I/O today we announced the latest version of the Android platform, Android 4.1 (Jelly Bean). With Jelly Bean, we’ve made the great things about Android even better with improved system performance and enhanced user features.

Improvements include a smoother and more responsive UI across the system, a home screen that automatically adapts to fit your content, a powerful predictive keyboard, richer and more interactive notifications, larger payload sizes for Android Beam sharing and much more. For a lowdown on what’s new, head over to the Jelly Bean platform highlights.

Of course, Jelly Bean wouldn’t be complete without a healthy serving of new APIs for app developers. Here are some of the new APIs that Jelly Bean introduces:

    Expandable notifications: Android 4.1 brings a major update to the Android notifications framework. Apps can now display larger, richer notifications to users that can be expanded and collapsed with a pinch. Users can now take actions directly from the notification shade, and notifications support new types of content, including photos.

    Android Beam: In Android 4.1, Android Beam makes it easier to share images, videos, or other payloads by leveraging Bluetooth for the data transfer.

    Bi-directional text support: Android 4.1 helps you to reach more users through support for for bi-directional text in TextView and EditText elements.

    Gesture mode: New APIs for accessibility services let you handle gestures and manage accessibility focus. Now you can traverse any element on the screen using gestures, accessories, you name it.

    Media codec access: Provides low-level access to platform hardware and software codecs.

    Wi-Fi Direct service discoverability: New API provides pre-associated service discovery letting apps get more information from nearby devices about the services they support, before they attempt to connect.

    Network bandwidth management: New API provides ability to detect metered networks, including tethering to a mobile hotspot.

For a complete overview of new APIs in Jelly Bean, please read the API highlights document. Note that this is a preview of the Jelly Bean platform. While we’re still finalizing the API implementations we wanted to give developers a look at the new API to begin planning app updates. We’ll be releasing a final platform in a few weeks that you should use to build and publish applications for Android 4.1.

For Android devices with the Google Play, we launched the following at Google I/O today:

    Smart app updates: For Android 2.3, Gingerbread devices and up, when there is a new version of an app in Google Play, only the parts of the app that changed are downloaded to users’ devices. On average, a smart app update is a third the size of a full apk update. This means your users save bandwidth and battery and the best part? You don’t have to do a thing. This is automatically enabled for all apps downloaded from Google Play.

    App encryption: From Jelly Bean and forward, paid apps in Google Play are encrypted with a device-specific key before they are delivered and stored on the device. We know you work hard building your apps. We work hard to protect your investment.

    Google Cloud Messaging for Android: This is the next version of C2DM and goes back to Froyo. Getting started is easy and has a whole bunch of new APIs than C2DM has to offer. If you sign-up for GCM, you will be able to see C2DM and GCM stats in the Android developer console. Most importantly, the service is free and there are no quotas. [Learn more.]

Starting from today, over 20 Android sessions at Google I/O will deep-dive in many of these areas. Join us in-person or follow us live.

Thursday, June 21, 2012

Replying to User Reviews on Google Play

[This post is by Trevor Johns from the Android team — Tim Bray]

User reviews on Google Play are great for helping people discover quality apps and give feedback to developers and other potential app users. But what about when developers want to give feedback to their users? Sometimes a user just needs a helping hand, or perhaps a new feature has been added and the developer wants to share the good news.

That’s why we’re adding the ability for Google Play developers to respond to reviews from the Google Play Android Developer Console. Developers can gather additional information, provide guidance, and — perhaps most importantly — let users know when their feature requests have been implemented.

We’ll also notify the user who wrote the review via email that the developer has responded. Users can then contact the developer directly if additional followup is needed or update their review.

We’re releasing this feature today to those with a Top Developer badge (). And based on feedback from users and developers, we will offer it to additional Google Play developers in the future.

Conversations are meant to be two-sided, and facilitating discussion between developers and users will ultimately yield better apps, to the benefit of everyone.

Helping you build beautiful, powerful, successful apps

[This post is by Billy Rutledge, Director of Developer Relations for Android. — Tim Bray]

Just in time for Google I/O next week, the Android Developers site is stepping into a new look that is streamlined, simplified, and refocused. A developer’s tasks fall into three baskets: Designing, developing, and distributing. We're trying to make's organization reflect this reality, shepherding you through the app development life cycle, from start to finish.


Earlier this year, we launched Android Design, an online style guide which lays out the principles, building blocks, and patterns for excellence in Android user interfaces. It seems to be working; every day, we see more and more beautiful apps arriving in Google Play. At I/O, we’ll continue to talk design, kicking off with Android Design for Success, led by Matias Duarte.


An Android app should be fast, powerful and useful. With Android Training, one of the many parts of the Develop section that we continue to build out, we lay out best practices in a variety of framework topics to help you achieve those goals. If you’re at I/O and you’re interested in Android tools, be sure to start off your show with What’s new in Android Developers’ Tools.


The most important piece of the piece of the puzzle is about getting your app in front of millions and millions of Android users on Google Play. That’s why we added a section on distributing your app — a peek into the world of publishing and promoting your app. Chris Yerga on the Play team will be kicking off our how-to sessions on distributing your with Android apps in Google Play.

This is just a small sample of the Android sessions at Google I/O, many of which will be live-streamed so you can follow along even if you can’t make it out to San Francisco. In the meantime, we hope you find the new Android Developer site much more useful as you build great apps.

Join the discussion on

+Android Developers

Sunday, June 3, 2012

Using DialogFragments

[This post is by David Chandler, Android Developer Advocate — Tim Bray]

Honeycomb introduced Fragments to support reusing portions of UI and logic across multiple activities in an app. In parallel, the showDialog / dismissDialog methods in Activity are being deprecated in favor of DialogFragments.

In this post, I’ll show how to use DialogFragments with the v4 support library (for backward compatibility on pre-Honeycomb devices) to show a simple edit dialog and return a result to the calling Activity using an interface.
For design guidelines around Dialogs, see the Android Design site.

The Layout

Here’s the layout for the dialog in a file named fragment_edit_name.xml.

<LinearLayout xmlns:android=""
android:layout_width="wrap_content" android:layout_height="wrap_content"
android:layout_gravity="center" android:orientation="vertical" >

android:id="@+id/lbl_your_name" android:text="Your name"
android:layout_width="wrap_content" android:layout_height="wrap_content" />

android:layout_width="match_parent" android:layout_height="wrap_content"
android:imeOptions="actionDone" />

Note the use of two optional attributes. In conjunction with android:inputType=”text”, android:imeOptions=”actionDone” configures the soft keyboard to show a Done key in place of the Enter key.

The Dialog Code

The dialog extends DialogFragment, and since we want backward compatibility, we’ll import it from the v4 support library. (To add the support library to an Eclipse project, right-click on the project and choose Android Tools | Add Support Library...).

// ...

public class EditNameDialog extends DialogFragment {

private EditText mEditText;

public EditNameDialog() {
// Empty constructor required for DialogFragment

public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_edit_name, container);
mEditText = (EditText) view.findViewById(;

return view;

The dialog extends DialogFragment and includes the required empty constructor. Fragments implement the onCreateView() method to actually load the view using the provided LayoutInflater.

Showing the Dialog

Now we need some code in our Activity to show the dialog. Here is a simple example that immediately shows the EditNameDialog to enter the user’s name. On completion, it shows a Toast with the entered text.

// ...

public class FragmentDialogDemo extends FragmentActivity implements EditNameDialogListener {

public void onCreate(Bundle savedInstanceState) {

private void showEditDialog() {
FragmentManager fm = getSupportFragmentManager();
EditNameDialog editNameDialog = new EditNameDialog();, "fragment_edit_name");

public void onFinishEditDialog(String inputText) {
Toast.makeText(this, "Hi, " + inputText, Toast.LENGTH_SHORT).show();

There are a few things to notice here. First, because we’re using the support library for backward compatibility with the Fragment API, our Activity extends FragmentActivity from the support library. Because we’re using the support library, we call getSupportFragmentManager() instead of getFragmentManager().

After loading the initial view, the activity immediately shows the EditNameDialog by calling its show() method. This allows the DialogFragment to ensure that what is happening with the Dialog and Fragment states remains consistent. By default, the back button will dismiss the dialog without any additional code.

Using the Dialog

Next, let’s enhance EditNameDialog so it can return a result string to the Activity.

// ...
public class EditNameDialog extends DialogFragment implements OnEditorActionListener {

public interface EditNameDialogListener {
void onFinishEditDialog(String inputText);

private EditText mEditText;

public EditNameDialog() {
// Empty constructor required for DialogFragment

public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_edit_name, container);
mEditText = (EditText) view.findViewById(;

// Show soft keyboard automatically

return view;

public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
if (EditorInfo.IME_ACTION_DONE == actionId) {
// Return input text to activity
EditNameDialogListener activity = (EditNameDialogListener) getActivity();
return true;
return false;

For user convenience, we programmatically focus on the EditText with mEditText.requestFocus(). Alternatively, we could have used the <requestFocus/> tag in the layout XML to do this; however, in some cases it’s preferable to request focus programmatically. For example, an OnFocusChangeListener added in the Fragment’s onCreateView() method won’t get called if you request focus in the layout XML.

If the user focuses on an EditText, the soft keyboard will automatically appear. In order to force this to happen with our programmatic focus, we call getDialog().getWindow().setSoftInputMode(). Note that many Window operations you might have done previously in a Dialog can still be done in a DialogFragment, but you have to call getDialog().getWindow() instead of just getWindow(). The resulting dialog is shown on both a handset and tablet (not to scale):

The onEditorAction() method handles the callback when the user presses the Done key. It gets invoked because we’ve set an OnEditorActionListener on the EditText. It calls back to the Activity to send the entered text. To do this, EditNameDialog declares an interface EditNameDialogListener that is implemented by the Activity. This enables the dialog to be reused by many Activities. To invoke the callback method onFinishEditDialog(), it obtains a reference to the Activity which launched the dialog by calling getActivity(), which all Fragments provide, and then casts it to the interface type. In MVC architecture, this is a common pattern for allowing a view to communicate with a controller.

We can dismiss the dialog one of two ways. Here we are calling dismiss() within the Dialog class itself. It could also be called from the Activity like the show() method.

Hopefully this sheds some more light on Fragments as they relate to Dialogs. You can find the sample code in this blog post on Google Code.

References for learning more about Fragments: