Android at Google I O 2013 Keynote Wrapup

The last year has been an exciting one for Android developers, with an incredible amount of momentum. In fact, over 48 billion apps have been downloaded from Google Play to date, with over 2.5 billion app downloads in the last month alone.

This week, at Google I/O, our annual developer conference, we’re celebrating this momentum, and putting on stage a number of new features and advancements both for the Android platform and Google Play, to help you design, develop and distribute great apps to your users.

We just wrapped up the keynote, and wanted to share a number of those new features; we’ll be spotlighting some of them throughout the week both here, on Google+, and in 36 Android sessions and sandboxes at the Moscone center in San Francisco (with many of the sessions livestreamed at developer.google.com). Enjoy!

Google Play Services 3.1

Google Play Services is our platform for bringing you easier integration with Google products and new capabilities to use in your apps. Today we announced a new version of Google Play Services that has some great APIs for developers.

• Google Play games services give you great new social features that you can add to your games   achievements, leaderboards, cloud save, and real-time multiplayer


• Location APIs make it easy to add location- and context-awareness to your apps through a fused location provider, geofencing, and activity recognition


• Google Cloud Messaging enhancements let you use bidirectional XMPP messaging between server and devices and dismiss notifications


• Cross-Platform Single Sign On, which lets your users sign in once, for all of their devices using Google+ Sign-In.

Android Studio: A new IDE for Android development

Today we announced a new Integrated Development Environment (IDE) built just for Android, with the needs of Android developers in mind. It’s called Android Studio, it’s free, and it’s available now to try as an early access preview.

To build Android Studio, we worked with with JetBrains, creators of one of the most advanced Java IDEs available today. Based on the powerful, extensible IntelliJ IDEA Community Edition, weve added features and capabilities that are designed specifically for Android development, to simplify and optimize your daily workflow for creating Android apps.

Google Play Developer Console: a better distribution experience

Building awesome Android apps is only part of the story. Today we announced great new features in the Google Play Developer Console that give you more control over how you distribute your app and insight into how your app is doing:

• App translation service: a pilot program that lets you purchase professional translations for your app directly from the Developer Console.


• Revenue graphs: a new tab in the Developer Console gives you a summary of your app global app revenue over time.


• Alpha and beta testing and staged rollouts: you can now distribute your app to controlled alpha and beta test groups, or do staged rollouts to specific percentages of your userbase.


• Optimization tips: design your app for tablets and understand how to expand your app into new language markets.


• Google Analytics: launching later this summer, your Google Analytics usage stats will be viewable right in the Developer Console.


• Referral tracking: also launching later this summer, you’ll get a new report in Google Analytics to show what blogs, campaigns, and ads are driving your installs.

Follow the Android Sessions

Join us for the Android sessions today and through the week by livestream. Visit the I/O Live Stream schedule for details.

Read More..

Android Design V2 Now with stencils

[This post is by Android designer Alex Faaborg, on behalf of the entire User Experience team. —Tim Bray]

When we initially released Android Design, by far the number one request we received was for us to release stencils as well. The fine folks on the Android User Experience team are pleased today to release some official Android Design stencils for your mockup-creating pleasure.

With these stencils you can now drag and drop your way to beautifully designed Ice Cream Sandwich (Android 4.0) applications, with grace and ease. The stencils feature the rich typography, colors, interactive controls, and icons found throughout Ice Cream Sandwich, along with some phone and tablet outlines to frame your meticulously crafted creations.

Currently we have stencils available for those venerable interactive design powerhouses Adobe® Fireworks®, and Omni® OmniGraffle® and we may expand to other applications® in the future. The source files for the various icons and controls are also available, created in Adobe® Photoshop®, and Adobe® Illustrator®. Here are the downloads.

We’ll be updating these stencils over time so, as always, please send in your feedback!

Happy mockup making,

— Your friendly Android Design Droids

Read More..

Google Developer Day at GDC

Day 2 of Game Developers Conference 2014 is getting underway and today Google is hosting a special Developer Day at Moscone Center in San Francisco.

Join us at the sessions

Building on yesterday’s announcements for game developers, well be presenting a series of sessions that walk you through the new features, services, and tools, explaining how they work and what they can bring to your games.

Well also be talking with you about how to reach and engage with hundreds of millions of users on Google Play, build Games that scale in the cloud, grow in-game advertising businesses with AdMob, track revenue with Google Analytics, as well as explore new gaming frontiers, like Glass.

