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.


For Android developers, Context objects can be tricky. To start with, android.content.Context has a zillion subclasses, some of which are really specific (I’m looking at you, NotificationCompatSideChannelService). On top of that, there are a bunch of available calls to retrieve the current Context, all of which seem slightly different. Once you start talking about passing these objects from one part of an app to another, which happens during AdMob mediation, it can get confusing in a hurry. In order to keep things straight, engineers building Android custom events and mediation adapters need to make sure they’re handling Contexts properly.

If you’ve ever built a custom event or mediation adapter for AdMob, you’re probably familiar with these two methods:

requestInterstitialAd(Context context, 
                      CustomEventInterstitialListener listener,
                      String serverParameter,
                      MediationAdRequest mediationAdRequest,
                      Bundle customEventExtras)

requestInterstitialAd(Context context,
                      MediationInterstitialListener listener,
                      Bundle serverParameters,
                      MediationAdRequest mediationAdRequest,
                      Bundle mediationExtras)

They’re from the CustomEventInterstitial and MediationInterstitialAdapter interfaces, respectively, and are used to request interstitial ads from custom events and adapters. Both include a Context parameter that can be used to retrieve information about the execution environment, query permissions, and access user preferences. In most cases, that object ends up being the Activity an app is displaying when its ad request is made (Activity is a subclass of Context), but that’s not guaranteed.

For example, consider an app that switches quickly from one Activity to another, and occasionally shows an interstitial ad during one of the transitions. Requesting a new ad in each onCreate method will likely waste resources, so offloading that work to a separate class that lives outside the Activity lifecycle is a common solution. Because that class isn’t an Activity, though, it can’t use itself as a Context, and instead must request interstitials using the Application object (another Context subclass). If the app uses custom event and adapter classes that were only tested with Activity objects, they might break!

The best practice here is to make sure to test your custom events and adapters with both Activity and Application objects prior to releasing them. A reliable custom event needs to operate the same no matter which is provided, and the same goes for adapters. If, for some reason, the SDK you’re adapting just can’t work with an Application object as the context parameter, you can always trap this using instanceof and log the error:

    Public void requestInterstitialAd(Context context,  
                      CustomEventInterstitialListener listener,
                      String serverParameter, 
                      MediationAdRequest mediationAdRequest,
                      Bundle customEventExtras) {
    if (!(context instanceof Activity)) {
        Log.w(“Example”, “Context not an Activity. Returning error!”);

    // ... code to request an ad using the Activity context ...

If you have technical questions about activities, contexts, or anything else relating to the Google Mobile Ads SDK, stop by our forum.

Starting in January 2016, we’ll be cleaning up some older geo targeting locations in the AdWords API. On January 21, 2016, the targetingStatus of these locations will be changed to PHASING_OUT, and they will be completely removed in an upcoming version of the API.

Most of the targets we're removing are no longer used. However, there are a few with some traffic, and these largely fall into two categories:
  • Criteria that are duplicates of other criteria. You should migrate these as soon as possible for consistency. Any that are not migrated by the time the criteria are removed will be automatically migrated to the new criteria IDs.
  • Criteria that designate places that no longer exist, but previously were meaningful targets.
Please see our developers site for a complete list of IDs affected.

If you have any questions about this change, or other questions about the AdWords API, please contact us via the forum or the Ads Developers Plus Page.


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.


It's been two years since we moved to a regular deprecation schedule. And thanks to developers like you, we've been able to regularly release new versions and features while maintaining code health.

To continue this trend, we'll be simplifying the sunset schedule by tightening our belts a little. Starting with v201511, versions will be sunset one year after release. This will help us reduce the number of out-of-band deprecations. A shorter lifecycle means dated features can ride off into the sunset as intended. Plus, it's easy to remember when the version you're using is about to bite the dust, even if you're not signed up for deprecation announcements or don't obsessively check our deprecation schedule.

We strive to make upgrades easy. If you think they're not, please tell us why on our developer forum so we can make it better.

The DoubleClick Ad Exchange (AdX) Buyer SOAP API and legacy AdX UI will be sunset in January, 2016. After the API is sunset, all static bidding campaigns will be terminated, and requests against any version of the API from AdX accounts will result in an error response. In addition, the legacy AdX UI will no longer be accessible.

As an alternative to the SOAP API, we recommend using the DoubleClick Ad Exchange Hosted Bidding solution. Similar to the static bidding functionality offered by the SOAP API and legacy UI, Hosted Bidding allows you to bid on Ad Exchange inventory without an external real-time bidding platform. At this time, Hosted Bidding is only accessible as a UI that can be found by signing in to your Ad Exchange Account and clicking the Hosted Bidding tab. To learn more, read the Hosted Bidding guide.

These sunsets will not affect real-time bidding applications. All features required to configure real-time bidding campaigns were migrated to the DoubleClick Ad Exchange Buyer REST API when we updated our pretargeting capabilities in July 2014.

If you have any comments or questions about the upcoming sunset, feel free to contact us via the forum or our Ads Developer G+ page.