In the coming weeks, we’ll be making changes to the way the IMA HTML5 SDK handles AdSense and Ad Exchange non-linear and full slot ads. To facilitate these changes, we’re adding a new API: AdsRequest.forceNonLinearFullSlot. Gaming publishers are required to set this parameter to true to ensure that all ads returned to your player are correctly rendered as full slot ads. This change is planned to go live the week of November 30th. Keep an eye on our release notes for the exact date as the change is released.

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

 - Shawn Busolits, IMA SDK Team

In the coming weeks, we’ll be making changes to the way the IMA HTML5 SDK handles AdSense and Ad Exchange non-linear and full slot ads. You should be aware of these changes to ensure that your video player behaves as expected once the changes have taken effect.

Definitions

A non-linear ad is a static or animated ad that displays over the video content during content playback. These are also sometimes referred to as “bottom-third” ads, because they typically take up the bottom third of the video player.

A non-linear ad.

A full slot ad is a static or animated ad that usually appears before or after the content, occupying the entire view area. It renders a close button that when clicked closes the ad and, if rendered before the content, triggers the content to start.

A full slot ad.

Current behavior

Currently, non-linear ads are rendered as expected, but full slot ads are also rendered as non-linear ads. So instead of pausing, the video continues to play underneath them while they take up a large portion of the video display.

New behavior

With the new behavior, any non-linear AdSense or Ad Exchange ad greater than 90 pixels in height will be rendered as a full slot ad. This means it will take up the entire video display. When the user clicks the close button, the content will start.

We will also be adding a new UI to these full slot ads which includes a countdown timer and a skip button. You should remove any custom UI elements you’ve added for full slot ads to ensure there are no conflicts with this new UI.

Lastly, to ensure that your ads are rendered properly, make sure your AdDisplayContainer is rendered on top of everything else and takes up the full size of your video player.

Full slot ad with the updated UI.

Testing the changes

If you’d like to test these changes, you can load the test version of our SDK by replacing your load of ima3.js with ima3_test.js. This is a watermarked test binary that changes frequently and without notice; it is not intended for use in production.

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

 - Shawn Busolits, IMA SDK Team

Starting this week, we’re going to incrementally roll out a change in the way the IMA HTML5 SDK handles an ad’s UI.

We will be adding a Learn More button to Ad Exchange and AdSense ads on both desktop and mobile. Clicking on the button will take the user to the advertiser’s site, while clicking elsewhere on the ad will pause or resume it. This is a change from the existing behavior, where clicking anywhere on the ad opens the advertiser’s site.

The new ad UI.

This change will also be rolling out to all mobile web ads that do not use custom click tracking. Note that ads that have no UI before the change will gain a UI with this change. This will allow our mobile web behavior to be consistent with native mobile behavior.

If you have any questions about these changes, feel free to contact us via the support forum.

 - Yury Pavlotsky, IMA SDK Team

Today we’re expanding on our earlier blog post, Manual ad break playback in the IMA SDKs. One of the major benefits mentioned in that blog post is the ability to let your users skip ads they’ve already seen when they resume a video stream they previously suspended. We’re going to show you how to implement that functionality. For the purposes of this demo, we’ll be using the HTML5 SDK, but the principles outlined here can be used to achieve the same functionality in all four of our SDK flavors.

Prerequisites

If you’d like to follow along with these samples, you’ll need to first:

1. Get a copy of our simple sample for HTML5.
2. Modify that sample to disable automatic playback of ad breaks, as outlined in this guide. Be sure to remove the original call to adsManager.start() in onAdsManagerLoaded!
3. Change the ad tag to a playlist with multiple mid-rolls (like this one) so you can see the behavior in action.

Step 1: Saving the user’s progress

The first step towards our ultimate goal is to save the current time of the video when the user leaves the page. For simplicity’s sake, we’re going to be using HTML5’s built-in localStorage object. We’re going to override window.onbeforeunload to grab the current time of the video element when the user leaves the page and save it in local storage.

function init() {
  videoContent = document.getElementById('contentElement');
  playButton = document.getElementById('playButton');
  playButton.addEventListener('click', requestAds);

  window.onbeforeunload = onUserExit;
}

function onUserExit() {
  if (videoContent) {
    localStorage.setItem('watched_time', videoContent.currentTime);
  }
}

Step 2: Restoring the user’s progress