If you’re at the conference, the Google Developer Day sessions are a great opportunity to meet the developer advocates, engineers, and product managers of the Google products that drive users, engagement and retention for your games. If you’re remote, we invite you to sit-in on the sessions by joining the livestream below or on Google Developers channel on YouTube.

The Developer Day sessions (and livestream) kick off at 10:00AM PDT (5:00PM UTC). A complete agenda is available on the GDC Developer Day page.

LiquidFun 1.0

Last December we announced the initial release of LiquidFun, a C++ library that adds particle physics, including realistic fluid dynamics, to the open-source Box2D.

To get Google Developer Day started, we’re releasing LiquidFun 1.0, an update that adds multiple particle systems, new particle behaviors, and other new features.

Check out the video below to see what Liquid Fun 1.0 can do, visit the LiquidFun home page, or join todays LiquidFun session at Google Developer Day to learn how LiquidFun works and how to use particle physics in your games. The session starts at 4:35PM PDT (11:35PM UTC).

Join the discussion on



+Android Developers

Read More..

Integrating Application with Intents

Written in collaboration with Michael Burton, Mob.ly; Ivan Mitrovic, uLocate; and Josh Garnier, OpenTable.

OpenTable, uLocate, and Mob.ly worked together to create a great user experience on Android. We saw an opportunity to enable WHERE and GoodFood users to make reservations on OpenTable easily and seamlessly. This is a situation where everyone wins — OpenTable gets more traffic, WHERE and GoodFood gain functionality to make their applications stickier, and users benefit because they can make reservations with only a few taps of a finger. We were able to achieve this deep integration between our applications by using Androids Intent mechanism. Intents are perhaps one of Androids coolest, most unique, and under-appreciated features. Heres how we exploited them to compose a new user experience from parts each of us have.

Designing

One of the first steps is to design your Intent interface, or API. The main public Intent that OpenTable exposes is the RESERVE Intent, which lets you make a reservation at a specific restaurant and optionally specify the date, time, and party size.

Hereʼs an example of how to make a reservation using the RESERVE Intent:

startActivity(new Intent("com.opentable.action.RESERVE",
       Uri.parse("reserve://opentable.com/2947?partySize=3")));

Our objective was to make it simple and clear to the developer using the Intent. So how did we decide what it would look like?

First, we needed an Action. We considered using Intent.ACTION_VIEW, but decided this didnt map well to making a reservation, so we made up a new action. Following the conventions of the Android platform (roughly <package-name>.action.<action-name>), we chose "com.opentable.action.RESERVE". Actions really are just strings, so its important to namespace them. Not all applications will need to define their own actions. In fact, common actions such as Intent.ACTION_VIEW (aka "android.intent.action.VIEW") are often a better choice if youʼre not doing something unusual.

Next we needed to determine how data would be sent in our Intent. We decided to have the data encoded in a URI, although you might choose to receive your data as a collection of items in the Intents data Bundle. We used a scheme of "reserve:" to be consistent with our action. We then put our domain authority and the restaurant ID into the URI path since it was required, and we shunted off all of the other, optional inputs to URI query parameters.

Exposing

Once we knew what we wanted the Intent to look like, we needed to register the Intent with the system so Android would know to start up the OpenTable application. This is done by inserting an Intent filter into the appropriate Activity declaration in AndroidManifest.xml:

<activity android:name=".activity.Splash" ... >
...
  <intent-filter>
    <action android:name="com.opentable.action.RESERVE"/>
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="reserve" android:host="opentable.com"/>
  </intent-filter>
...
</activity>

In our case, we wanted users to see a brief OpenTable splash screen as we loaded up details about their restaurant selection, so we put the Intent Filter in the splash Activity definition. We set our category to be DEFAULT. This will ensure our application is launched without asking the user what application to use, as long as no other Activities also list themselves as default for this action.

Notice that things like the URI query parameter ("partySize" in our example) are not specified by the Intent filter. This is why documentation is key when defining your Intents, which weʼll talk about a bit later.

Processing

Now the only thing left to do was write the code to handle the intent.

    protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       final Uri uri;
       final int restaurantId;
       try {
           uri = getIntent().getData();
           restaurantId = Integer.parseInt( uri.getPathSegments().get(0));
       } catch(Exception e) {
           // Restaurant ID is required
           Log.e(e);
           startActivity( FindTable.start(FindTablePublic.this));
           finish();
           return;
       }
       final String partySize = uri.getQueryParameter("partySize");
       ...
   }

Although this is not quite all the code, you get the idea. The hardest part here was the error handling. OpenTable wanted to be able to gracefully handle erroneous Intents that might be sent by partner applications, so if we have any problem parsing the restaurant ID, we pass the user off to another Activity where they can find the restaurant manually. Its important to verify the input just as you would in a desktop or web application to protect against injection attacks that might harm your app or your users.

