Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Android Developers Blog
Syndicate content
An Open Handset Alliance Project.
Updated: 1 hour 6 min ago

What’s new in WebView security

Thu, 06/22/2017 - 22:29
Posted by Xiaowen Xin and Renu Chaudhary, Android Security Team

The processing of external and untrusted content is often one of the most important functions of an app. A newsreader shows the top news articles and a shopping app displays the catalog of items for sale. This comes with associated risks as the processing of untrusted content is also one of the main ways that an attacker can compromise your app, i.e. by passing you malformed content.

Many apps handle untrusted content using WebView, and we've made many improvements in Android over the years to protect it and your app against compromise. With Android Lollipop, we started delivering WebView as an independent APK, updated every six weeks from the Play store, so that we can get important fixes to users quickly. With the newest WebView, we've added a couple more important security enhancements.

Isolating the renderer process in Android O

Starting with Android O, WebView will have the renderer running in an isolated process separate from the host app, taking advantage of the isolation between processes provided by Android that has been available for other applications.

Similar to Chrome, WebView now provides two levels of isolation:

  1. The rendering engine has been split into a separate process. This insulates the host app from bugs or crashes in the renderer process and makes it harder for a malicious website that can exploit the renderer to then exploit the host app.
  2. To further contain it, the renderer process is run within an isolated process sandbox that restricts it to a limited set of resources. For example, the rendering engine cannot write to disk or talk to the network on its own. It is also bound to the same seccomp filter (blogpost on seccomp is coming soon) as used by Chrome on Android. The seccomp filter reduces the number of system calls the renderer process can access and also restricts the allowed arguments to the system calls.
Incorporating Safe Browsing

The newest version of WebView incorporates Google's Safe Browsing protections to detect and warn users about potentially dangerous sites.. When correctly configured, WebView checks URLs against Safe Browsing's malware and phishing database and displays a warning message before users visit a dangerous site. On Chrome, this helpful information is displayed more than 250 million times a month, and now it's available in WebView on Android.

Enabling Safe Browsing

To enable Safe Browsing for all WebViews in your app, add in a manifest tag:

<manifest>
     <meta-data android:name="android.webkit.WebView.EnableSafeBrowsing"
                android:value="true" />
      . . .
     <application> . . . </application>
</manifest>

Because WebView is distributed as a separate APK, Safe Browsing for WebView is available today for devices running Android 5.0 and above. With just one added line in your manifest, you can update your app and improve security for most of your users immediately.

.blogimage img { width: 100%; border: 0; margin: 0; padding: 0; } .floatimage img { float: right; width: 45%; }
Categories: Programming

Ending support for Android Market on Android 2.1 and lower

Tue, 06/20/2017 - 19:00
Posted by Maximilian Ruppaner, Software Engineer on Google Play

On June 30, 2017, Google will be ending support for the Android Market app on Android 2.1 Eclair and older devices. When this change happens, users on these devices will no longer be able to access, or install other apps from, the Android Market. The change will happen without a notification on the device, due to technical restrictions in the original Android Market app.

It has been 7 years since Android 2.1 Eclair launched. Most app developers are no longer supporting these Android versions in their apps given these devices now account for only a small number of installs.

We will still be supporting later versions of Android Market for as long as feasible. Google Play, the replacement for Android Market, is available on Android 2.2 and above.

Categories: Programming

Semantic Time support now available on the Awareness APIs

Fri, 06/16/2017 - 18:00
Posted by Ritesh Nayak M, Product Manager

Last year at I/O we launched the Awareness API, a simple yet powerful API that let developers use signals such as Location, Weather, Time and User Activity to build contextually relevant app experiences.

Available via Google Play services, the Awareness API offers two ways to take advantage of context signals within your app. The Snapshot API lets your app request information about the user's current context, while the Fence API lets your app react to changes in user's context, and when it matches a certain set of conditions. For example, "tell me whenever the user is walking and their headphone is plugged in".

Until now, you could specify a time fence on the Awareness APIs but were restricted to using absolute/canonical representation of time. Based on developer feedback, we realized that the flexibility of the API in regards to building time fences did not support higher level abstractions people use when they think and talk about time. "This weekend", "on the next holiday", "after sunset", are all very common and colloquial ways of expressing time. That's why we're adding Semantic time support to these APIs starting today

For e.g., if you were building a fitness app and wanted a way to prompt users everyday morning to start their routine, or if you're a reading app that wants to turn on night mode after dusk; you would have to query a 3p API for sunrise/sunset information at the user location and then write up an Awareness fence with those canonical time values. With our latest update, you can use our TIME_INSTANT_SUNRISE and TIME_INSTANT_SUNSET constants and let the platform manage all the complexity for you.

Let's look at an example. Suppose you're building a fitness app which prompts users on Tuesday, and Thursday around sunrise to begin their morning work out. You can set up this triggering using the following lines of code.

// A sun-state-based fence that is TRUE only on Tuesday and Thursday during Sunrise 
AwarenessFence.and(
    TimeFence.aroundTimeInstant(TimeFence.TIME_INSTANT_SUNRISE,
            -10 * ONE_MINUTE_MILLIS, 5 * ONE_MINUTE_MILLIS),
    AwarenessFence.or(
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_TUESDAY,
                0, ONE_DAY_MILLIS),
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_THURSDAY,
                0, ONE_DAY_MILLIS)));

One of our favorite semantic time features is public holidays. Every country and regions within it have different holidays. Assume you were a local hiking & adventure app that wants to show users activities they can indulge in on a holiday that falls on a Friday or a Monday. You can use a combination of Days and Holiday flags to identify this state for all your users around the world. You can do this with just 3 lines of code and have this work in any part of the world.

// A local-time fence that is TRUE only on public holidays in the
// device locale that fall on Fridays or Mondays.
AwarenessFence.and(
    TimeFence.inTimeInterval(TimeFence.TIME_INTERVAL_HOLIDAY),
    AwarenessFence.or(
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_FRIDAY,
                9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS),
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_MONDAY,
                9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS)));

In both example cases, Awareness does the heavy lifting of localizing time and holidays based on the device locale settings.

We're excited to see what problems you'll solve using this powerful API. Please join our mailing list to get updates about this and other Context APIs at Google.

.blogimage img { width: 100%; }
Categories: Programming

Android Things Developer Preview 4.1

Thu, 06/15/2017 - 22:41
Posted by Wayne Piekarski, Developer Advocate for IoT

Today, we're releasing a new Developer Preview 4.1 (DP4.1) of Android Things, with updates for new supported hardware and bug fixes to the platform. Android Things is Google's platform to enable Android Developers to create Internet of Things (IoT) devices, and seamlessly scale from prototype to production.

New hardware

A new Pico i.MX6UL revision B board has been released, which supports many common external peripherals from partners such as Adafruit and Pimoroni. There were some prototype Pico i.MX6UL boards made available to some early beta testers, and these are not compatible with DP4.1.

Improvements

DP4.1 also includes some performance improvements since DP4, such as boot time optimizations that improve the startup time of i.MX7D based hardware. This Developer Preview also includes a version of Google Play Services, specifically optimized for IoT devices. This new IoT variant is a lot smaller and optimized for use with Android Things, and requires the use of play-services 11.0.0 or later in your build.gradle. For more information about the supported features in the IoT variant of Google Play Services, see the information page.

Google I/O

Android Things had a large presence at Google I/O this year, with 7 talks covering different aspects of Android Things for developers, and these are available as videos in a playlist for those who could not attend:

What’s New In Google’s IoT Platform? Ubiquitous Computing at Google Bringing Device Production to Everyone With Android Things From Prototype to Production Devices with Android Things Developing for Android Things Using Android Studio Security for IoT on Android Things Using Google Cloud and TensorFlow on Android Things Building for Enterprise IoT Using Android Things and Google Cloud Platform

Google I/O also had a codelab area, where attendees could sit down and test out Android Things development with some simple guided training guides. These codelabs are available for anyone to try at https://codelabs.developers.google.com/?cat=IoT

Feedback

Thank you to all the developers who submitted feedback for the previous developer previews. Please continue sending us your feedback by filing bug reports and feature requests, and asking any questions on stackoverflow. To download images for DP4.1, visit the Android Things download page and find the changes in the release notes. You can also join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas, with over 5,600 members.