Now that we’re saving the user’s progress, we’ll want to restore the video to that point when the user returns to the page. We’re going to add some code to the init method to grab the stored current time (if it exists) and seek to that time when our video loads.

function init() {
  videoContent = document.getElementById('contentElement');
  playButton = document.getElementById('playButton');
  playButton.addEventListener('click', requestAds);

  window.onbeforeunload = onUserExit;

  watchedTime = localStorage.getItem('watched_time') || 0;
  videoContent.addEventListener('loadedmetadata', function() {
    videoContent.currentTime = watchedTime;
  });
}

Step 3: Skipping previously viewed ads

Now that we’re keeping track of the user’s progress and restoring that progress when the user returns, we can skip and ad breaks they watched in a previous visit. To do that, we’ll modify our adBreakReadyHandler to call adsManager.start() only when the loaded ad break is set to play after the user’s most recent saved progress. To ensure the video starts after the skipped ad breaks, we’ll also add a call to videoContent.play() when we decide to skip an ad break.

function adBreakReadyHandler(event) {
  if (event.getAdData().adBreakTime >= watchedTime ||
      event.getAdData().adBreakTime == -1) { // -1 ensures we play post-rolls
    adsManager.start();
  } else {
    videoContent.play();
  }
}

That’s all there is to it! Try starting your video and watching the first mid-roll break. When you leave the page and come back, clicking the play button will result in the video playing from where you left off. The first ad break you’ll see is the second mid-roll break.

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

 - Shawn Busolits, IMA SDK Team

On September 16th, 2015, the IMA HTML5 SDK will change how it handles custom playback. In order to provide a more seamless ad experience, custom playback on Android 4.0+ devices will be disabled.

As per a previous change, the SDK only selects custom playback when necessary. Since Android 4.0+ devices support standard rendering, it is no longer necessary to use custom playback on these devices.

What must I do to prepare for this change?

1. Double check to make sure you’re always passing in your content video element as the custom playback element. Custom playback will still be used in pre-4.0 Android environments.
2. On mobile, be sure you’re calling AdDisplayContainer.initialize() as a result of a user action. This method is not necessary in custom playback, but it must be called to play ads using standard rendering. Otherwise your ad video will not play. We recommend you always call this method on mobile, so your implementation will be ready for any future devices that support standard rendering.
3. If your code requires a reference to the <video> element playing the ad, then this change might break your implementation. Instead, check the return value of AdsManager.isCustomPlaybackUsed(). If the value is true, the content video reference will be the same as the ad video reference.

If you have any questions about these changes, feel free to contact us via the support forum.

 - Yury Pavlotsky, IMA SDK Team

We recently launched manual ad break playback across our iOS, Android, HTML5, and Flash SDKs. For more info on what this means and how to use it, read on!

What is manual ad break playback?

Under a standard IMA SDK implementation, when an ad rules or VMAP response is returned, the SDK will automatically play each ad break at its cue point. With manual ad break playback, the SDK will instead fire an event when it’s time to play an ad break, and let you decide if or when you’d like to play it.

What are the implications of this change?

If you’re happy with your current ad rules or VMAP performance, this change doesn’t require you to do anything - your implementation will continue to work just as it does now. If you’d like more fine-tuned control over ad break playback timing, then we recommend using this feature.

What are the benefits of this change?

We see two major areas in which this change will help publishers. The first is when a user starts a stream somewhere in the middle of the content instead of at the beginning. (The most common scenario is that the user watched part of the video previously, left the app or page, and returned to continue watching the rest of the video). With a standard implementation, the user will be greeted by (in some cases) a pre-roll, followed by the most recent mid-roll that they watched previously, then the content. By using manual ad break playback you can prevent the pre- or mid-roll (or both) from playing so that the user can go straight to the content, and then resume mid-rolls when the user sees their first mid-roll break for the new session.

The second major use case is misaligned ad breaks. If you’re playing long form content with mid-rolls, and your video fades in and out for mid-roll breaks, you want to make sure that your ad breaks properly align with those fades. In some cases, publishers have told us that the ad break scheduling changes slightly between pieces of content, causing the ad to cut off content for some streams. With this new system, if you know exactly when an ad break should play, you can listen for the AD_BREAK_READY event and delay the ad break playback until the exact time your stream is ready for it.

How do I implement this new feature?

We have guides for each of the SDKs on implementing this new feature:

• HTML5
• Android
• iOS
• Flash

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

 - Shawn Busolits, IMA SDK Team

Last week, we released beta version 15 of the IMA SDK for iOS. This release includes two new features:

• Ad buffer events via IMAAdsManager delegates
• Debugging mode

Ad buffer events

We’re providing more information on ad buffering by introducing new buffering events via the following optional IMAAdsManagerDelegate methods:

• adsManagerAdPlaybackReady:
• adsManagerAdDidStartBuffering:
• adsManager:adDidBufferToMediaTime:

Collectively, these delegate methods provide more transparency into buffer events, giving you more control over the user’s ad experience. For more detailed information on these new methods, take a look at the reference documentation.

Debugging mode

We’ve introduced a new debugging mode setting to allow for more verbose logging to the console. You can now set IMASettings.enableDebugMode to YES to enable debug mode. This should not be used in production, as it will show a watermark on the ad player.

A note about CocoaPods

If you’re using CocoaPods with the IMA SDK, please make sure to use at least version 0.38.

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

 - Yury Pavlotsky, IMA SDK Team

The HTML5 SDK has two main ways to render ads: what we call “standard” rendering and “custom ad playback.” To avoid confusion and to keep you all informed, here’s a breakdown of those rendering modes and how the SDK decides which to use.

Standard Rendering

If you're using the HTML5 SDK you probably have a web page playing your content in a <video> element. In standard rendering, the SDK will create another <video> element and render it in the ad display container div you provided, which should be placed on top of your video player. The ads will then play in this SDK-owned video player on top of your content player. To the user, it looks like one video player switching from content to an ad, but in reality it’s another video player appearing on top of your content to play an ad and then disappearing. For a visual representation of what’s going on, see the image below.

Why use standard rendering?

The main benefit to this standard rendering involves buffering. Using a separate video player to render ads allows us to preserve your content buffer while ads are playing. If you’re playing a pre-roll, you can start loading your content when the ad starts and buffer the content the whole time the ad is playing. For mid-rolls, the separate player allows you to preserve your content buffer while ads are playing - if your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they won’t lose the content in the buffer for 00:05:00-00:10:00.

Custom Ad Playback

As avid blog readers will know, we recommend always passing in your content video element as the custom playback element. If you’re not already doing this, check out our guide to custom ad playback. The HTML5 SDK will intelligently use custom ad playback only when it deems necessary, as described below. When it’s not necessary, it will use standard ad playback.

What is custom ad playback?

When the SDK decides to use custom playback mode, it renders video ads in the same player as your content. This means you lose the buffer-related benefits of standard rendering. If your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they will lose the content in the buffer beyond the ad. Certain ad formats (such as AdSense) require an SDK-owned player and can't play in your content player.

Why use custom ad playback?

Simply put, some platforms do not support multiple, simultaneous, active video elements. On those platforms, the SDK can’t create its own ad player because the one allotted video player slot per page is already occupied by your content player. If the SDK tries to play an ad in a second video player, it will either fail to play (freezing the player) or make it impossible for the content to restart after the ad is finished (again freezing the player). Thus we must show the ad and video content in the same player.

How does the SDK know when to use custom ad playback?

The HTML5 SDK looks at the UserAgent string of each browser on which it’s loaded. When it sees a browser that it knows has trouble with multiple video elements, it uses custom ad playback. Currently those browsers are limited to Android and iPhone. We’re in the process of phasing out custom ad playback on Android 4.0+ to bring the benefits of standard playback to users.

Now you know all there is to know about HTML5 video ad rendering. As always, if you have any questions feel free to contact us via the support forum.
 - Shawn Busolits, IMA SDK Team

We’re excited to announce the addition of Swift samples to the IMA SDK! To view these samples check out our GitHub repo. Along with these new samples we’ve also added Swift snippets to our quick start guide.

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

 - Shawn Busolits, IMA SDK Team

Today we’re announcing the release of beta version 13 of the IMA SDK for iOS. This release includes two new major features:

1. The SDK can be included as a framework in your project.
2. The SDK now supports ad playing in the background.

Importing the SDK as a Framework

Prior to today’s release, importing the SDK involved manually adding every header file to your project, importing every header file individually in your source, and manually including the required frameworks. With the new framework model, you can add a single .framework file to your app and replace all of your header import source lines with a single import statement.

For CocoaPods Users