Calling and Handling Uncertainty with Grace

Actually invoking the target application from within the requester is quite straight-forward, but there are a few cases we need to handle. What if OpenTable isnt installed? What if WHERE or GoodFood doesnt know the restaurant ID?

	Restaurant ID known	Restaurant ID unknown
User has OpenTable	Call OpenTable Intent	Dont show reserve button
User doesnt have OpenTable	Call Market Intent	Dont show reserve button

Youll probably wish to work with your partner to decide exactly what to do if the user doesnt have the target application installed. In this case, we decided we would take the user to Android Market to download OpenTable if s/he wished to do so.

    public void showReserveButton() {
      
       // setup the Intent to call OpenTable      
       Uri reserveUri = Uri.parse(String.format( "reserve://opentable.com/%s?refId=5449",
               opentableId));
       Intent opentableIntent = new Intent("com.opentable.action.RESERVE", reserveUri);

       // setup the Intent to deep link into Android Market
       Uri marketUri = Uri.parse("market://search?q=pname:com.opentable");
       Intent marketIntent = new Intent(Intent.ACTION_VIEW).setData(marketUri);
      
       opentableButton.setVisibility(opentableId > 0 ? View.VISIBLE : View.GONE);
       opentableButton.setOnClickListener(new Button.OnClickListener() {
           public void onClick(View v) {
               PackageManager pm = getPackageManager();
               startActivity(pm.queryIntentActivities(opentableIntent, 0).size() == 0  ?
                       opentableIntent : marketIntent);
           }
       });
   }

In the case where the ID for the restaurant is unavailable, whether because they dont take reservations or they arent part of the OpenTable network, we simply hide the reserve button.

Publishing the Intent Specification

Now that all the technical work is done, how can you get other developers to use your Intent-based API besides 1:1 outreach? The answer is simple: publish documentation on your website. This makes it more likely that other applications will link to your functionality and also makes your application available to a wider community than you might otherwise reach.

If theres an application that youd like to tap into that doesnt have any published information, try contacting the developer. Its often in their best interest to encourage third parties to use their APIs, and if they already have an API sitting around, it might be simple to get you the documentation for it.

Summary

Its really just this simple. Now when any of us is in a new city or just around the neighborhood its easy to check which place is the new hot spot and immediately grab an available table. Its great to not need to find a restaurant in one application, launch OpenTable to see if theres a table, find out there isnt, launch the first application again, and on and on. We hope youll find this write-up useful as you develop your own public intents and that youll consider sharing them with the greater Android community.

Read More..

Traceview War Story

I recently took my first serious look at Traceview, and it occurred to me, first, that there are probably a few other Android developers who haven’t used it and, second, that this is an opportunity to lecture sternly on one of my favorite subjects: performance improvement and profiling. This is perhaps a little bit Android-101; If you already know all about Traceview, you can stop here and go back to coding.

Making Apps Fast

Here’s a belief that I think I share with most experienced developers: For any app that is even moderately complex, you’re not smart enough to predict what the slow parts are going to be, because nobody is smart enough to predict where software bottlenecks will turn up.

So the smart way to write a fast app is to build it in the simplest way that could possibly work, avoiding egregiously-stupid thing like order-N-squared algorithms and doing I/O on the Android UI thread. Who knows, it might be fast enough, and then you’re done!

If it isn’t fast enough, don’t guess why. Measure it and find out, using a profiler. Actually I’ve been known to do this, when backed into a corner, using things like System.err.println("Entered at" + System.currentTimeMillis()); Fortunately, Android comes with a reasonably decent profiler, so you don’t have to get ugly like that.

Case Study: LifeSaver 2

I have this little utility in Android Market called LifeSaver 2, the details are on my personal blog. At one point, it reads the SMS and phone-call logs out of the system and persists them in a JSON text file on the SD card. Since this is kind of slow, it shows a nice dynamic progress bar. It occurred to me to wonder why it was kind of slow to write a few hundred records into a text file on a device that, after all, has a gigahertz processor.

Somebody who foolishly disregarded my advice above might assume that the slowdown had to be due to the ContentProvider Cursor machinery reading the system logs, or failing that, the overhead of writing to the SD card. A wiser person would instrument the code and find out. Let’s do that.

Turning On Tracing

I went into Saver.java and bracketed the code in its run() method like so:

       public void run() {

            android.os.Debug.startMethodTracing("lsd");

            // ... method body elided

            android.os.Debug.stopMethodTracing();
        }

