Posted:

With the advent of video players that support streaming media formats such as HLS and DASH, publishers can now easily support these formats with the IMA SDK for Android. Here is a list of steps to make this work:

  • Use a video player that can play streaming video, such as ExoPlayer.
  • Inform the SDK of your video player's capabilities.

The latter is done via the SDK's AdsRenderingSettings API. Create a new instance of AdsRenderingSettings and then create a list of MIME types you plan to support:

AdsRenderingSettings adsRenderingSettings = 
    ImaSdkFactory.getInstance().createAdsRenderingSettings();
ArrayList arrayList = new ArrayList();
arrayList.add("application/x-mpegURL"); //HLS
arrayList.add("application/dash+xml"); //DASH
adsRenderingSettings.setMimeTypes(arrayList);

Then initialize the AdsManager using these AdsRenderingSettings:

adsManager.init(adsRenderingSettings);

This will allow the SDK to choose streaming ad media to play in your video player. Make sure to add any additional MIME types you plan to support, such as MP4, as this approach assumes that any MIME types not passed in are not supported.

FAQ

How do I play HLS ads using the IMA SDK for iOS?

The default video player used by the iOS IMA SDK supports HLS, so it is not necessary to set that in AdsRenderingSettings.

Will this work with the SDK-owned player?

No, currently you must use custom playback by implementing the VideoAdPlayer interface. For an example of how to do this, check out our guide on custom playback or AdvancedExample.

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

Posted:

We're pleased to announce that we'll be holding a series of Display Ads API Workshops in April 2017. These workshops are a half-day of tech talks, group discussions, networking activities, and one-on-one time with Googlers geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These workshops offer you the following:

  • A great way for you to meet with the display ads API team to ask questions in person and give feedback directly to us.
  • A great opportunity to meet and exchange ideas with fellow developers in the community.
  • Previews of API and SDK roadmaps and select upcoming features.
  • For the first time, one-on-one office hours with ads API Googlers. Sign-ups will be available on-site on the day of the workshops.

The workshops will be held in the following cities:

For more information on the agenda and a preview of our talks, please see our workshop page.

As always, if you have any questions, feel free to drop us a line on the DFP API forums, IMA SDK forums, Mobile Ads SDK forums, or the Ads Developer Google+ page.

Posted:

One of the most important factors in keeping users on your page or in your app is latency - the lower your latency, the more likely your users are to stick around. With this in mind, we'd like to remind you about our best practices for reducing latency with the IMA SDKs. In general, you can reduce latency by doing as much IMA set-up work as possible on page or app load, before your user tries to play a video. The following can be done in all of the SDKs before the user attempts to play a video:

  • Creating your ads loader.
  • Creating your ads request.
  • Requesting ads.
  • Obtaining the ads manager.
  • Registering ads manager event handlers.

You can find more information on optimizing latency in each of our SDKs at the links below:

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

Posted:

On June 1, 2017, Google will cease development of Flash in the IMA SDKs. This will end support for the IMA SDK for Flash, as well as support for Flash VPAID ads in the HTML5 SDK. We strongly encourage all publishers still using the Flash SDK to migrate to the HTML5 SDK. We also strongly encourage advertisers still trafficking Flash VPAID ads to migrate those ads to JavaScript VPAID.

What does this mean for the Flash SDK?

We will not actively prevent ad serving to the Flash SDK. However, new releases will stop after June 1st and we will no longer fix bugs or answer support questions. If ad serving or playback stops working after this date for the Flash SDK, it will not be fixed. We strongly encourage you to migrate to the HTML5 SDK.

What does this mean for the HTML5 SDK?

We will no longer support Flash VPAID ads in the HTML5 SDK. Flash VPAID ads served to the HTML5 SDK will not be rendered and the SDK will fire an error. We strongly encourage you to migrate your Flash VPAID ads to JavaScript VPAID.

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

Posted:

On February 1, 2017, we will implement a new deprecation policy for the IMA SDKs for iOS and Android. The Flash and HTML5 SDKs are unaffected by this policy because they are downloaded at runtime, so all developers are always using the latest version.

Each release will be deprecated 12 months after its successor is released.