If you use CocoaPods, your build will fail after you update to beta 13. But fear not, you can fix this in a matter of seconds with the following steps:

1. Locate and remove each instance of an imported IMA header file in your source (these will look like #import “IMA<something>.h”).
2. Add the following line to the first header or implementation file to access an IMA object:

   @import GoogleInteractiveMediaAds;

For Manual Importers

If you don’t use Cocoapods, your path to upgrade is slightly different. You can update using the following steps:

1. Remove all of the IMA header files and the IMA library file from your project.
2. Under "Build Phases” > “Link Binary With Libraries”, click the plus sign, select “Add Other...”, and navigate to the downloaded and extracted SDK files. Select GoogleInteractiveMediaAds.framework from whichever folder applies to your implementation (with or without AdMob) and click “Open”.
3. Follow the two steps above for CocoaPods users.

Background Ad Playback

Since our launch, one of the most requested features has been background ad playback. Suppose, for example, you author a music streaming app, and you want to be able to request and play ads in the background. With today’s release, however, we now support requesting and playing ads in a background service. For more info and implementation instructions, see our Background Ad Playback guide.

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

 - Shawn Busolits, IMA SDK Team

A few weeks back we hosted a workshop for the Display Ads APIs and SDKs where we gave presentations on the DFP API, IMA SDK, and Mobile Ads SDK. If you weren’t able to attend, or want a refresher on something you saw that day, you can check out our presentation videos and slides. If you have any questions about those videos, feel free to ask on our respective forums:

• DFP
• IMA
• Mobile Ads

 - Shawn Busolits, IMA SDK Team

Today we're releasing Beta 10 of the IMA Android SDK. This is primarily a service release to address performance and bug fixes, but the release also includes some API changes to be aware of.

Changes in Beta 10

• Added ImaSdkSettings.getMaxRedirects and ImaSdkSettings.setMaxRedirects.
• IMA API classes are now final.
• The following AdError.AdErrorCode values have been removed:
• API_ERROR - instead use UNKNOWN_AD_RESPONSE.
• PLAYLIST_MALFORMED_RESPONSE - instead use UNKNOWN_AD_RESPONSE.
• REQUIRED_LISTENERS_NOT_ADDED - was not being raised by the SDK.
• VAST_INVALID_URL - instead use VAST_LOAD_TIMEOUT.
• Bug fixes.

Download IMA Android SDK Beta 10

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

Check out the release notes page to stay up to date on IMA Android SDK releases.

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.

 - Bret McGowen, IMA SDK Team

Like any Android library, the Google Play services SDK impacts the final size of applications that include it. Good developers care about the size of their apps, so today we’d like to show you two ways that you can leverage the Android plugin for gradle to reduce the APK size of applications that include Google Play services.

1. Split JAR Architecture

   Beginning with Google Play services 6.5, additional maven artifacts have been added to the Google Repository that contain single domains of functionality. This means that you can include just those portions of Google Play services that your app uses. For example, here’s how to configure gradle to incorporate the JAR that contains functionality relating to ads:

   dependencies {
       compile 'com.google.android.gms:play-services-ads:6.5.+'
   }
   

   That line instructs gradle to include everything Mobile Ads developers need, with the exception of the IMA SDK JAR needed for IMA applications.

   Please note that if you currently initialize Mobile Ads SDK banner ads via XML layout files, you should continue including the full Google Play services artifact. See this blog post for more information.

2. Shrink Resources

   The Android gradle plugin supports the ability to automatically exclude unused resources during the build process via the shrinkResources gradle property. To take advantage of this in your release builds, just add “shrinkResources true” to your build.gradle file’s release configuration:

   android {
       buildTypes {
           release {
               minifyEnabled true
               shrinkResources true
           }
       }
   }
   

   Note that the shrinkResources property requires that minifyEnabled be set to true as well, though that’s already a good practice for release builds.

Both of these techniques are quick to implement, so consider giving them a try. In testing, the use of shrinkResources and the new, split JAR maven artifacts reduced the APK size of our Interstitial Example by 1.2MB -- almost 50%!

If you have questions about these techniques and how to put them to work in your applications, visit us on the Mobile Ads SDK forum or the IMA SDK forum.

 - Andrew Brogdon, Mobile Ads Developer Relations

Today we’re announcing the release of v6.5 of the Google Mobile Ads SDK! It’s listed as Google Play services 6.5 (Rev. 22) in the Android SDK manager, and is available for download right now. Those of you using Android Studio should download Google Repository (Rev. 14) to get the latest Gradle artifacts.

Under the hood improvements (greater stability, more efficient use of resources) make up most of the changes, but we’re pleased to note that this will be the first version of the SDK to support a split jar architecture. Previously, the SDK was compiled as a single, all-encompassing JAR file. Beginning with this release, however, it’s also built into separate JARs, each covering a specific domain of functionality. Interactive Media Ads (IMA) and Mobile Ads developers can now reference part of the Play Services SDK without needing to import the whole thing. This in turn reduces the APK size and memory footprint of your applications.

Taking advantage of the new architecture is easy -- you just need to change how you’re incorporating the SDK in your build process. Here’s an excerpt from a typical build.gradle file for an app that uses the SDK to display mobile ads:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.google.android.gms:play-services:6.+'
}