The first call turns tracing on, the argument "lsd" (stands for Life Saver Debug, of course) tells the system to put the trace log in /sdcard/lsd.trace. Remember that doing this means you have to add the WRITE_EXTERNAL_STORAGE permission so you can save the trace info; don‘t forget to remove that before you ship.

[Update:] Android engineer Xavier Ducrohet writes to remind me: “DDMS has a start/stop profiling button in the ‘device view’. Upon clicking stop it launches TraceView with the trace file. This is not as fine grained as putting start/stopMethodTracing in your code but can be quite useful. For VMs earlier than froyo, the permission is required as well (DDMS basically automate getting the trace from the sd card and saving it locally before calling traceview). For Froyo+ VMs, the VM is able to send the trace file through the JDWP connection and the permission is not needed anymore (which is really useful).” Thanks, Xav!

Then you run your app, then you copy the output over to your computer, and fire up Traceview.

540> adb pull /sdcard/lsd.trace
541> traceview lsd

At this point, you will have noticed three things. First, turning tracing on really slows down your app. Second, the tracefile is big; in this case, 8.6M for a run that took like four seconds. Third, that traceview looks pretty cool.

The bars across the top show the app’s threads and how they dealt out the time; since the Nexus One is single-threaded CPU, they have to take turns. Let’s zero in on one 100-msec segment.

The top line is where my app code is running (the red segment is GC happening), the middle line is the UI thread and the bursts of activity are the ProgressBar updating, and I have no idea what the third thread, named HeapWorker, does, but it doesn’t seem a major contributor to the app’s runtime, so let’s ignore it.

The bottom of the screen is where the really interesting data is; it shows which of your methods burned the time, and can be sorted in a bunch of different ways. Let’s zero in on the first two lines.

Translated into English, this tells us that the top-level routine consumed 100% of the time if you include everything it called (well, yeah), but only 0.9% of the time itself. The next line suddenly starts to get real interesting: java.io.PrintStream.println(Object) and whatever it calls are using 65.2% of the app’s time. This is the code that writes the JSON out to the SD card. Right away, we know that apparently the task of pulling the data out of the phone’s ContentProviders doesn’t seem to be very expensive; it’s the output that’s hurting.

Can we conclude that the app is limited by the sluggish write performance of the SD card? Let’s drill down, which is done in the most obvious point-and-click way imaginable.

Ooh, there’s a nasty surprise. Of course, println calls (in effect) toString() on all its arguments. It looks like turning the arguments to strings is taking over half the time, before it even dispatches from println(Object) to println(String).

I’ll skip the step of drilling down into println(String) but it does suggest that yes, there is some slow I/O happening there, to the SD card. But let’s look inside that String.valueOf() call.

There’s your smoking pistol. It turns out that org.json.JSONObject.toString() is what we professional programmers call a, well, this is a family-friendly operation so I won’t go there. You can poke around inside it, but it’s just depressing.

What you can do, however, is sort all the routines by their “Exclusive” times, as in the number of CPU circles burned right there in the routine. Here are all of them that use 1% or more of the total execution time.

There’s a little bit of GC and Android framework View-wrangling stuff in there, but the display is dominated by org.jason and java.lang.StringBuilder code.

The Conclusion

The real conclusion is that in the case of this app, I actually don’t care about the performance. A user runs it a grand total of two times, once on the old phone and once on the new phone, and it’s got lots of eye candy, so I just don’t think there’s a problem.

If I did want to speed this up, it’s obvious what to do. First, either stop using JSON, or find a cheaper way to serialize it. Second, do fewer println() calls; glom the data together in one big buffer and just blast it out with a single I/O call. But, and here’s the key point, if I’d guessed where the bottlenecks were, I’d have been wrong, mostly.

Traceview is a nice tool, and if you don’t already know it, you owe it to yourself to learn it.

Read More..

New Seller Countries in Google Play

Over the past year we’ve been working to expand the list of countries and currencies from which Android developers can sell their products. Starting today, developers in Czech Republic, Israel, Poland, and Mexico can sell priced applications and in-app products on Google Play, using their local bank accounts for payments. Welcome developers!



If you develop Android apps in one of the new countries and want to get started selling them, visit play.google.com/apps/publish and set up a new Google Play developer account. Once you’ve uploaded your apps, you can price them in any available buyer currencies, publish, and then receive payouts and financial data in your local currency.



If you are based in Israel or Mexico and are currently selling apps through an AdSense merchant account, you will need to migrate your apps to a new Google Play developer account in your local currency. Watch for an email that provides complete information on the migration process and timeline.