.parent { display: flex; justify-content: space-around; align-items: center; width: 100% flex-wrap: wrap; } .child1 { width: 30%; display: flex; justify-content: center; align-items: center; } .child1 img { object-fit: contain; width: 150px; margin: 0; border: 0; padding: 0; } .child2 { width: 70%; text-align: left; padding: 0 0 0 5px; }
Categories: Programming

Welcome to your New Home on Android TV

Thu, 06/15/2017 - 18:43
.image img { width: 100%; padding: 10px 0; margin: 0; border: 0; } Posted by Paul Saxman, Android Devices and Media Developer Relations Lead

Android TV brings rich app experiences and entertainment to the biggest screen in your house, and with Android O, we’re making it even easier for users to access content from their favorite apps. We’ve built a new, content-centric home screen experience for Android TV, and we're bringing the Google Assistant to the platform as well. These features put content that users want to access a few clicks, or spoken words, away.

The New Android TV Home Screen

The new Android TV home screen organizes video content into channels and programs in a way that’s familiar to TV viewers. Each Android TV app can publish multiple channels, which are represented as rows of programs on the home screen. Apps add relevant programs on each channel, and update these programs and channels as users access content or when new content is available. To help engage users, programs can include a video preview, which is automatically played when a user focuses on a program. Users can configure which channels they wish to see on the home screen, and the ordering of channels, so the themes and shows they’re interested in are quick and easy to access.

In addition to channels for you app, the top of the new Android TV home screen includes a quick launch bar for users' favorite apps, and a special Watch Next channel. This channel contains programs based on the viewing habits of the user.

The APIs for creating and maintaining channels and programs are part of the TvProvider APIs, which are distributed as an Android Support Library module with Android O. To get started using these APIs, visit the Android O Developer Preview site for an overview, and try out the Android TV Channels and Programs codelab for a first-hand experience building an Android TV app for Android O.

Later this year, Nexus Players will receive the new Android TV home experience as an OTA update. If you wish build and test apps for the new interface today, however, you can use the Android TV emulator or Nexus Player device images that are part of the latest Android O Developer Preview.

The Google Assistant on Android TV

The Google Assistant on Android TV, coming later this year, will allow users to quickly find and access content using their voice. Because the Assistant is context-aware, it can help users narrow down what content to play. Users will also be able access the Assistant to control playback, even while a video or music is playing. And since the Assistant can control compatible smart home devices, a simple voice request can dim the lights to create an ideal movie viewing environment. When the Google Assistant comes to Android TV, it will launch in the US on Android devices running M, N, and O.

We're looking forward to seeing how developers take advantage of the new Android TV home screen. We welcome feedback, so please visit the Android TV Developer Community on G+ to share you thoughts and ideas!

Categories: Programming

Reduce friction with the new Location APIs

Wed, 06/14/2017 - 19:16
Posted by Aaron Stacy, Software Engineer, Google Play services

The 11.0.0 release of the Google Play services SDK includes a new way to access LocationServices. The new APIs do not require your app to manually manage a connection to Google Play services through a GoogleApiClient. This reduces boilerplate and common pitfalls in your app.

Read more below, or head straight to the updated location samples on GitHub.

Why not use GoogleApiClient?

The LocationServices APIs allow you to access device location, set up geofences, prompt the user to enable location on the device and more. In order to access these services, the app must connect to Google Play services, which can involve error-prone connection logic. For example, can you spot the crash in the app below?

Note: we'll assume our app has the ACCESS_FINE_LOCATION permission, which is required to get the user's exact location using the LocationServices APIs.

public class MainActivity extends AppCompatActivity implements
        GoogleApiClient.OnConnectionFailedListener {

  @Override
  public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    GoogleApiClient client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .build();
    client.connect();

    PendingResult result = 
         LocationServices.FusedLocationApi.requestLocationUpdates(
                 client, LocationRequest.create(), pendingIntent);

    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

If you pointed to the requestLocationUpdates() call, you're right! That call throws an IllegalStateException, since the GoogleApiClient is has not yet connected. The call to connect() is asynchronous.

While the code above looks like it should work, it's missing a ConnectionCallbacks argument to the GoogleApiClient builder. The call to request location updates should only be made after the onConnected callback has fired:

public class MainActivity extends AppCompatActivity implements 
        GoogleApiClient.OnConnectionFailedListener,
        GoogleApiClient.ConnectionCallbacks {

  private GoogleApiClient client;

  @Override
  protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .addConnectionCallbacks(this)
        .build();

    client.connect();
  }

  @Override
  public void onConnected(@Nullable Bundle bundle) {
    PendingResult result = 
            LocationServices.FusedLocationApi.requestLocationUpdates(
                    client, LocationRequest.create(), pendingIntent);
    
    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

Now the code works, but it's not ideal for a few reasons:

  • It would be hard to refactor into shared classes if, for instance, you wanted to access Location Services in multiple activities.
  • The app connects optimistically in onCreate even if Location Services are not needed until later (for example, after user input).
  • It does not handle the case where the app fails to connect to Google Play services.
  • There is a lot of boilerplate connection logic before getting started with location updates.
A better developer experience

The new LocationServices APIs are much simpler and will make your code less error prone. The connection logic is handled automatically, and you only need to attach a single completion listener:

public class MainActivity extends AppCompatActivity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    FusedLocationProviderClient client =
            LocationServices.getFusedLocationProviderClient(this);

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnCompleteListener(new OnCompleteListener() {
          @Override
          public void onComplete(@NonNull Task task) {
            Log.d("MainActivity", "Result: " + task.getResult());
          }
        });
  }
}

The new API immediately improves the code in a few ways:

  • The API calls automatically wait for the service connection to be established, which removes the need to wait for onConnected before making requests.
  • It uses the Task API which makes it easier to compose asynchronous operations.
  • The code is self-contained and could easily be moved into a shared utility class or similar.
  • You don't need to understand the underlying connection process to start coding.
What happened to all of the callbacks?

The new API will automatically resolve certain connection failures for you, so you don't need to write code that for things like prompting the user to update Google Play services. Rather than exposing connection failures globally in the onConnectionFailed method, connection problems will fail the Task with an ApiException:

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnFailureListener(new OnFailureListener() {
          @Override
          public void onFailure(@NonNull Exception e) {
            if (e instanceof ApiException) {
              Log.w(TAG, ((ApiException) e).getStatusMessage());
            } else {
              Log.w(TAG, e.getMessage());
            }
          }
        });
Try it for yourself

Try the new LocationServices APIs out for yourself in your own app or head over to the android-play-location samples on GitHub and see more examples of how the new clients reduce boilerplate and simplify logic.

Categories: Programming

Reduce friction with the new Location APIs

Wed, 06/14/2017 - 19:16
Posted by Aaron Stacy, Software Engineer, Google Play services

The 11.0.0 release of the Google Play services SDK includes a new way to access LocationServices. The new APIs do not require your app to manually manage a connection to Google Play services through a GoogleApiClient. This reduces boilerplate and common pitfalls in your app.

Read more below, or head straight to the updated location samples on GitHub.

Why not use GoogleApiClient?

The LocationServices APIs allow you to access device location, set up geofences, prompt the user to enable location on the device and more. In order to access these services, the app must connect to Google Play services, which can involve error-prone connection logic. For example, can you spot the crash in the app below?

Note: we'll assume our app has the ACCESS_FINE_LOCATION permission, which is required to get the user's exact location using the LocationServices APIs.

