Today we're announcing Beta 9 of the IMA Android SDK. This release includes important new API changes to support upcoming alternate IMA SDK ad playback. These changes will prevent your app from compiling so you'll need to make a few code updates using the following guide.

Required Changes

  1. Pause and resume ads with AdsManager

    Previously, the SDK did not provide a method to pause/resume the current ad. Beta 9 of the SDK introduces AdsManager.pause() and AdsManager.resume() to control these events. You should no longer directly control the pause/play/resume of ads via your video player. Instead, use the AdsManager methods. In the future, the IMA SDK may play ads with a video player other than your content video player, so utilizing the AdsManager methods now will ensure that ad pause and resume calls are called on the appropriate player.

  2. Change getProgress() to getAdProgress()

    The VideoAdPlayer.getProgress() signature has changed; it now explicitly states it's returning the progress of the current ad:

        VideoProgressUpdate getAdProgress()

    When implementing this method, return VideoProgressUpdate.VIDEO_TIME_NOT_READY if an ad is not playing (for example, if content is playing). Here's a sample getAdProgress method:

    public VideoProgressUpdate getAdProgress() {
      if (currentVideoIsAd() && currentVideo.getDuration() > 0) {
        return new VideoProgressUpdate(
            video.getCurrentPosition(), video.getDuration())
      } else {
        return VideoProgressUpdate.VIDEO_TIME_NOT_READY;

  3. Return content progress with ContentProgressProvider

    For the SDK to automatically schedule ad breaks when ad rules (for DFP) or VMAP playlists are returned in an ad tag, your player should provide the playback progress of your content video. The ContentProgressProvider interface has been introduced to allow the SDK to check on actively playing content. Pass an implementation of ContentProgressProvider to your AdsRequest object via:


    This method should return VideoProgressUpdate.VIDEO_TIME_NOT_READY if content is not playing (for example, if an ad is playing). Here's a sample ContentProgressProvider implementation:

    public VideoProgressUpdate getContentProgress() {
      if (currentVideoIsContent() && currentVideo.getDuration() > 0) {
        return new VideoProgressUpdate( 
            video.getCurrentPosition(), video.getDuration());
      } else {
        return VideoProgressUpdate.VIDEO_TIME_NOT_READY;

Why should I update to Beta 9?

In addition to bug fixes, Beta 9 of the SDK introduces important changes to clarify some API intentions and to, in a later release, allow the SDK to use an SDK-managed video player to play ads when it would improve the ad viewing experience for certain environments and ad types.

Beta 9 is an optional upgrade; new SDK integrations should use Beta 9 (check out our quick start guide), but your existing apps can upgrade at your discretion. The API changes introduced in Beta 9 will carry over to later IMA Android SDK releases, so if you wish to minimize code changes when the next version of the IMA Android SDK is released, you can make these app code changes now.

Other changes in Beta 9

Download IMA Android SDK Beta 9

You can get this latest release of the IMA Android SDK from our IMA SDK downloads page.

Other questions?

As always, feel free to drop us a line on the IMA SDK forum and follow our Google+ page for other announcements and updates.

This week we released Beta 8 of the IMA SDK for iOS (not to be confused with support for iOS 8 -that was added in the previous release, Beta 7). This release adds a new object, IMAUIElements, which allows you to customize which parts of the ad UI are shown while an ad is playing. Currently, this customization is limited to the countdown timer and ad attribution. By default, all available UI elements will be displayed by the SDK. We anticipate another iOS SDK release shortly; unless you plan on taking advantage of this new functionality immediately, we recommend hold off on upgrading until we release Beta 9 in the coming weeks.

To configure the ad UI, modify the members of the uiElements property on the adsRenderingSettings like so:

- (void)adsLoader:(IMAAdsLoader *)loader 
    adsLoadedWithData:(IMAAdsLoadedData *)adsLoadedData {
  self.adsManager = adsLoadedData.adsManager;
  // …
  self.adsRenderingSettings = [[IMAAdsRenderingSettings alloc] init];
  // Show no attribution or countdown timer.
  self.adsRenderingSettings.uiElements = @[];
  // Or, show only ad attribution.
  self.adsRenderingSettings.uiElements = @[kIMAUiElements_AD_ATTRIBUTION];
  // Or, show both countdown timer and ad attribution.
  self.adsRenderingSettings.uiElements =
      @[kIMAUiElements_AD_ATTRIBUTION, kIMAUiElements_COUNTDOWN];
  // ...
  [self.adsManager initializeWithContentPlayhead:self.contentPlayhead

This configuration will not always be honored; some ad formats (e.g. AdSense and YouTube-hosted ads) require that certain UI elements be displayed. Also note that displaying the countdown timer requires ad attribution - if you want to display a countdown timer, you must also display ad attribution. You can check which UI elements are being displayed by using the uiElements property of the IMAAd object tied to the STARTED event.

As always, if you have any questions feel free to contact us via the support forum.


This is a friendly reminder that, on February 27, 2015, we will sunset DFP API versions v201311, v201308, and v201306. At that point, requests to these versions will fail. We'll also remove them from our online documentation and the client libraries. If you are currently using one of these versions, this is an excellent time to begin migrating to a supported version. See the release notes for a list of the many new features in our recent API versions.

Going forward, all DFP API versions will follow a consistent deprecation schedule: versions will be supported for one year, deprecated for one quarter, then sunset. This means each of our quarterly API versions will be available for 15 months from the time of release. This deprecation schedule enables us to spend more time improving the latest versions with new features.

Note that v201311 is the last version that supports ClientLogin, which was officially deprecated across all of Google on April 20, 2012. If your application is not yet using OAuth2, you must migrate before Feb 27, 2015.

If this task seems daunting, don't fret, we have you covered. On our Developer page, we have a helpful OAuth2 guide to make sure the transition is as smooth as possible. As an added reason to switch, the DFP API now supports OAuth2 service accounts. You can add service account users directly in the DFP UI. For more information, see here for a guide on how to use a service account user with the DFP API.

If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum.

Do you save your AdWords API reports to a database? Do you have code that detects and skips header and summary rows? If the answer to these questions is "why yes, I do!", then you'll be happy to hear that in AdWords API v201409 you can modify your report requests so that the returned results will not include these rows.

Excluding the report header

Prior to v201409, the output of each AdWords report included a header that gave the name of the report and the date range in your predicates:

"KEYWORDS_PERFORMANCE_REPORT (Sep 21, 2014-Sep 27, 2014)"

If you do not want this row in your report results, include the new skipReportHeader HTTP header with a value of true.

Excluding the report summary

Similar to the header, each AdWords report for versions prior to v201409 returned a summary row with totals in its final row of output:

Total, --, --,44700

If you don't want this row in your report results, include the new skipReportSummary HTTP header with a value of true.

Note: If you do not include these headers or specify a value of false for both headers, your report results will include the header and summary rows, just as they did for prior versions of the AdWords API.

For more details, check out our updated Reporting Basics guide. Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

Today we're announcing the release of AdWords API v201409. Here are the highlights:
  • Mobile campaigns for search and display. Search Mobile App and Display Mobile App campaign subtypes are now available via CampaignService. These new subtypes are a simplified way of creating campaigns focused on mobile app promotion.
  • Ad Customizers. Ad Customizers previously available for Test Accounts only are now enabled in production. With this feature you can include dynamic values in your ads based on feed data.
  • Currency support for conversions. Conversion trackers (including offline conversions) now support currency specification. You can also set default currency per tracker.
  • Website call conversion tracker. This tracker allows the collection of conversion stats for calls made on a script-generated phone number placed on your website.
  • Rule-based remarketing lists. The new API version allows you to create and manage rule-based remarketing lists. This feature allows you to use simple rules to better target the people who visited your website.
  • Better Labels handling. LabelIds column is now available in all relevant reports. We've also added both Labels and LabelIds columns to the Criteria Performance report.
  • Updates to reporting. A new Extension Placeholder report is now available for retrieving consistent extension stats. Reporting interface was extended to allow you to control the presence of report headers and footers in the response.
There's also an important API-level change in v201409. Starting this version, the clientCustomerId header is now a required header for calls to all services except CustomerService. If your application relies on a default account identified by authorization credentials, you need to update it to send a valid customer ID for every request. You can obtain the customer ID via a get call to the CustomerService.

If you're still using v201402 of the AdWords API, please note that it's being sunset on November 6th, 2014. We encourage you to skip v201406 and migrate straight to v201409. If you're using v201406, be aware it's now marked deprecated and will be sunset on April 6th, 2015.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201409 migration guide. The updated client libraries and code examples will be published shortly. With this release, we've also updated the Required Minimum Functionality document to include some of the newly added features that are now required in third-party tools. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

We recently deprecated the default namespace in the AdSense Management API so now you should show an account picker to your users and add an account ID to all requests.

The Accounts resource offers both a name and an ID but for most accounts these were showing the same string (something like "pub-12345678901234"). To make the process more intuitive for users, we are improving the logic behind the name.

From now on, the property will have the company name or, in its absence, the contact name. If you still want to show the account ID, just use the id field.

This also applies to the Host API, although the default namespace can still be used.

As always, if you have any questions, feel free to drop us a line on our API forums.

We previously announced changes to the way the IMA HTML5 SDK handles custom playback and custom click tracking elements. Starting today, October 2, 2014, those behavior changes will be rolling out.

Custom playback changes

Effective today, custom playback will now be used only when necessary (e.g., on devices such as iPhones or pre-4.0 Android phones) rather than whenever a custom playback video element is passed in.

We recommend all implementations now pass in the custom playback element so that ads will be rendered via a more seamless playback experience across different environments. For more info on the change and code snippets to help you upgrade, see upgrading to the new custom playback.

Custom click tracking element changes

Custom click tracking elements will now only be used in certain video environments. To determine whether or not a custom click tracking element is being used, check ima.AdsManager.isCustomClickTrackingUsed in an AdEvent such as ima.AdEvent.STARTED. Additionally, please do not render your custom click tracking element over your video player as it will break the ad experience by preventing clickthroughs on the ad and skip button. For more information on the custom click tracking element changes, see "a note about custom click tracking elements" on our custom playback guide.

As always, if you have any questions about these changes or other IMA SDK questions, feel free to contact us via the support forum.