Additionally, we encourage developers everywhere to visit the Developer Console as soon as possible to set prices for their products in the currencies of these new countries. Stay tuned for more announcements soon as we continue to roll out our new billing infrastructure to buyers and sellers throughout the world.

Join the discussion on

+Android Developers

Read More..

Taking the Android Show on the Road

[This spring, the Android Developer Relations team (where I work, too) went on the road round the world with boxes of phones, their laptops bulging with slide-ware. Here we’ve combined write-ups from Billy Rutledge (who leads the Android evangelism team at Google HQ) and Reto Meier, who has a desk in London and wrote the book on Android. Featuring Europe is a little unfair, there are a ton of stories from Asia and North America too, but we wanted to keep this reasonably short. - Tim Bray]

Introduction

Billy: The Android Developer Lab (ADL) events are sponsored by Google to help drive developer interest in the Android platform and increase the quality, as well as quantity of creative, innovative applications in Android Market. This Android Developer Relations tour covered 18 locations around the world; we met with over five thousand enthusiastic Android developers and were thrilled to see the energy and creativity behind your applications.

Reto: The European leg of the Android Developer Lab World Tour consisted of me, Billy, and intrepid local volunteers covering eight labs in eleven days across six countries.

Some of the venues werent like some of the others.

The goal of the tour was to meet and support local Android communities around the world, get developers excited about Android, and inspire them to create the next generation of innovative mobile applications.

Billy: In these sessions, we tried to help new and experienced developers move forward with their application plans. The core topics included:

• Status of the Mobile Web

• Android Opportunity for Developers

• Android Market Overview

• Android SDK Key Features

• Code Labs ranging from HelloWorld to Threads to LiveWallpaper

Reto: The odyssey began in the London Google office, three labs over two days that played host to nearly 200 developers. Our surprise gifts arrived minutes after our first session started - a close enough call that our “there’s a package you need to sign for - any idea what it is?” charade was unscripted and only partially contrived. The heart palpitations were entirely real. London is home to some great Android developers including the teams behind ADC2 winners PlinkArt and BuzzDeck.

After London we battled ice and snow in Stockholm, where Anders Bond told us why Android is a good match for Spotify, and enjoyed the sound of 100 Swedes spontaneously erupting in applause.

In Paris 200 experienced community members joined us for two events at La Cantine. Speakers from FRAndroid, Sfeir, and Diotasoft covered everything from OpenGL development using the SDK to using AppEngine to create scalablends for your Android apps.

The Berlin event was huge, with over 150 developers travelling in from all across Germany. We saw demos including multi-touch pong, a Live Wallpaper of the changing Berlin skyline, and an app that showed us where to find (and rate!) the nearest public toilets. The night ended (in the small hours) with a private tour of c-base, an experience not to be missed.

Universidad Rey Juan Carlos made us feel very welcome in Madrid. Over 200 developers from across Spain (and Portugal) were in attendance including more winners of ADC1 (Biowallet) and ADC2 (SweetDreams).

Lessons Learned

Billy: Developers have matured to the point where they dont need to be convinced, they hunger for more technical details. While the intro level topics were well received, most developers have advanced beyond this point and seek guidance on more in-depth topics.

Reto:

• It’s possible for one person to carry up to four boxes each containing ten Nexus Ones at a time.

• You should not try to carry more than three boxes of Nexus Ones if the conditions are icy. Right Billy?

  Billy: Absolutely!!! :)

• Announcing free smartphones to a room of developers always results in a spontaneous round of applause.

• European mobile developers are smart, enthusiastic, and already building the next generation of epic apps for Android.

Billy: Post event series, we opened a volunteer survey to help us guide future efforts:

• 78% of developers rated the event 4+ stars (of 5 stars)

• 79% of developers say having Google engineers on hand is "extremely important"

• 69% of developers say it is "extremely important" to see more test devices at future events

Looking Forward

[These are still at the planning stage, nothing here is a promise. - Tim]

Billy: The Android Developer Relations team plans to lead future Android Developer Lab events in 2010, building on the feedback from the February events. These future events will focus on deeper technical subjects, expecting the attendees to have a basic understanding of the Android platform. We will post the beginner material on-line as a prerequisite.

While its impossible for us to reach all locations, well look to cover the key locations where Android devices are available.

Reto: I hadn’t even made it back to London when the requests started to roll in. Given the success of this tour I don’t imagine it will be too long.

It’s always a great experience meeting the Android developer community, we look forward to seeing you again soon!

Read More..