public class MainActivity extends AppCompatActivity implements
        GoogleApiClient.OnConnectionFailedListener {

  @Override
  public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    GoogleApiClient client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .build();
    client.connect();

    PendingResult result = 
         LocationServices.FusedLocationApi.requestLocationUpdates(
                 client, LocationRequest.create(), pendingIntent);

    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

If you pointed to the requestLocationUpdates() call, you're right! That call throws an IllegalStateException, since the GoogleApiClient is has not yet connected. The call to connect() is asynchronous.

While the code above looks like it should work, it's missing a ConnectionCallbacks argument to the GoogleApiClient builder. The call to request location updates should only be made after the onConnected callback has fired:

public class MainActivity extends AppCompatActivity implements 
        GoogleApiClient.OnConnectionFailedListener,
        GoogleApiClient.ConnectionCallbacks {

  private GoogleApiClient client;

  @Override
  protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .addConnectionCallbacks(this)
        .build();

    client.connect();
  }

  @Override
  public void onConnected(@Nullable Bundle bundle) {
    PendingResult result = 
            LocationServices.FusedLocationApi.requestLocationUpdates(
                    client, LocationRequest.create(), pendingIntent);
    
    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

Now the code works, but it's not ideal for a few reasons:

  • It would be hard to refactor into shared classes if, for instance, you wanted to access Location Services in multiple activities.
  • The app connects optimistically in onCreate even if Location Services are not needed until later (for example, after user input).
  • It does not handle the case where the app fails to connect to Google Play services.
  • There is a lot of boilerplate connection logic before getting started with location updates.
A better developer experience

The new LocationServices APIs are much simpler and will make your code less error prone. The connection logic is handled automatically, and you only need to attach a single completion listener:

public class MainActivity extends AppCompatActivity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    FusedLocationProviderClient client =
            LocationServices.getFusedLocationProviderClient(this);

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnCompleteListener(new OnCompleteListener() {
          @Override
          public void onComplete(@NonNull Task task) {
            Log.d("MainActivity", "Result: " + task.getResult());
          }
        });
  }
}

The new API immediately improves the code in a few ways:

  • The API calls automatically wait for the service connection to be established, which removes the need to wait for onConnected before making requests.
  • It uses the Task API which makes it easier to compose asynchronous operations.
  • The code is self-contained and could easily be moved into a shared utility class or similar.
  • You don't need to understand the underlying connection process to start coding.
What happened to all of the callbacks?

The new API will automatically resolve certain connection failures for you, so you don't need to write code that for things like prompting the user to update Google Play services. Rather than exposing connection failures globally in the onConnectionFailed method, connection problems will fail the Task with an ApiException:

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnFailureListener(new OnFailureListener() {
          @Override
          public void onFailure(@NonNull Exception e) {
            if (e instanceof ApiException) {
              Log.w(TAG, ((ApiException) e).getStatusMessage());
            } else {
              Log.w(TAG, e.getMessage());
            }
          }
        });
Try it for yourself

Try the new LocationServices APIs out for yourself in your own app or head over to the android-play-location samples on GitHub and see more examples of how the new clients reduce boilerplate and simplify logic.

Categories: Programming

Recognizing Android Excellence on Google Play

Tue, 06/13/2017 - 17:00
Posted by Kacey Fahey, Developer Marketing, Google Play

Every day developers around the world are hard at work creating high quality apps and games on Android. Striving to deliver amazing experiences for an ever growing diverse user base, we've seen a significant increase in the level of polish and quality of apps and games on Google Play.

As part of our efforts to recognize this content on the Play Store, today we're launching Android Excellence. The new collections will showcase apps and games that deliver incredible user experiences on Android, use many of our best practices, and have great design, technical performance, localization, and device optimization.

Android Excellence collections will refresh quarterly and can be found within the revamped Editors' Choice section of the Play Store – which includes app and game reviews curated by our editorial team.

Congrats to our first group of Android Excellence apps and games!

Android Excellence Apps Android Excellence Games AliExpress by Alibaba Mobile

B&H Photo Video by B&H Photo Video

Citymapper by Citymapper Limited

Drivvo by Drivvo

drupe by drupe

Evernote by Evernote Corporation

HotelTonight by HotelTonight

Kitchen Stories by Kitchen Stories

Komoot by komoot GmbH

Lifesum by Lifesum

Memrise by Memrise

Pocket by Read It Later

Runtastic Running & Fitness by Runtastic

Skyscanner by Skyscanner Ltd

Sleep as Android by Urbandroid Team

Vivino by Vivino After the End Forsaken Destiny by NEXON M Inc.

CATS: Crash Arena Turbo Stars by ZeptoLab

Golf Clash by Playdemic

Hitman GO Square Enix Ltd

Horizon Chase by Aquiris Game Studio S.A

Kill Shot Bravo by Hothead Games

Lineage Red Knights by NCSOFT Corporation

Nonstop Knight by flaregames

PAC-MAN 256 - Endless Maze by Bandai Namco Entertainment Europe

Pictionary™ by Etermax

Reigns by DevolverDigital

Riptide GP: Renegade by Vector Unit

Star Wars™: Galaxy of Heroes by Electronic Arts

Titan Brawl by Omnidrone

Toca Blocks by Toca Boca

Transformers: Forged to Fight by Kabam

Stay up-to-date on best practices to succeed on Play and get the latest news and videos with the new beta version of our Playbook app for developers.

How useful did you find this blogpost? .blogimage img { float: right; margin: 0; padding: 0; border: 0; width: 40%; } table { border-collapse: collapse; border-spacing: 0; width: 100%; } th { text-align: left; padding: 8px; text-align: left; vertical-align: middle; width: 50%; font-size: 125%; } td { text-align: left; padding: 8px; vertical-align: top; width: 50%; } .note { text-align: center; margin: 0; padding: 0; font-size: 75%; } .playlogo img { display: block; margin: auto; width: 40%; }
Categories: Programming

Money made easily with the new Google Play Billing Library

Mon, 06/12/2017 - 17:00
Posted by Neto Marin, Developer Advocate

Many developers want to make money through their apps, but it's not always easy to deal with all the different types of payment methods. We launched the Google Play In-app Billing API v3 in 2013, helping developers offer in-app products and subscriptions within their apps. Year after year, we've added features to the API, like subscription renewal, upgrades and downgrades, free trials, introductory pricing, promotion codes, and more.

Based on your feedback, we’re pleased to announce the Play Billing Library - Developer Preview 1. This library aims to simplify the development process when it comes to billing, allowing you to focus your efforts on implementing logic specific to your app, such as application architecture and navigation structure. The library includes several convenient classes and features for you to use when integrating your Android apps with the In-app Billing API. The library also provides an abstraction layer on top of the Android Interface Definition Language (AIDL) service, making it easier for you to define the interface between your app and the In-app Billing API.

Easy to get started and easy to use

Starting with Play Billing Library Developer Preview release, the minimum supported API level is Android 2.2 (API level 8), and the minimum supported In-app Billing API is version 3.

In-app billing relies on the Google Play Store, which handles the communication between your app and Google's Play billing service. To use Google Play billing features, your app must request the com.android.vending.BILLING permission in your AndroidManifest.xml file.

To use the library, add the following dependency in your build.gradle file:

dependencies {
    ...
    compile 'com.android.billingclient:billing:dp-1'
}

After this quick setup process, you're ready to start using the Play Billing Library in your app and can connect to the In-app Billing API, query for available products, start the purchase flow, and more.

Sample updated: Trivial Drive V2

With a new library comes a refreshed sample! To help you to understand how to implement in-app billing in your app using the new Play Billing Library, we've rewritten the Trivial Drive sample from the ground up.

Since we released Trivial Drive back in 2013, many new features, devices, and platforms have been added to the Android ecosystem. To reflect this evolution, the Trivial Drive v2 sample now runs on Android TV and Android Wear.

Give it a try!

Before integrating within your app, you can try the Play Billing Library with the codelab published during Google I/O 2017: Buy and Subscribe: Monetize your app on Google Play.

In this codelab, you will start with a simplified version of Trivial Drive V2 that lets users to "drive" and then you will add in-app billing to it. You'll learn how to integrate purchases and subscriptions as well as the best practices for developing reliable apps that handle purchases.

If you are looking for a step-by-step guide about how to sell in-app products from your app using the Play Billing Library, check out our new training class, explaining how to prepare your application, add products for purchase, start purchase flow and much more.

We want your feedback

We look forward to hearing your feedback about this new library. Visit the Play Billing Library site, the library reference, and the new version of the Trivial Drive sample. If you have issues or questions, file a bug report on the Google Issue Tracker, and for issues and suggestions on the sample, contact us on the Trivial Drive issues page.

For technical questions on implementation, library usage, and best practices, you can use the tags google-play and play-billing-library on Stackoverflow or visit the community pages on our Google+ page.

Categories: Programming

Making the Internet safer and faster: Introducing reCAPTCHA Android API

Fri, 06/09/2017 - 17:15
Posted by Wei Liu, Product Manager