And here’s one that targets the ads library specifically, new in v6.5:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.google.android.gms:play-services-ads:6.+'
}

That’s it! Gradle will now incorporate the new, smaller JAR into your application. If your app consumes other services from the SDK, simply add the relevant JARs (play-services-games or play-services-location, for example) to your build file as well.

IMA developers can make this change now. If you’re a Mobile Ads developer, one important thing to note is that the new split jar architecture currently works only with projects that configure banner ads in Java code, and not in XML. We plan to support XML configurations in the future, but for now if you’re defining and configuring your AdViews in an XML layout file, you should continue to reference Play Services in the existing manner.

You can read the Google Play Services Announcement on the Android Developers Blog for a summary of what’s new with this release. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

 - Andrew Brogdon, Mobile Ads Developer Relations

Last week we released beta 10 of the IMA SDK for iOS. This release comes with a few new features including the following:

• Ad rendering via the new WKWebView in iOS 8
• Addition of calling classes in delegate methods
• New TAPPED event for tracking user taps on the ad container

The most important thing to know about this release is that you will now need to include the WebKit framework as an optional framework in your implementation and build for 64-bit support. If you are a Cocoapods user, this will be done for you in the generated xcworkspace when you upgrade to beta 10 via pod install.

Ad rendering via the new WKWebView in iOS 8

We’ve moved ad rendering from UIWebView to the new WKWebView in iOS 8 implementations. This should fix a number of issues we saw with the old web view in iOS 8, including skip button unresponsiveness and delayed tracking event firings. As a side effect of this change, you’ll need to include the WebView framework as an optional framework in your project and build for 64-bit support. If you’re a Cocoapods user, this will be done for you when you run pod install to get the latest version of the SDK.

Addition of calling classes in delegate methods

After the beta 9 release, we noticed that a few of our delegate methods were missing a reference to their calling class, which put them out of line with iOS standards. We’ve resolved this issue in beta 10 and marked the old methods (without a reference to the calling class) as deprecated. You can see a list of the new methods in our release notes.

New TAPPED event for tracking user taps on the ad container

Since launch, one of our most requested features has been to add the ability to respond to user taps on the ad container while an ad is playing. We’re happy to announce that Beta 10 fulfills this request by adding kIMAAdEvent_TAPPED to the list of AdsManager events. You can start listening to this event by setting up your AdsManager delegate as follows:

  - (void)adsManager:(IMAAdsManager *)adsManager
      didReceiveAdEvent:(IMAAdEvent *)event {
    if (event.type == kIMAAdEvent_TAPPED) {
      // Handle TAPPED event
    }
  }

This event will be fired any time a user taps on a non-clickable part of an ad (taps on the "Learn more" or "Skip" buttons will not result in a TAPPED event).

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

 - Shawn Busolits, IMA SDK Team

Today we're announcing support for Internet Explorer 11 in the IMA HTML5 SDK. The SDK is now compatible with the desktop versions of Chrome, Firefox, Safari, and Internet Explorer, as well as the mobile versions of Chrome, Safari, and the default Android browser. For more information on the supported platforms of the IMA SDK, check out the supported video player platforms.

Getting started

There are no configuration or setting changes to the IMA HTML5 SDK to enable IE11 support. If you already have a player with the IMA HTML5 SDK integrated, you can start serving to IE11 visitors immediately.

If you want to walk through integrating the IMA HTML5 SDK with an HTML5 video player, check out our quick start guide.

Older Internet Explorer versions