As of February 1, 2017, the following SDK versions will no longer be supported:

  • IMA Android prior to version 3.1.3
  • IMA iOS prior to version 3.1.0

If you are currently on one of these versions, we strongly suggest upgrading to the latest version before the new policy takes effect.

Once an SDK version is deprecated, we cannot guarantee that version will continue to work. If we receive reports of crashes related to a deprecated version of the IMA SDK, we may discontinue serving ads to that version. We will also no longer field support requests for these versions on the IMA SDK support forum.

To maintain support, publishers on the latest version of an SDK will have 12 months to move to a new version once its successor is released. To "support" an SDK means we will investigate bugs in that SDK version and work on fixes. If a bug fix requires a change to the library itself, the fix will be applied to the newest version.

For a list of supported SDK versions and their deprecation dates, see the new deprecation schedule pages for iOS and Android. As always, if you have any questions, feel free to contact us via the support forum.

Posted:

Integrating with the IMA SDK for Android has historically meant implementing the VideoAdPlayer interface and playing video ads in your content player. While this approach offers maximum flexibility, it also requires a lot of extra work to get up and running. In our mission to make developers' lives easier, we are proud to offer an alternative: SDK-owned ad playback, added in our newest release, v3.5.2.

Using SDK-owned ad playback, the SDK takes care of playing ads in its own player, allowing you to focus on content playback and the normal ad request flow in your player. With SDK-owned playback, you no longer have to implement a VideoAdPlayer, or worry about VideoAdPlayerCallbacks. Enabling SDK-owned playback is straightforward: simply omit the setAdPlayer call on your AdDisplayContainer.

With the new, simplified integration flow using SDK-owned playback, integrating with the IMA SDK for Android is easier than ever! For a step-by-step guide, head over to our revamped Get Started guide or download the BasicExample project from GitHub and try it out.

SDK-owned ad playback allows publishers to simplify their IMA implementation, but using it is not required. If you already have a VideoAdPlayer implementation or want to use a single video player for both ads and content, you can keep using custom playback. SDK-owned playback merely gives you the option to let the SDK handle some of the implementation complexity for you.

If you have any questions about SDK-owned playback, feel free to contact us via the support forum.

Posted:

Have you ever asked yourself, Can I use the IMA SDK and Google Cast together to display videos with ads on a cast-enabled device? The answer is, yes you can!

We’ve put together a new section of guides and examples that show you how to add cast support to your IMA SDK implementation. They also explain the logic behind requesting ads on the sender and receiver devices. We’ve included both Android and iOS example sender apps, and an example HTML5 receiver.

We recommend familiarizing yourself with the Google Cast SDK as well as the IMA SDKs for Android, iOS and HTML5 before diving into these examples.

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

Posted:

We’ve seen an increase in support questions recently on fatal and non-fatal errors in the IMA SDKs, so we’re here to explain when and why each is fired, and how you should handle one versus the other.

When are fatal and non-fatal errors fired?

Simply put, a fatal error is fired by the SDK when there is no chance for the SDK to play an ad for the remainder of the current video. There are two common scenarios for fatal ad errors. The first is when the SDK itself fails to load. The second (and more common) is when you are requesting one and only one ad, and that ad request fails to return a valid ad.

A non-fatal error is fired by the SDK when something goes wrong with an ad, but the SDK could potentially play other ads. The most common scenario for a non-fatal error occurs when you’re requesting a pod or playlist of ads, and one ad fails to load. Because it could still play other ads in that pod or playlist, the SDK fires a non-fatal error and moves on to attempt the next ad.

How can I tell the difference between a fatal and a non-fatal error?

Fatal errors are what we call “top-level” errors. They trigger one of the following events, depending on your particular SDK:

SDK Triggered event or delegates
HTML5 onAdError(AdErrorEvent)
Android AdErrorEvent.AdErrorListener.onAdError(AdErrorEvent)
iOS adsLoader:failedWithErrorData
adsManager:didReceiveAdError
Flash adsLoadErrorHandler(AdErrorEvent)
adsManagerPlayErrorHandler(AdErrorEvent)

Non-fatal errors are wrapped in a LOG type AdEvent. That event is sent to your AdsManager event listener or delegate. You can access the error message from the LOG event as follows:

SDK Error Data
HTML5 AdEvent.getAdData()[‘adError’].getMessage()
Android AdEvent.getAdData()[‘errorMessage’]
iOS IMAAdEvent.adData[@”logData”]
Flash Error(Event.adData.error).message

How should I handle fatal and non-fatal errors?

When you get a fatal error, you should destroy your AdsManager and play your content video. When you get a non-fatal error, you are not obliged to do anything for video and ad playback to continue - you can log the error message using the snippets shown in the table above for informational purposes.

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

Posted:

In our ongoing efforts to make developing with the IMA SDK easier, we’re pleased to announce that as of version 3.2.1, the IMA SDK for Android is now available on JCenter.

With this release, it's now quicker than ever to integrate with the IMA SDK. Simply make sure you include JCenter in your list of repositories:

repositories {
   jcenter()
}

Then, in your build.gradle's dependencies, include the following compile directive:

compile 'com.google.ads.interactivemedia.v3:interactivemedia:3.2.1'

If you're modifying an existing sample, make sure to remove the IMA SDK JAR file from your libs folder. This directive includes the SDK, and if you already have the SDK JAR in libs, you’ll get errors for having two copies of the same library.

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

Posted:

We’re pleased to announce that the latest version of the IMA SDK for iOS, 3.2.0, supports compiling with bitcode enabled.

To enable/disable bitcode, go into Build Settings in your XCode project and toggle the 'Enable Bitcode' build option. For more information on bitcode, please see the developer documentation.

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

Posted:

Have you ever wished you could experiment with IMA HTML5 SDK features without having to download our samples, modify them for the feature, and host them on your own webserver? Now you can with our new Codepen snippets!

We’ve added codepen snippets to several HTML5 guides. These snippets allow you to modify and execute Javascript right in your browser. To test different aspects of a new feature, you can simply modify the Javascript and re-run the sample, without having to download the files or host them yourself. Codepen snippets are now available for the following guides:

For more information, check out the guides above. We’ll continue to add codepen snippets to new guides as they are released, so keep an eye out! As always, if you have any questions, feel free to contact us via the support forum.

Posted:

We are pleased to announce that the IMA SDK for HTML5 now supports VPAID Flash creatives. When Flash is available on the running platform, the SDK is able to play these creatives in addition to existing formats. This feature allows video publishers added flexibility in their adoption of the SDK as they can continue to accept advertiser VPAID Flash creatives using the HTML5 SDK.

As an example, take a look at a sample ad running in our Video Suite Inspector tool.

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

Posted:

We are pleased to announce the release of the IMA SDK for iOS v3.1.0. This release contains support for Picture in Picture in iOS 9 and HTML5 companion ads. It also introduces a new API, [IMAAdsManager discardAdBreak], for discarding ad breaks. In addition, we have changed where IMAContentPlayhead is passed to the SDK.

Picture in Picture (PiP) is a feature that was introduced in iOS 9, and now IMA publishers can add it to their existing IMA implementation. For more information, please see our PiP guide.

The IMA SDK now supports HTML5 companion ads. There is no implementation change required to use HTML5 companion ads. The SDK uses the same companion ad slot classes and delegates as before.

We have also introduced a new API for discarding ad breaks. Publishers can use [IMAAdsManager discardAdBreak] to implement timeout policies for their apps and to have more control over ad playback.

IMAContentPlayhead is now passed into IMAAdsRequest instead of the IMAAdsManager. This change will require an update to existing implementations.

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

Posted:

We're pleased to announce that we’ll be holding a series of Display Ads API Workshops in March 2016. These workshops are a half-day of tech talks, group discussions, and office hours geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These API workshops are a great way for you to meet with the display ads API team and ask questions in person. The workshops are also a great opportunity for members of the community to bring their feedback directly to us, and exchange ideas and best practices with fellow developers.

The workshops will be held in the following cities:

For more information on the workshops’ agenda and a preview of our talks, please see our workshop page.

As always, if you have any questions, feel free to drop us a line on the DFP API forums, IMA SDK forums, Mobile Ads SDK forums, or the Ads Developer Google+ page.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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:

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