When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to street numbers and names, then No CAPTCHA reCAPTCHA in 2014 and Invisible reCAPTCHA in March this year.

By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.

reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it's important to keep the mobile applications and data safe. Today, on reCAPTCHA's tenth birthday, we're glad to announce the first reCAPTCHA Android API as part of Google Play Services.

With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.

reCAPTCHA Android API is included with Google SafetyNet, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the diversity of security protections on Android: Google Play Protect to monitor for potentially harmful applications, device encryption, and regular security updates. Please visit our site to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.

The journey of reCAPTCHA continues: we'll make the Internet safer and easier to use for everyone (except bots).

.gif img { display: block; margin: auto; max-width: 50%; } .gif2 img { display: block; margin: auto; max-width: 200px; }
Categories: Programming

Android O APIs are final, get your apps ready!

Thu, 06/08/2017 - 19:40
Posted by Dave Burke, VP of Engineering

Three weeks ago at Google I/O, we announced the second developer preview of Android O along with key themes, Fluid Experiences and Vitals, and highlighted our work towards a modular base with Project Treble. It was also an important milestone for us with the release of the first beta-quality candidate. We talked a lot about what's new in Android during the keynote and breakout sessions—if you missed the livestream, be sure to check out the full archive of talks here.

Today we're rolling out Developer Preview 3 with the final Android O APIs, the latest system images, and an update to Android Studio to help you get ready for the consumer release later in the summer. Watch for one more preview update coming in July that will bring you the near-final system images.

If you've already enrolled your device in the Android Beta Program, you'll receive an update to Developer Preview 3 shortly.

Make your app compatible with Android O

With the consumer launch approaching in the coming months, a critical first step is making your current app compatible with Android O. This will give your users a seamless transition to the new platform as it arrives on their devices.

If you haven't tested your app for compatibility yet, getting started is straightforward -- just enroll a supported device in Android Beta and get the latest update over-the-air, then install your current app from Google Play and test. The app should run and look great, and it should handle the Android O behavior changes properly -- in particular pay attention to background limits and changes in networking, security, and identifiers.

After you've made any necessary updates, we recommend publishing the compatible version of your app to Google Play right away -- without changing the app's platform targeting.

Enhance your app with Android O features and APIs

Extending your apps with Android O features can help you drive more engagement, offer new interactions, give users more control and security, and even improve your app's performance.

Notification channels and dots give you more ways to surface new content to users and bring them back into your app. Picture-in-picture keeps your app onscreen while users are multitasking, and autofill makes it simple for them to enter forms data and helps keep their data secure. Also check out adaptive icons, XML font resources, downloadable fonts and emoji, autosizing TextView, AAudio API, and many others. You'll also want plan your support for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Picture-in-Picture mode lets you keep users engaged while they are multitasking (left). Notification dots keep users active in your app and let them jump directly the app’s core functions (right). Get started with Developer Preview 3

Today's preview update includes the latest version of the Android O platform with the final API level 26 and hundreds of bugfixes and optimizations. You can download the final API 26 SDK from the SDK Manager in Android Studio, and Android Support Library 26.0.0 beta 2 from Google's Maven repository.

Together, these give you everything you need to develop and test your apps with the official Android O APIs. Once you've installed the final SDK, you can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to set up your environment to build with Android O.

APIs have changed since the second developer preview, so if you have existing code using Android O preview APIs, take a look at the diff report to see where your code might be affected.

If you're developing for Android O, we recommend updating to the latest version of Android Studio 3.0, now available in the canary channel. Aside from great new features like improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 includes build support for Instant Apps, an Adaptive Icon Wizard, and support for XML Fonts, and Downloadable Fonts.

Android Studio 3.0 includes tools for developing with Android O features lets you preview XML font resources in your app.

If you don't plan to use those features, you now have the option of developing for Android O using Android Studio 2.3.3 from the stable channel. Note that the tools for working with adaptive icons and downloadable fonts, and XML fonts are not available in Android Studio 2.3.3.

Publish your apps to alpha, beta or production channels in Google Play

Now that the APIs are final, you can publish APK updates compiling with, and optionally targeting, API 26 to your alpha, beta, or even production channels in Google Play. Publishing your O-targeted app during the preview lets you test compatibility on existing devices and push updates to devices running API 26 -- such as users who are enrolled in the Android Beta program.

To make sure that your updated app runs well on Android O as well as older versions, a common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to get the preview update

Through the Android Beta program, developers and early adopters worldwide will soon be getting Developer Preview 3 on their devices. If you aren't yet enrolled, just visit android.com/beta and opt-in your eligible Android phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and Nexus Player.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. We're looking forward to seeing your apps on Android O!

.logo img { float: right; margin: 0 0 10px 10px; width: 200px; } .parent { display: flex; justify-content: space-around; align-items: center; width: 100% } .child { width: 50%; } .child img { width: 100% } .captionx { font-size: 75%; margin: 5px 0 10px 0; } .assetx { width: 100% } .assetx img { width: 100%; padding: 0; margin: 10px 0 10px 0; }
Categories: Programming

Google Play’s policy on incentivized ratings, reviews, and installs

Mon, 06/05/2017 - 18:00

Posted by Kazushi Nagayama, Ninja Spamologist and Bryan Woodward, Policy Specialist

Ensuring Google Play remains trusted and secure is one of our top priorities. We've recently announced improvements in fighting spam installs as well as fake ratings & reviews. In order to underscore these announcements and provide more clarity, we have now updated our Developer Program Policies on incentivized ratings, reviews, and installs:


Developers must not attempt to manipulate the placement of any apps in the Store. This includes, but is not limited to, inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized installs, reviews and ratings.


Defining an incentivized action

We deem an action to be incentivized if a user is offered money, goods, or the equivalent in exchange for the action – be it a rating, review or install. Incentivized ratings and reviews have always been against our policies and we will continue to take action against them in order to protect the integrity of our store. Installs done with the intent to manipulate the placement of an app in Google Play will be detected and filtered.

Incentivized installs as user acquisition

We've observed instances where incentivized installs are utilized solely to manipulate the placement of apps in Google Play; these instances are a policy violation. However, we also recognize that incentivized installs can be a legitimate user acquisition channel for some developers. In order to recognize these two distinct use cases, we are taking the following approach:

  • Whilst we won't automatically remove apps from the store just because they utilize incentivized installs as one of their user acquisition channels, we will monitor for, and take action against behaviour that compromises the integrity of the store.
  • To address those whose intent we perceive is to manipulate the placements of their apps, we will monitor and filter incentivized installs in our systems, including removal from the top charts. If warranted, identified apps also may be removed from the Store.

Through this approach, we hope to further ensure that the top charts and other discovery mechanisms on Google Play reflect the reality of the popularity of an app.

As a general rule, we advise against utilizing incentivized actions. Incentivized users are a very different user base than users found through other acquisition channels. In an internal analysis, the Google Research team found that incentivized users generally have lower retention rates and make fewer in-app purchases than users found through paid or organic acquisition channels.

For more information on the Google Play policies, please visit the developer policy center. For tips and best practices to find success on Google Play, visit the Android Developers website.

How useful did you find this blogpost?

.post-content img { margin: 0; padding: 0; }
Categories: Programming

Google Play’s policy on incentivized ratings, reviews, and installs

Mon, 06/05/2017 - 18:00

Posted by Kazushi Nagayama, Ninja Spamologist and Bryan Woodward, Policy Specialist

Ensuring Google Play remains trusted and secure is one of our top priorities. We've recently announced improvements in fighting spam installs as well as fake ratings & reviews. In order to underscore these announcements and provide more clarity, we have now updated our Developer Program Policies on incentivized ratings, reviews, and installs:


Developers must not attempt to manipulate the placement of any apps in the Store. This includes, but is not limited to, inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized installs, reviews and ratings.


Defining an incentivized action

We deem an action to be incentivized if a user is offered money, goods, or the equivalent in exchange for the action – be it a rating, review or install. Incentivized ratings and reviews have always been against our policies and we will continue to take action against them in order to protect the integrity of our store. Installs done with the intent to manipulate the placement of an app in Google Play will be detected and filtered.

Incentivized installs as user acquisition

