Gingerbread NDK Awesomeness

[This post is by Chris Pruett, an outward-facing Androider who focuses on the world of games. —Tim Bray]

We released the first version of the Native Development Kit, a development toolchain for building shared libraries in C or C++ that can be used in conjunction with Android applications written in the Java programming language, way back in July of 2009. Since that initial release we’ve steadily improved support for native code; key features such as OpenGL ES support, debugging capabilities, multiple ABI support, and access to bitmaps in native code have arrived with each NDK revision. The result has been pretty awesome: we’ve seen huge growth in certain categories of performance-critical applications, particularly 3D games.

These types of applications are often impractical via Dalvik due to execution speed requirements or, more commonly, because they are based on engines already developed in C or C++. Early on we noted a strong relationship between the awesomeness of the NDK and the awesomeness of the applications that it made possible; at the limit of this function is obviously infinite awesomeness (see graph, right).

With the latest version of the NDK we intend to further increase the awesomeness of your applications, this time by a pretty big margin. With NDK r5, we’re introducing new APIs that will allow you to do more from native code. In fact, with these new tools, applications targeted at Gingerbread or later can be implemented entirely in C++; you can now build an entire Android application without writing a single line of Java.

Of course, access to the regular Android API still requires Dalvik, and the VM is still present in native applications, operating behind the scenes. Should you need to do more than the NDK interfaces provide, you can always invoke Dalvik methods via JNI. But if you prefer to work exclusively in C++, the NDK r5 will let you build a main loop like this:

void android_main(struct android_app* state) {
    // Make sure glue isn't stripped.

    // loop waiting for stuff to do.
    while (1) {
        // Read all pending events.
        int ident;
        int events;
        struct android_poll_source* source;

        // Read events and draw a frame of animation.
        if ((ident = ALooper_pollAll(0, NULL, &events,
                (void**)&source)) >= 0) {
            // Process this event.
            if (source != NULL) {
                source->process(state, source);
        // draw a frame of animation

(For a fully working example, see the native-activity sample in NDK/samples/native-activity and the NativeActivity documentation.)

In addition to fully native applications, the latest NDK lets you play sound from native code (via the OpenSL ES API, an open standard managed by Khronos, which also oversees OpenGL ES), handle common application events (life cycle, touch and key events, as well as sensors), control windows directly (including direct access to the window’s pixel buffer), manage EGL contexts, and read assets directly out of APK files. The latest NDK also comes with a prebuilt version of STLport, making it easier to bring STL-reliant applications to Android. Finally, r5 adds backwards-compatible support for RTTI, C++ exceptions, wchar_t, and includes improved debugging tools. Clearly, this release represents a large positive ∆awesome.

We worked hard to increase the utility of the NDK for this release because you guys, the developers who are actually out there making the awesome applications, told us you needed it. This release is specifically designed to help game developers continue to rock; with Gingerbread and the NDK r5, it should now be very easy to bring games written entirely in C and C++ to Android with minimal modification. We expect the APIs exposed by r5 to also benefit a wide range of media applications; access to a native sound buffer and the ability to write directly to window surfaces makes it much easier for applications implementing their own audio and video codecs to achieve maximum performance. In short, this release addresses many of the requests we’ve received over the last year since the first version of the NDK was announced.

Integrating your Rails application with Google Apps and the Apps Marketplace

In this article you will find a step-by-step guide to integrating your Ruby on Rails application with Google Apps and launching it on the Google Apps Marketplace. The Google Apps Marketplace is a great platform to get new clients, show off our product and integrate Floorplanner with the services Google provides. At the beginning of the summer we tried to launch our application on the Marketplace. We found out that a lot of people were struggling with the existing Rails libraries and the OAuth authorization method, therefore we would like to provide this tutorial to help other developers. I would like to thank Dušan Maliarik for building this implementation with me and finding the solution for using the two-legged OAuth authorization.

1. The initial setup

Before you start programming there is some required setup. You first have to add a new application on the Google Apps Marketplace. You will need a Vendor Profile for this and a Google account. Sign In to the Marketplace with your Google account and go to your Vendor Profile using the link at the top-right of the Marketplace homepage.

After you enter some information about your company, there will be a list of your applications called “Listings.” You need to create a new listing to develop and test your application. When you create a new listing, check the box which says “My product may be directly installed into Google Apps domains.” This is necessary if you want the application to have an “Add it Now” button on the listing page, and allows you to add a Manifest to describe the application.

A Manifest describes all the settings of your application, like the name, URL’s and required permissions. Below you can find an example manifest. You will need to change all fields surrounded by brackets [ ].




You should decide whether you want to create a setup page. During the installation process of the application you will be redirected to the URL you specified in the manifest under “setup”. This is useful for collecting additional information necessary for configuring the app, or setting up a new umbrella account for the company. The umbrella account allows you to use other users of the domain as sub-users. You can also retrieve other information, like the administrators of the domain, the logo of the Google Apps account, or the domain name of the Google Apps account. If you don’t want to redirect customers to your site during the installation process, then just remove the line from your manifest.

2. Rails libraries and OpenID

The code you’re going to use relies on several Rails plugins and gems. The plugins/gems needed for this tutorial are listed below.

After installing these, you will be able to use OpenID, OAuth and the Google Data APIs in your Rails application. First you are going to authenticate the user with OpenID. This way you can retrieve the user’s email address and other information like First and Last name. The OpenID implementation is straight-forward. When using OpenID, a connection will be made to Google’s OpenID service and will check if the user granted access to your application. In typical OpenID, a ‘grant access’ page or login page is presented if the user hasn’t granted access to the app, though this won’t happen if you have a Google Apps Marketplace application installed with a properly configured realm as access is granted by the administrator for all of their users. This process can be found in the example code below.

def login

# The domain needs to be set. For example with params[:domain]
   { :required   => [""], :return_to  => '/login'}) do |result, identity_url, registration|

     if result.successful?
       # Succesfully logged in, retrieve email address
       email = get_email(registration)
        # Failed to login


def get_email(registration)

       ax_response = OpenID::AX::FetchResponse.from_success_response(


After reviewing this code sample you can alter it for using it with the setup page. Authenticate with OpenID when a user goes into the setup procedure and redirect them to the actual setup page after they are authenticated.

After your setup page is complete you can add your Google Apps Marketplace listing to your Google Apps account. Note that administrator privileges are necessary to add the application to your Google Apps account. You can add the application from the Vendor Profile when you click on your newly created application. A big blue button will appear on the right side of the listing’s information page. More information on this process can be found on the Creating a Listing page in the Marketplace developer documentation.

3. Using the Google Data APIs

When using the Google Data APIs outside of the Apps Marketplace you have to get access to a user’s data using three-legged OAuth, AuthSub or ClientLogin. These authorization methods require your application to redirect the user to Google’s site to request authorization. Because you’ve already authenticated the user by using OpenID and an administrator has granted authorization to the user’s data when they added your application to their Google Apps domain, you don’t want to use these methods.

For the Google Apps Marketplace there is another option– two-legged OAuth. Two-legged OAuth allows your application to use a single consumer key and secret (available from the Vendor Profile) to access the data for all your customers who have installed the Marketplace app and granted the appropriate permissions. Because the administrators have granted permission on behalf of their users, each user does not need to be prompted individually.

The first thing you should try is to retrieve a contact list of a user. You could use it for auto completion on forms, or you can let users quickly add friends to your application.

CONSUMER_KEY = "Your-consumer-key"
CONSUMER_SECRET = "Your-consumer-secret"

def get_contacts

   # Retrieve contacts 
   email = ""
   url = "{email}"
   contacts = gdata_request(url, :get)


def gdata_request(url, method, headers = {}, data = "")

    uri = URI.parse(url)

   # Setting up two-legged-oauth
   consumer =, CONSUMER_SECRET)
   oauth_params = {:consumer => consumer, :method => method, :request_uri => uri.to_s}

   # Set Net:HTTP connection
   http =, uri.port)
   http.use_ssl = (uri.port == 443)

   if method == :post
 req =
 req.body = data
 req =

   # Set authorization header
   oauth_helper =, oauth_params)
   req.initialize_http_header(headers.merge({'Authorization' => oauth_helper.header}))

   # Execute request
   response = http.request(req)


The feature we struggled with the most during the integration of Floorplanner was the two-legged OAuth authorization. There was no documentation available for the gems and it took some attempts to get it right. We turned to the OAuth Playground to find out the differences between our own request and the working request. After numerous tries we found out that we need to specify the HTTP method in order to get it working. It was important to use the Net::HTTP::Post request when sending information and Net::HTTP::Get request when retrieving information. This sounds logical, but it also needed to be done when retrieving the authorization header in the OAuth Client Helper, as well as in the Net HTTP request. Now we have this code, we can generate a request for almost every call in the Google Data API’s.

In the next example, you will use the Google Docs API to send a CSV file to a user’s Google Docs account. You need to do a POST request to the Google Docs feed. The request is almost the same as in the previous example, only you need to add two more headers. One is the Content-Type where you specify the MIME type you want to send. In this case, you’re uploading a CSV file so “text/csv” will do. Another header you need to send is the Slug. This value specifies the name you want for the document in Google Docs. Another way of doing this is adding meta-data to the body of the request. More information on this method can be found in the the Google Docs documentation.

def submit_csv_to_gdocs

  email = ''
  url = '{email}'

  # Create new CSV
  csv =

  CSV::Writer.generate(csv, ',') do |line|
  line << ["Example 1", "Example 2"]


  # Send request
   gdata_request(url, :post, 
      { 'Content-Type' => 'text/csv', 
         'Slug' => 'test.csv', 
         'GData-Version' => '3.0' },


Now, this is all you need to get started with the Google Data API’s. Be sure to check out the Google Apps Marketplace Developer overview for more information and to see which API’s you could use and how to use these. I would advise to check out the OAuth Playground if you have any problems with authorization. Using the playground with two-legged OAuth is very easy. Just follow these steps:

  1. Set the signature method to HMAC-SHA1
  2. Type in your consumer key and consumer secret (these can be found in your Vendor Profile)
  3. Set your Feed URL (step 6)
  4. Set GData-version to 3.0 unless the API only supports 2.0
  5. Click execute

Since the OAuth playground traffic isn’t over SSL, I’d only recommend using it with the consumer key and secret for a test application installed on test domains.

Thank you for reading this tutorial. I know this isn’t the best approach on using two-legged OAuth but it will give you some insight. The best way would be to build in two-legged OAuth support in the Google Data APIs Ruby Utility Library. I haven’t done that yet but am planning to look into that soon. If you have any questions or comments, I would love to hear from you. You can email me at

One last note: These code snippets are just examples of how to use the Google Apps Marketplace with Rails. I would advise you not to use these examples in a production environment.