Currently only IE11 is supported; some publishers are using the IMA HTML5 SDK with IE10 without issues, but it isn't officially supported. SDK support will be focused on on IE11 and subsequent versions given the upgrade rate from IE10 to IE11. Version 9 and earlier of Internet Explorer are not supported by the IMA HTML5 SDK and likely will not correctly serve video ads.

Questions?

If you have any questions about Internet Explorer support or other IMA SDK questions, feel free to contact us via the support forum.

 - Bret McGowen, IMA SDK Team

We recently updated the iOS and Android quick starts for IMA to make them more streamlined and informative. The new quick starts are done in the style of a code lab - we first provide a sample video player app with no ad integration, then walk you through the steps of adding the IMA SDK to the app. We also provide a completed example if you just want to follow along. If you haven’t yet tried the IMA SDKs for mobile, give our new quick starts a spin and let us know how you like them via our forum.
 - Shawn Busolits, IMA SDK Team

In Part I, Chris showed you how to create and traffic a video ad. In Part II, you’ll learn how to get that ad displayed before your video content in Flash, HTML5, iOS, or Android.

The IMA SDK requires you to have an ad tag that points to your ad. An ad tag is a URL that returns a VAST response. The VAST (or VMAP) response contains information about your ad, including tracking URLs, clickthrough destinations, and the media files for the video ad. For more information about VAST, see the IAB website.

If you’re using DFP, the UI can generate an ad tag for you based on your line item and ad unit criteria. To generate the ad tag for your line item, follow these steps.

Now that you have your ad tag, let’s take a look at some of the parameters. We’ll use one of our standard sample tags for this exercise:

http://pubads.g.doubleclick.net/gampad/ads?
    sz=640x360&
    iu=/6062/iab_vast_samples/skippable&
    ciu_szs=300x250,728x90&
    impl=s&
    env=vp&
    gdfp_req=1&
    output=xml_vast2&
    unviewed_position_start=1&
    url=[referrer_url]&
    correlator=[timestamp]&
    scor=[timestamp]

sz

The size of the video ad that you’re requesting.

iu

Your “inventory unit” - the ad unit you created in Part I. This is in the format <network_code>/<ad_unit_code path>.

ciu_szs

If your ad unit has associated companion ads, their sizes will be listed here.

impl

The request mode. Here, “s” for “sync”.

env

The environment. Here, “vp” for “video player”. 

gdfp_req

Indicates that this is a DFP request rather than the legacy Google Ads Manager.

output

The type of output you want from your ad request. Typical values are “vast” or “vmap”.

unviewed_position_start

Enables delayed impressions for your ad. This ensures that an impression isn’t counted until the ad starts playing.

url

The URL of the page requesting ads. This will also be automatically filled in by the SDK.

correlator

This randomly-generated value will be filled in by the SDK. It’s used for a number of things, but they all boil down to detecting ad requests that come from the same instance of a page load.

scor

Like the correlator, but refreshed when your video stream changes rather than when the page refreshes. Used to detect ad requests that come from the same video stream instance.

For more info on these parameters, see this DFP help center article.

Now that you have a basic understanding of your ad tag, it’s time to plug it into your IMA SDK implementation. If you’d like to use a video player with the SDK pre-integrated, we have pre-baked solutions for HTML5, iOS, and Android. If you want to do your own SDK integration, check out the quick start guide for Flash, HTML5, iOS, or Android. In each of the sample implementations, you’ll find a reference to at least one ad tag.

For example, the HTML5 ad tag reference is in ads.js and looks like this:

adsRequest.adTagUrl = “YOUR_AD_TAG_HERE”;

Now fire up the sample and request an ad. Voila! You’ll now see the ad you trafficked in Part I serving as a pre-roll to your video content!

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

 - Shawn Busolits, IMA SDK Team

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:
   
   

   @Override
   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:
   
       AdsRequest.setContentProgressProvider(ContentProgressProvider);
   
   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:
   
   

   @Override
   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

• Beta 9 also introduces Ad.getTitle, Ad.getDescription, and Ad.getContentType.
• Adds information about ad pod position to the ad UI; for example, "Ad 1 of 4: (0:13)". 
• Bug fixes
  
  

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.

 - Bret McGowen, IMA SDK Team

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
                           adsRenderingSettings:self.adsRenderingSettings];
}

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.

 - Shawn Busolits, IMA SDK Team