We've observed instances where incentivized installs are utilized solely to manipulate the placement of apps in Google Play; these instances are a policy violation. However, we also recognize that incentivized installs can be a legitimate user acquisition channel for some developers. In order to recognize these two distinct use cases, we are taking the following approach:

  • Whilst we won't automatically remove apps from the store just because they utilize incentivized installs as one of their user acquisition channels, we will monitor for, and take action against behaviour that compromises the integrity of the store.
  • To address those whose intent we perceive is to manipulate the placements of their apps, we will monitor and filter incentivized installs in our systems, including removal from the top charts. If warranted, identified apps also may be removed from the Store.

Through this approach, we hope to further ensure that the top charts and other discovery mechanisms on Google Play reflect the reality of the popularity of an app.

As a general rule, we advise against utilizing incentivized actions. Incentivized users are a very different user base than users found through other acquisition channels. In an internal analysis, the Google Research team found that incentivized users generally have lower retention rates and make fewer in-app purchases than users found through paid or organic acquisition channels.

For more information on the Google Play policies, please visit the developer policy center. For tips and best practices to find success on Google Play, visit the Android Developers website.

How useful did you find this blogpost?

.post-content img { margin: 0; padding: 0; }
Categories: Programming

2017 Android Security Rewards

Fri, 06/02/2017 - 18:50
Posted by Mayank Jain and Scott Roberts of the Android Security team

Two years ago, we launched the Android Security Rewards program. In its second year, we've seen great progress. We received over 450 qualifying vulnerability reports from researchers and the average pay per researcher jumped by 52.3%. On top of that, the total Android Security Rewards payout doubled to $1.1 million dollars. Since it launched, we've rewarded researchers over $1.5 million dollars.

Here are some of the highlights from the Android Security Rewards program's second year:

  • There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise, our highest award amount possible.
  • We paid 115 individuals with an average of $2,150 per reward and $10,209 per researcher.
  • We paid our top research team, C0RE Team, over $300,000 for 118 vulnerability reports.
  • We paid 31 researchers $10,000 or more.

Thank you to all the amazing researchers who submitted complete vulnerability reports to us last year.

Improvements to Android Security Rewards program

We're constantly working to improve the Android Security Rewards program and today we're making a few changes to all vulnerability reports filed after June 1, 2017.

Because every Android release includes more security protections and no researcher has claimed the top reward for an exploit chains in 2 years, we're excited to increase our top-line payouts for these exploits.

  • Rewards for a remote exploit chain or exploit leading to TrustZone or Verified Boot compromise increase from $50,000 to $200,000.
  • Rewards for a remote kernel exploit increase from $30,000 to $150,000.

In addition to rewarding for vulnerabilities, we continue to work with the broad and diverse Android ecosystem to protect users from issues reported through our program. We collaborate with manufacturers to ensure that these issues are fixed on their devices through monthly security updates. Over 100 device models have a majority of their deployed devices running a security update from the last 90 days. This table shows the models with a majority of deployed devices running a security update from the last two months:

Manufacturer Device BlackBerry PRIV Fujitsu F-01J General Mobile GM5 Plus d, GM5 Plus, General Mobile 4G Dual, General Mobile 4G Gionee A1 Google Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9 LGE LG G6, V20, Stylo 2 V, GPAD 7.0 LTE Motorola Moto Z, Moto Z Droid Oppo CPH1613, CPH1605 Samsung Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Galaxy C9 Pro, Galaxy C7, Galaxy J7, Galaxy On7 Pro, Galaxy J2, Galaxy A8, Galaxy Tab S2 9.7 Sharp Android One S1, 507SH Sony Xperia XA1, Xperia X Vivo Vivo 1609, Vivo 1601, Vivo Y55 Source: Google May 29th, 2017.

Thank you to everyone who helped make Android safer and stronger in the past year. Together, we made a huge investment in security research that helps Android users everywhere. If you want to get involved to make next year even better, check out our detailed Program Rules. For tips on how to submit complete reports, see Bug Hunter University.

table { border-collapse: collapse; border-spacing: 0; width: 100%; border: 1px solid #ddd; } th { border: 1px solid #ddd; text-align: left; padding: 8px; background-color: #d3d3d3; text-align: center; vertical-align: middle; } td { border: 1px solid #ddd; text-align: left; padding: 8px; vertical-align: middle; min-width: 100px; } .note { font-size: 10px; padding-top: 0; margin; 0; text-align: center; }
Categories: Programming

Request a professional app translation from the Google Play Console and reach new users

Tue, 05/30/2017 - 16:12
.post-content img { padding: 20px 0 10px 0; } b { color: gold; } .stars { color: gold; text-align: center; } .use { font-style: italic; font-size: 8pt; text-align: center; } Posted by Rahim Nathwani, Product Manager, Google Play
Localizing your app or game is an important step in allowing you to reach the widest possible audience. It helps you increase downloads and provide better experiences for your audience.
To help do this, Google Play offers an app translation service. The service, by professional linguists, can translate app user interface strings, Play Store text, in-app products and universal app campaign ads. We've made the app translation service available directly from inside the Google Play Console, making it easy and quick to get started.
  • Choose from a selection of professional translation vendors.
  • Order, receive and apply translations, without leaving the Play Console.
  • Pay online with Google Wallet.
  • Translations from your previous orders (if any) are reused, so you never pay for the same translation twice. Great if you release new versions frequently.
Using the app translation service to translate a typical app and store description into one language may cost around US$50. (cost depends on the amount of text and languages).
Find out more and get started with the app translation service.

How useful did you find this blogpost?
Categories: Programming

Meet 5 Android developers working to improve lives around the world

Fri, 05/26/2017 - 17:00
.asset img { width: 200px; text-align: center; padding: 0; border: 0; margin: auto; display: block; } .caption { text-align: center; font-size: 6pts; font-style: italic; padding: 10px 0 0 0; margin: 0; border: 0; } .use { text-align: center; font-size: 6pts; padding:10px 0 0 0; margin: 0; border: 0; .stars { text-align: center; } Posted by Maxim Mai, Apps Partnerships, Google Play

Last Thursday at Google I/O 2017, we announced the winners of this year's Google Play Awards. Grab some popcorn and watch the award ceremony, we think it's just as fun as The Oscars. This year, we included a category to celebrate the achievements of developers who publish outstanding apps that have positive social impact.

In introducing this awards category, we were inspired by the UN's 17 Sustainable Development Goals. With the ability to reach over 1 billion active Android devices around the world, we think that app developers have a tremendous opportunity to impact Zero Hunger (SDG #2), Good Health and Wellbeing (SDG #3) and Quality Education (SDG #4), and many others. Read on to find out more about how this year's winner and finalists and impacting these goals.

Get in touch about your social impact app or game

Our work in supporting developer success in this area on Android and Google Play is just beginning. We would like to encourage Android developers with a focus on social impact to get in touch with us here at Google Play and to tell us about their app or game. It doesn't matter where you are based, what problems you are solving, or which countries you are targeting, we would like to hear your story and maybe we can help you grow faster and improve your app's quality.

Social impact winner & finalists in the 2017 Google Play Awards
Categories: Programming

Meet 5 Android developers working to improve lives around the world

Fri, 05/26/2017 - 17:00
.asset img { width: 200px; text-align: center; padding: 0; border: 0; margin: auto; display: block; } .caption { text-align: center; font-size: 6pts; font-style: italic; padding: 10px 0 0 0; margin: 0; border: 0; } .use { text-align: center; font-size: 6pts; padding:10px 0 0 0; margin: 0; border: 0; .stars { text-align: center; } Posted by Maxim Mai, Apps Partnerships, Google Play

Last Thursday at Google I/O 2017, we announced the winners of this year's Google Play Awards. Grab some popcorn and watch the award ceremony, we think it's just as fun as The Oscars. This year, we included a category to celebrate the achievements of developers who publish outstanding apps that have positive social impact.

In introducing this awards category, we were inspired by the UN's 17 Sustainable Development Goals. With the ability to reach over 1 billion active Android devices around the world, we think that app developers have a tremendous opportunity to impact Zero Hunger (SDG #2), Good Health and Wellbeing (SDG #3) and Quality Education (SDG #4), and many others. Read on to find out more about how this year's winner and finalists and impacting these goals.

Get in touch about your social impact app or game

Our work in supporting developer success in this area on Android and Google Play is just beginning. We would like to encourage Android developers with a focus on social impact to get in touch with us here at Google Play and to tell us about their app or game. It doesn't matter where you are based, what problems you are solving, or which countries you are targeting, we would like to hear your story and maybe we can help you grow faster and improve your app's quality.

Social impact winner & finalists in the 2017 Google Play Awards
Categories: Programming

Android Studio 3.0 Canary 1

Thu, 05/25/2017 - 21:58
.prettyprintcustom { font-size: 12pt; background-color: black; color: white; text-align: left; } .code { font-size: 12pt; } .dl { text-align: left; }

By Jamal Eason, Product Manager, Android

Just in time for Google I/O 2017, we're providing a sneak peak of Android Studio 3.0 - available to download today on our canary release channel. Android Studio's our official IDE, purpose-built for Android, and we keep increasing our investment. The feature set in Android Studio is focused on accelerating your app development flow and providing the latest tools built for the Android platform.

To accelerate your development flow, Android Studio 3.0 includes three major features: a new suite of app performance profiling tools to quickly diagnose performance issues, support for the Kotlin programming language, and increased Gradle build speeds for large sized app projects. Android Studio 3.0 also tightly integrates with Android platform development with these additional key features: support for Instant App development, inclusion of the Google Play Store in the Android O emulator system images, and new wizards for Android O development. Overall, this first canary release of Android Studio 3.0 has 20+ new features.

We have been quietly iterating on many of these features as part of the Android Studio 2.4 Canaries. Today we are renumbering the release to Android Studio 3.0 after recognizing that we added many significant features, and that we had to introduce a rare breaking change in the Android Gradle Plugin to improve scalability and build times. If you want to target Android O, create an Instant App, start developing with the Kotlin language or use the latest in Android app performance tools to improve your app quality then you should download Android Studio 3.0 Canary 1 today.
What's New in Android Development Tools - Google I/O '17


Check out the the list below organized into key developer flow for the details of the new features in this first canary release of Android Studio 3.0.

Develop
  • Kotlin Programming Language - By popular request, Android Studio 3.0 now includes support for Kotlin. With this new language support, you can seamlessly add Kotlin code next to your existing Android app code and have access to all the great development tools found in Android Studio. You can choose to add Kotlin to your project using the built-in conversion tool found under CodeConvert Java File to Kotlin File, or you choose to create a Kotlin enabled project with the New Project Wizard. Lean more about Kotlin language support in Android and Android Studio.

Kotlin Language Conversion in Android Studio

  • Java 8 Language features - We are continuing to evolve the support for Java 8 language features and APIs. With the recent deprecation of the Jack toolchain and migration to the javac based toolchain, you have access to features such as Instant Run for projects using the Java 8 language features in Android Studio. To update your project to support the new Java 8 Language toolchain, simply update your Source and Target compatibility levels to 1.8 in the Project Structure dialog. Learn more.
Update Project Structure Dialogue for Java 8 Language



  • Layout Editor - With this Android Studio release, you will find additional enhancements to the Layout Editor. We have updated the component tree with better drag-and-drop view insertions, and a new error panel. In coordination with an update to ConstraintLayout, the Layout Editor also supports creating view Barriers, creating Groups, and enhances Chain Creation. Learn more.
Layout Editor Component Tree & Warning Panel


  • Adaptive Icon Wizard - Android O introduces adaptive launcher icons, which can display in different shapes across different Android devices. The new Adaptive Launcher Icon wizard creates the new and legacy launcher icon assets and provides previews of how your adaptive icon will look on different launcher screen icon masks. Create a new asset by right-clicking on the /res folder in your project then navigate to → NewImage AssetLauncher Icons (Adaptive and Legacy) Learn more.
Adaptive Icon Wizard


  • XML Fonts & Downloadable Fonts - Adding custom fonts to your app (available when targeting Android O) is now even easier with the XML fonts preview and font selection tools in Android Studio. You can can also create a downloadable font resource for your app. Using downloadable fonts allows you to use a custom font in your app while avoiding the need to bundle in a font resource into your APK. To use downloadable fonts, ensure that you device or emulator is running Google Play Services v11.2.63 or higher. Learn more.
Downloadable Fonts Resource Picker
XML Fonts Preview



  • Android Things Support - With Android Studio 3.0, you can start developing on Android Things with a new set of templates in the New Project wizard and the New Module wizard. Android Things allows you to extend your Android development knowledge into the Internet of Things (IoT) device category. Learn more.

Android Things New Module Wizard 



  • IntelliJ Platform Update: Android Studio 3.0 Canary 1 includes the IntelliJ 2017.1 release, which has features such as Java 8 language refactoring, parameter hints, semantic highlighting, draggable breakpoints, enhanced version control search, and more. Learn more.

Build
  • Instant App Support - With Android Studio 3.0, you can create Instant Apps in your project. Instant Apps are lightweight Android apps that your users can immediately run without installation. To support this, Android Studio introduces two new module types: instant app and feature. Combined with a new "Modularize" refactoring action and the App Links Assistant, Android Studio can help you extend your app into an Instant App. To use you can use the New Module Wizard or right-click on a class and navigate to: RefactorModularize Learn more.

Instant App Module Wizard


  • Build Speed Improvements - We are continuing to invest in making build speeds faster. For this release, we focused on improving speed for projects that have many modules. To achieve these speed improvements and to support future enhancements, we have made breaking API changes to the Android Gradle plugin used by Android Studio. If you depended on APIs provided by the previous plugin you should validate compatibility with the new plugin and migrate applicable APIs. To test, update the plugin version in your build.gradle file. Learn more.



build.gradle
dependencies {
   classpath 'com.android.tools.build:gradle:3.0.0-alpha1'
}
  • Google's Maven Repository - Also, by popular request, we are now distributing the Android Support Library maven dependencies outside of the Android SDK Manager in a brand new Maven repository. For those developing with a Continuous Integration (CI) system, this should make Maven dependency management easier. Used in combination with the latest command line SDK Manager tool and Gradle, CI builds should be easier to manage with Google's Maven Repository. To use the the new Maven location, add the following url to your app module's build.gradle file. Learn more.
build.gradle
repositories {
   maven {
       url "https://maven.google.com"
   }
}



    Test & Debug
    • Google Play System Images - Along with the update to the Android O Beta release, we updated the Android Emulator O system images to include the Google Play Store. Bundling in the Google Play store allows you to do end-to-end testing of apps with Google Play, and provides a convenient way to keep Google Play services up-to-date in your Android Virtual Device (AVD). Just as Google Play services updates on physical devices, you can trigger the same updates on your AVDs.
    Google Play Store in Android Emulator


    Update Google Play Services in Android Emulator



    To ensure app security and a consistent experience with physical devices, the emulator system images with the Google Play store included are signed with a release key. This means you will not be able to get elevated privileges. If you require elevated privileges (root) to aid with your app troubleshooting, you can use the Android Open Source Project (AOSP) emulator system images that do not include Google apps or services. To get started, make sure you are using Android Emulator v26.1+, the latest system images API 24+ and then create a new AVD with a Google Play icon next to the device definition. Learn more.

    Android Virtual Device Manager with Google Play Store Support 




    • OpenGL ES 3.0 Support in Android Emulator - As a part of our ongoing investment in making your development experience fast, the latest version of the Android Emulator has OpenGL ES 3.0 support for Android O system images along with significant improvements in OpenGL ES 2.0 graphics performance for older emulator system images. Most modern graphics cards on all operating systems support OpenGL ES 2.0 acceleration. To use OpenGL ES 3.0 with the Android Emulator, your development machine needs a host GPU graphics card that supports OpenGL 3.2 or higher on Microsoft® Windows® or Linux (with Apple MacOS® support coming in the future). Learn more.


    OpenGL ES 3.0 in Android Emulator



    • App Bug Reporter in Android Emulator - To help in documenting bugs in your app, we have added an easier way to generate a bug report with all the necessary configuration settings and space to capture your repro steps. Additionally, if you want to share a specific emulator bug with the Android team, we have also added a link to quickly generate a bug on the Android Issue Tracker. To use this feature, navigate to the Emulator Tool BarExtended ControlsHelpEmulator HelpFile a Bug. Learn more.

    App Bug Reporting in Android Emulator

    • Proxy Support in Android - For those who need to use a HTTP proxy to access the Internet, we have added a user interface to manage the proxy settings used by the emulator. By default, the Android Emulator will now use the settings from Android Studio, but you can override these settings for your network setup. To configure navigation to the Extended ControlsSettingsProxy.
    Android Emulator Proxy Settings

    • Android Wear Rotary Controls in Android Emulator - The Android Emulator now supports rotary controls for the Android Wear 2.0 emulator system image. It is now easier to test your apps that target Android Wear devices that include rotary input scrolling. To enable, create an Emulator AVD that targets Android Wear, and the Rotary Input panel should appear under Extended controls. Learn more.

    Rotary input in Android Emulator


    • APK Debugging - For those of you who just want to debug an APK without building your project in Android Studio, the Android Studio 3.0 release now has the ability to debug an arbitrary APK. This functionally is especially helpful for those who develop your Android C++ code in another development environment, but want to debug and analyze the APK in the context of Android Studio. As long as you have a debuggable version of your APK, you can use the new APK Debugging features to analyze, profile & debug the APK. Moreover, if you have access to the sources of your APK, you can link the source to the APK debugging flow for a higher fidelity debugging process. Get started by simply selecting Profile or debug APK from the Android Studio Welcome Screen or File → Profile or debug APKLearn More.

    Profile or Debug an APK

    APK Debugging

    • Layout Inspector - You will find that the Layout Inspector has a few additional enhancements in Android Studio 3.0 that make it easier to debug issues in your app layouts. A couple of the enhancements include better grouping of properties into common categories, as well as search functionality in both the View Tree and Properties Panels. While an application is running, access the Layout Inspector via ToolsAndroidLayout Inspector. Learn more.
    Layout Inspector

    • Device File Explorer - Ported from DDMS into Android Studio by popular demand, the new Device File Explorer allows you to view the file and directory structure of your Android device or emulator. As you are testing your app, you can now quickly preview and modify app data files directly in Android Studio. Learn more.

    Device File Explorer


    Optimize
    • Android Profiler - Android Studio 3.0 includes a brand new suite of tools to help debug performance problems in your app. We completely rewrote the previous set of Android Monitor tools, and replaced them with the Android Profiler. Once you deploy your app to a running device or emulator, click on the Android Profiler tab and you will now have access to a real-time & unified view of the CPU, Memory, & Network activity for your app. Each of the performance events are mapped to the UI event timeline which highlights touch events, key presses, and activity changes so that you have more context on when and why a certain event happened.  Click on each timeline to dig into each performance aspect of your app. Learn more

    Android Profiler - Combined timeline view.
    • CPU Profiler - Unnecessary CPU processing and load spikes are symptoms of poor app performance. With the CPU Profiler, you can analyze the CPU thread usage of your app by triggering a sample or instrumented CPU trace. At this point, you can troubleshoot CPU performance issues using a variety of data views and filters built into the CPU Profiler. Learn more.

    CPU Profiler


    • Memory Profiler - Using memory inefficiently can lead to many device problems ranging from a janky UI to low memory events. The Memory Profiler combines the functionality of the previous Heap Viewer and Allocation Tracker in one rich interface to help debug memory usage problems in your app. You can diagnose a range of memory issues by analyzing memory allocations, heap dumps and more. Learn more.

    Memory Profiler


    • Network Profiler - Optimizing foreground and background network usage in your app can lead to a more performant app and lower app data usage. The network profiler allows you to monitor the network activity of your app, inspect the payload of each of your network requests, and link back to the line of source code that generated the network request. Currently, the network profiler works with HttpURLConnection, OkHttp, and Volley network libraries. The network profiler is an advanced analysis feature that can be enabled on Pre-Android O devices & emulators by selecting Enable Advanced Profiling in the Profiling Tab in the Run Configuration box. In addition to enabling network request and payload analysis, this checkbox enables event collection at the top level, memory object count, and memory garbage collection. For Android O-based devices and emulator, just deploy your app. Learn more.
    Network Profiler



    Network Profiler Setup for Pre- Android O Devices

    • APK Analyzer Improvements - In Android Studio 3.0, we have added some additional enhancements to the APK Analyzer to help you further optimize the size of your APK. With this feature update, you can now analyze Instant App zip files & AARs, and view dex bytecode of classes & methods. You can also generate Proguard configuration rules and load Proguard mapping files in the dex viewer. Learn more.

    APK Analyzer





    To recap, Android Studio 3.0 Canary 1 includes these new major features: 

    Develop


    Build


    Test & Debug

    Optimize
    Check out the release notes for more details.
    Android DevByte - What’s New in Android Studio 3.0 Canary 1
    Getting Started Download

    If you are using a previous version of Android Studio, you can install Android Studio 3.0 Canary 1 alongside your stable version. You can download this update from the official Android Studio Preview download page. As mention in this blog, there are some breaking Gradle Plugin API changes to support new features in the IDE. Therefore, you should also update your Android Gradle plugin version to 3.0.0-alpha1 in your current project to test and validate your app project setup.

    We appreciate any feedback on things you like, issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Connect with us -- the Android Studio development team ‐ on our Google+ page or on Twitter.

    Categories: Programming

    Request a professional app translation from the Google Play Console and reach new users

    Wed, 05/24/2017 - 18:45
    .post-content img { border: 0 0 0 0; margin: 0 0 0 0; padding: 20px 0 10px 0; max-width: 100%; } .stars { color: gold; text-align: center; } .use { font-style: italic; font-size: 8pt; text-align: center; } Posted by Rahim Nathwani, Product Manager, Google Play
    Localizing your app or game is an important step in allowing you to reach the widest possible audience. It helps you increase downloads and provide better experiences for your audience.
    To help do this, Google Play offers an app translation service. The service, by professional linguists, can translate app user interface strings, Play Store text, in-app products and universal app campaign ads. We've made the app translation service available directly from inside the Google Play Console, making it easy and quick to get started.
    • Choose from a selection of professional translation vendors.
    • Order, receive and apply translations, without leaving the Play Console.
    • Pay online with Google Wallet.
    • Translations from your previous orders (if any) are reused, so you never pay for the same translation twice. Great if you release new versions frequently.
    Using the app translation service to translate a typical app and store description into one language may cost around US$50. (cost depends on the amount of text and languages).
    Find out more and get started with the app translation service.

    How useful did you find this blogpost? ★ ★ ★ ★ ★
    Categories: Programming

    FORTIFY in Android

    Tue, 05/23/2017 - 22:26
    Posted by George Burgess, Software Engineer

    FORTIFY is an important security feature that's been available in Android since mid-2012. After migrating from GCC to clang as the default C/C++ compiler early last year, we invested a lot of time and effort to ensure that FORTIFY on clang is of comparable quality. To accomplish this, we redesigned how some key FORTIFY features work, which we'll discuss below.

    Before we get into some of the details of our new FORTIFY, let's go through a brief overview of what FORTIFY does, and how it's used.

    What is FORTIFY?
    FORTIFY is a set of extensions to the C standard library that tries to catch the incorrect use of standard functions, such as memset, sprintf, open, and others. It has three primary features:

    • If FORTIFY detects a bad call to a standard library function at compile-time, it won't allow your code to compile until the bug is fixed.
    • If FORTIFY doesn't have enough information, or if the code is definitely safe, FORTIFY compiles away into nothing. This means that FORTIFY has 0 runtime overhead when used in a context where it can't find a bug.
    • Otherwise, FORTIFY adds checks to dynamically determine if the questionable code is buggy. If it detects bugs, FORTIFY will print out some debugging information and abort the program.

    Consider the following example, which is a bug that FORTIFY caught in real-world code:

    struct Foo {
        int val;
        struct Foo *next;
    };
    void initFoo(struct Foo *f) {
        memset(&f, 0, sizeof(struct Foo));
    }
    
    FORTIFY caught that we erroneously passed &f as the first argument to memset, instead of f. Ordinarily, this kind of bug can be difficult to track down: it manifests as potentially writing 8 bytes extra of 0s into a random part of your stack, and not actually doing anything to *f. So, depending on your compiler optimization settings, how initFoo is used, and your project's testing standards, this could slip by unnoticed for quite a while. With FORTIFY, you get a compile-time error that looks like:

    /path/to/file.c: call to unavailable function 'memset': memset called with size bigger than buffer
        memset(&f, 0, sizeof(struct Foo));
        ^~~~~~
    
    For an example of how run-time checks work, consider the following function:

    // 2147483648 == pow(2, 31). Use sizeof so we get the nul terminator,
    // as well.
    #define MAX_INT_STR_SIZE sizeof("2147483648")
    struct IntAsStr {
        char asStr[MAX_INT_STR_SIZE];
        int num;
    };
    void initAsStr(struct IntAsStr *ias) {
        sprintf(ias->asStr, "%d", ias->num);
    }
    
    This code works fine for all positive numbers. However, when you pass in an IntAsStr with num <= -1000000, the sprintf will write MAX_INT_STR_SIZE+1 bytes to ias->asStr. Without FORTIFY, this off-by-one error (that ends up clearing one of the bytes in num) may go silently unnoticed. With it, the program prints out a stack trace, a memory map, and will abort with a core dump.

    FORTIFY also performs a handful of other checks, such as ensuring calls to open have the proper arguments, but it's primarily used for catching memory-related errors like the ones mentioned above.
    However, FORTIFY can't catch every memory-related bug that exists. For example, consider the following code:

    __attribute__((noinline)) // Tell the compiler to never inline this function.
    inline void intToStr(int i, char *asStr) { sprintf(asStr, “%d”, num); }
    
    
    char *intToDupedStr(int i) {
        const int MAX_INT_STR_SIZE = sizeof(“2147483648”);
        char buf[MAX_INT_STR_SIZE];
        intToStr(i, buf);
        return strdup(buf);
    }
    
    Because FORTIFY determines the size of a buffer based on the buffer's type and—if visible—its allocation site, it can't catch this bug. In this case, FORTIFY gives up because:

    • the pointer is not a type with a pointee size we can determine with confidence because char * can point to a variable amount of bytes
    • FORTIFY can't see where the pointer was allocated, because asStr could point to anything.

    If you're wondering why we have a noinline attribute there, it's because FORTIFY may be able to catch this bug if intToStr gets inlined into intToDupedStr. This is because it would let the compiler see that asStr points to the same memory as buf, which is a region of sizeof(buf) bytes of memory.

    How FORTIFY works
    FORTIFY works by intercepting all direct calls to standard library functions at compile-time, and redirecting those calls to special FORTIFY'ed versions of said library functions. Each library function is composed of parts that emit run-time diagnostics, and—if applicable—parts that emit compile-time diagnostics. Here is a simplified example of the run-time parts of a FORTIFY'ed memset (taken from string.h). An actual FORTIFY implementation may include a few extra optimizations or checks.

    _FORTIFY_FUNCTION
    inline void *memset(void *dest, int ch, size_t count) {
        size_t dest_size = __builtin_object_size(dest);
        if (dest_size == (size_t)-1)
            return __memset_real(dest, ch, count);
        return __memset_chk(dest, ch, count, dest_size);
    }
    
    In this example:

    • _FORTIFY_FUNCTION expands to a handful of compiler-specific attributes to make all direct calls to memset call this special wrapper.
    • __memset_real is used to bypass FORTIFY to call the "regular" memset function.
    • __memset_chk is the special FORTIFY'ed memset. If count > dest_size, __memset_chk aborts the program. Otherwise, it simply calls through to __memset_real.
    • __builtin_object_size is where the magic happens: it's a lot like size sizeof, but instead of telling you the size of a type, it tries to figure out how many bytes exist at the given pointer during compilation. If it fails, it hands back (size_t)-1.

    The __builtin_object_size might seem sketchy. After all, how can the compiler figure out how many bytes exist at an unknown pointer? Well... It can't. :) This is why _FORTIFY_FUNCTION requires inlining for all of these functions: inlining the memset call might make an allocation that the pointer points to (e.g. a local variable, result of calling malloc, …) visible. If it does, we can often determine an accurate result for __builtin_object_size.

    The compile-time diagnostic bits are heavily centered around __builtin_object_size, as well. Essentially, if your compiler has a way to emit diagnostics if an expression can be proven to be true, then you can add that to the wrapper. This is possible on both GCC and clang with compiler-specific attributes, so adding diagnostics is as simple as tacking on the correct attributes.

    Why not Sanitize?
    If you're familiar with C/C++ memory checking tools, you may be wondering why FORTIFY is useful when things like clang's AddressSanitizer exist. The sanitizers are excellent for catching and tracking down memory-related errors, and can catch many issues that FORTIFY can't, but we recommend FORTIFY for two reasons:

    • In addition to checking your code for bugs while it's running, FORTIFY can emit compile-time errors for code that's obviously incorrect, whereas the sanitizers only abort your program when a problem occurs. Since it's generally accepted that catching issues as early as possible is good, we'd like to give compile-time errors when we can.
    • FORTIFY is lightweight enough to enable in production. Enabling it on parts of our own code showed a maximum CPU performance degradation of ~1.5% (average 0.1%), virtually no memory overhead, and a very small increase in binary size. On the other hand, sanitizers can slow code down by well over 2x, and often eat up a lot of memory and storage space.

    Because of this, we enable FORTIFY in production builds of Android to mitigate the amount of damage that some bugs can cause. In particular, FORTIFY can turn potential remote code execution bugs into bugs that simply abort the broken application. Again, sanitizers are capable of detecting more bugs than FORTIFY, so we absolutely encourage their use in development/debugging builds. But the cost of running them for binaries shipped to users is simply way too high to leave them enabled for production builds.

    FORTIFY redesign
    FORTIFY's initial implementation used a handful of tricks from the world of C89, with a few GCC-specific attributes and language extensions sprinkled in. Because Clang cannot emulate how GCC works to fully support the original FORTIFY implementation, we redesigned large parts of it to make it as effective as possible on clang. In particular, our clang-style FORTIFY implementation makes use of clang-specific attributes and language extensions, as well as some function overloading (clang will happily apply C++ overloading rules to your C functions if you use its overloadable attribute).

    We tested hundreds of millions of lines of code with this new FORTIFY, including all of Android, all of Chrome OS (which needed its own reimplementation of FORTIFY), our internal codebase, and many popular open source projects.

    This testing revealed that our approach broke existing code in a variety of exciting ways, like:
    template <typename OpenFunc>
    bool writeOutputFile(OpenFunc &&openFile, const char *data, size_t len) {}
    
    bool writeOutputFile(const char *data, int len) {
        // Error: Can’t deduce type for the newly-overloaded `open` function.
        return writeOutputFile(&::open, data, len);
    }
    
    and
    struct Foo { void *(*fn)(void *, const void *, size_t); }
    void runFoo(struct Foo f) {
        // Error: Which overload of memcpy do we want to take the address of?
        if (f.fn == memcpy) {
            return;
        }
        // [snip]
    }
    
    

    There was also an open-source project that tried to parse system headers like stdio.h in order to determine what functions it has. Adding the clang FORTIFY bits greatly confused the parser, which caused its build to fail.

    Despite these large changes, we saw a fairly low amount of breakage. For example, when compiling Chrome OS, fewer than 2% of our packages saw compile-time errors, all of which were trivial fixes in a couple of files. And while that may be "good enough," it is not ideal, so we refined our approach to further reduce incompatibilities. Some of these iterations even required changing how clang worked, but the clang+LLVM community was very helpful and receptive to our proposed adjustments and additions, such as:


    We recently pushed it to AOSP, and starting in Android O, the Android platform will be protected by clang FORTIFY. We're still putting some finishing touches on the NDK, so developers should expect to see our upgraded FORTIFY implementation there in the near future. In addition, as we alluded to above, Chrome OS also has a similar FORTIFY implementation now, and we hope to work with the open-source community in the coming months to get a similar implementation* into glibc, the GNU C library.

    * For those who are interested, this will look very different than the Chrome OS patch. Clang recently gained an attribute called diagnose_if, which ends up allowing for a much cleaner FORTIFY implementation than our original approach for glibc, and produces far prettier errors/warnings than we currently can. We expect to have a similar diagnose_if-powered implementation in a later version of Android.
    Categories: Programming