Today we're pleased to announce the release of the Unified Native Ads API, an easier way to implement AdMob Native Ads Advanced. This feature is now available in Google Mobile Ads for iOS, as of version 7.28.0. The Android version will be made available in an upcoming release.

With this feature, the existing native ad formats in Native Ads Advanced — GADNativeAppInstallAd and GADNativeContentAd — are replaced by a single format, GADUnifiedNativeAd. The corresponding views, GADNativeAppInstallAdView and GADNativeContentAdView, are replaced by a single corresponding view, GADUnifiedNativeAdView.

Using the Unified Native Ads API, you no longer need to create UIs for ad content and app install ad formats separately. Instead you will create one UI for unified native ads, saving you time from developing and maintaining two separate UIs and associated code for the two previous ad formats, while still getting the same ad demand.

Here's a short code example showing how your implementation might change when migrating from the separate formats to the new unified format:

@implementation ViewController

- (void)viewDidLoad {
  [super viewDidLoad];

// Note here we request only `kGADAdLoaderAdTypeUnifiedNative` and no
// longer request both `kGADAdLoaderAdTypeAppInstall` and
// `kGADAdLoaderAdTypeContentAd`
  self.adLoader = [[GADAdLoader alloc] initWithAdUnitID:YOUR_AD_UNIT_ID
          rootViewController:self
                     adTypes:@[ kGADAdLoaderAdTypeUnifiedNative ]
                     options:nil];
  self.adLoader.delegate = self;
  [self.adLoader loadRequest:[GADRequest request]];
  }
}

#pragma mark - GADUnifiedNativeAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveUnifiedNativeAd:(GADUnifiedNativeAd *)nativeAd {
 // A unified native ad has loaded, and can be displayed.
}

// Note that the two separate ad type delegate callbacks are no longer needed.
#pragma mark - GADNativeAppInstallAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveNativeAppInstallAd:(GADNativeAppInstallAd *)nativeAppInstallAd {
   // An app install ad has loaded, and can be displayed.
}

#pragma mark - GADNativeContentAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveNativeContentAd:(GADNativeContentAd *)nativeContentAd {
   // A content ad has loaded, and can be displayed.
}

With the Unified Native Ads format, you still need to respect the required and recommended assets for display, and check the availability of certain assets when displaying the Unified Native Ad.

For detailed documentation on how to implement Unified Native Ads, refer to the developer documentation and the updated sample code.

If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.

Today we're announcing a behavior change when requesting test ads using the Google Mobile Ads SDK. It enables you to test your own ad units while also ensuring that you are in test mode.

When using the Google Mobile Ads SDK during development, we recommend that you configure your device to request test ads. Always testing with test ads is important so you avoid having your account flagged for invalid activity.

Previously, enabling test ads resulted in the same sample ad like this one being shown in your app:

While this worked well as a basic check, it didn't allow for testing what real ads would look like in a production environment. For example, you couldn't test your mediation configurations or the different types of banner and interstitial formats that AdMob offers. The update we're rolling out addresses these problems.

New Test Ad Behavior

Starting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity.

Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad.

Sample 300x250 Banner ad

For native advanced test ads, the headline asset has the text "Test Ad" prepended.

Sample native content ad.

Test ads with Mediation

When using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guide for more information on how to enable test ads on those networks.

See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.

One of the biggest cheers from the crowd at I/O '17 came in response to Stephanie Saad Cuthbertson's announcement that Kotlin would be an officially supported language for Android development starting with Android Studio 3.0. If you're an AdMob or Doubleclick publisher who's been eager to make the leap to a new language, we've got another announcement you might like: now that the new version of Android Studio has launched, we've released bunch of new mobile ads resources to support the Kotlin community.

If you haven't seen Kotlin yet, it's a statically typed language developed by JetBrains that compiles down to the same JVM bytecode that Java does, but includes a number of new features that can make Android development faster and easier. Things like dedicated data classes with less boilerplate, the Elvis operator, lambdas, SAM conversion, explicit nullability for references, and lots of other modern language features come built-in. For more information, see Introduction to Kotlin (also from I/O '17) in which Andrey Breslav and Hadi Hariri code up examples of the language's best features:

When you're done, you can see those same features in action in our new developer resources, which are now available to the AdMob and Doubleclick publisher community.

Samples

The Mobile Ads DevRel team maintains a GitHub repository of Android samples covering our API, and we've pushed Kotlin versions for each ad format. If you been wondering how Kotlin's Android extensions work with AdMob's banner ad layouts, for example, we've got a new sample app that'll show you. If you're curious how native ads work with all the new nullability stuff, we've got you covered with Kotlin samples for those formats as well.

In addition, we've included a new version of our API Demo app, which features a navigation drawer full of individual API demos for things like banner sizes, category exclusions, and more, all in Kotlin.

Implementation Guides

We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations.

Questions?

If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

Ever wondered about the best ways to monetize with banner ads while maintaining a great user experience? If so, the Mobile Ads Garage is here to help. In the third episode, Andrew and Gary the Graphics Guy cover how to integrate banner ads into a mobile app's UX, with a little help from Aunt Betty, hairless cats, and discount moose repellent. You'll see detailed breakdowns of things to avoid, plus reliable best practices that you can take back to your own apps. As always, links to guides, samples, and other resources are included.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Today, the first episode of the Mobile Ads Garage hits YouTube! The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down a feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

The series will make its home on YouTube's Google Developer Channel, where you'll find the first episode in the Mobile Ads Garage playlist along with a sneak peek of the next four.


In addition to being a new way that people can find out about the SDK and how to use it, the series is a way for publishers to let us know what features they'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

We recently announced SDK-less mediation - a new way for DFP and AdMob publishers to use mediation to access additional ad networks without having to integrate and maintain multiple third-party SDKs and adapters. Today, we would like to go into more detail on how you can integrate SDK-less in your project.

With SDK-less mediation, everything is done through a single SDK, the Google Mobile Ads SDK. It is now possible to add additional ad networks server-side without having to update your apps. Also, SDK-less supports all existing mediation features including ad network optimization, live eCPM, and country-specific CPM values, so you won’t lose any of the features that you get with standard mediation.

An SDK-less network looks and feels like any other third-party mediation network in AdMob. It includes an ‘SDK-less’ suffix (see screenshot below) and has its own settings.

Supporting SDK-less Mediation

To support SDK-less ad networks, Android apps require v7.8 or higher of the Google Mobile Ads SDK for both AdMob and DFP. However, devices that have an up-to-date Google Play services already support SDK-less.

For iOS apps, v7.2.1 or higher of the Google Mobile Ads SDK is required for AdMob and v7.6.0 or higher is required for DFP. If a publisher’s app is not updated to the minimum SDK version required to support SDK-less networks, then the mediated request excludes all SDK-less networks.

In many cases, even after you migrate to the latest version of the Google Mobile Ads SDK, there may be apps that still reference older SDKs. To accommodate this, AdMob allows publishers to place both SDK adapters and SDK-less sources in a single mediation chain. Apps that don’t meet the minimum SDK requirements will ignore the SDK-less mediation sources automatically.

Ad Networks Supporting SDK-less Mediation

There are currently four ad networks that support SDK-less mediation for both banner ads and interstitial ads. The AdMob developer site for Android and iOS provides a table that lists all the AdMob mediation networks including the type of mediation and ad formats that they support. Please keep an eye on this table as there will be more ad networks supporting SDK-less in the near future.

If you have any questions regarding SDK-less mediation, feel free to contact us through our forum.

The Google Mobile Ads API Demo apps for Android and iOS are now available. These new apps contain advanced examples for both AdMob and DoubleClick for Publishers (DFP) that demonstrate features of the Google Mobile Ads SDK that can help you improve the user experience and maximize ad revenue. Whether you’re a new publisher or a seasoned veteran of the SDK, the API Demo apps showcase new ways to customize ad requests, experiment with multiple ad sizes, and compare AdMob and DFP technologies.

Download the API Demo apps for Android and iOS today and explore new ways to improve your integration with the Google Mobile Ads SDK!

If you have any questions regarding the new API Demo apps, feel free to contact us through our forum.

Today we’re pleased to announce two new versions of the Google Mobile Ads SDK: version 7.5 for Android, and version 7.3.1 for iOS. Included is a brand new way to monetize your apps with the Google Mobile Ads SDK: native ads!

With native ads, publishers can display ad assets directly in native views, using layouts and storyboards they design to fit their user experience. You now have the power to monetize with ads that are seamless with content!

Native ads are currently in a beta with a limited group of publishers, but the code is included in the latest releases of the Mobile Ads SDK for iOS and Android. Those of you using Android Studio can download Google Repository (Rev. 19) via the Android SDK Manager to get the latest Gradle artifacts, and developers with Eclipse projects can find it listed as Google Play services (Rev. 25). Publishers with iOS apps can snag the latest SDK for that platform by updating their Podfile to pull version 7.3.1.

For AdMob, DFP, and AdX publishers, there are two system-defined native ad formats: App Install and Content. Each provides a set of image and string assets that make up the ad. App Install ads contain assets named “price,” “star rating,” and so on, while Content ads have “body,” “logo,” and others. See the AdMob and DFP help center articles for more information about the formats.

Publishers using DFP can also take advantage of custom native ad formats. With a custom format, you can create your own set of asset definitions, and then upload creatives with a matching set of values.

Native ads are loaded using the new AdLoader and GADAdLoader classes, which can request a single format or several at the same time, helping you maximize the value of your impressions. Here’s an example showing how to request an App Install ad on Android:

AdLoader adLoader = new AdLoader.Builder(this, DFP_AD_UNIT_ID)
        .forAppInstallAd(new NativeAppInstallAd.OnAppInstallAdLoadedListener() {
            @Override
            public void onAppInstallAdLoaded(NativeAppInstallAd ad) {
                /* display the ad */
            }
        }).build();
adLoader.loadAd(new AdRequest.Builder().build());

And here’s the iOS equivalent:

self.adLoader = [[GADAdLoader alloc]
                   initWithAdUnitID:DFP_AD_UNIT_ID
                 rootViewController:rootViewController
                            adTypes:@[ kGADAdLoaderAdTypeNativeAppInstall ]
                            options:nil];
self.adLoader.delegate = self;
[self.adLoader loadRequest:[GADRequest request]];

Check out the native ads guide (Android | iOS) for more information about native ads. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

Imagine you’ve just finished creating a line item targeting mobile devices in DFP, and your manager comes to you and says, “Bad news! Our Android developer was just eaten by a bear, so now it’s your job to get that line item into our new app.” Don’t worry! Displaying DFP ads in Android applications is surprisingly easy.

First, check your configuration

If you’re already using the Mobile Ads SDK in your project, you’re ready to go. If not, check our quick starts for Android Studio and Eclipse to learn the best way to include the SDK.

Retrieve your ad unit ID and size

To display your new line item, you’ll need to retrieve its ad unit ID from DFP. Log into your account, locate the ad unit that targets the new line item, and look for a “Generate tags” button to the right of its name. Clicking that button will display a dialog with some options for the type of tag to generate:

Select “Mobile applications” in the Tag Type dropdown, and you’ll see the correct ad unit ID and ad unit size for your line item. Armed with those two pieces of info, you’re ready to start coding.

Place a PublisherAdView

DFP banner ads are displayed with the PublisherAdView class. It’s possible to create instances on the fly and add them to a layout programmatically, but the better practice is to define them in your XML layout files. Here’s an example element:

<com.google.android.gms.ads.doubleclick.PublisherAdView
    android:id="@+id/banner_ad"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    ads:adSize="320x50"
    ads:adUnitId="/1234567890/DemoAccount/BearRepellent"/>

Note the adSize and adUnitId attributes. These should be set to match the ad unit ID and size shown in the Generate Tags dialog. See our banner guide for more information about setting custom or multiple sizes.

Request an ad

With the PublisherAdView defined in your layout file, you just need to add a few lines of code to its corresponding Java class:

PublisherAdView adView = (PublisherAdView)findViewById(R.id.banner_ad);
PublisherAdRequest request = new PublisherAdRequest.Builder().build();
adView.loadAd(request);

PublisherAdRequest.Builder is a factory class that builds PublisherAdRequest objects. This example uses a simple, unmodified request, but there are a number of ways to add custom targeting, network extras, and test device information when building your own. See the targeting section of our banner guide for details.

Enjoy your line item

With the layout updated and request code in place, your app is ready to show an ad!

Feel free to use the code from this example in your own applications, and if you have any questions, come and see us on our forum.

Today we’re announcing the release of v7.0 of the Google Mobile Ads SDK! It’s listed as Google Play services (Rev. 23) in the Android SDK manager, and is available for download right now. Those of you using Android Studio can download Google Repository (Rev. 16) to get the latest Gradle artifacts. This release contains a number of stability and performance improvements, as well as some new features.

DFP developers can take advantage of two other new methods in PublisherAdRequest.Builder: addCustomTargeting and addCategoryExclusion.

Previously, developers had to add custom targeting information to a request by creating a Bundle and passing it to addNetworkExtrasBundle. This can now be done with a simple call to the addCustomTargeting method:

PublisherAdRequest newRequest = new PublisherAdRequest.Builder()
        .addCustomTargeting("some_key", "some_value")
        .addCustomTargeting("some_other_key", aListOfStringValues)
        .build();

The new addCategoryExclusion method makes setting a slot-level category exclusion label for a request just as straightforward:

PublisherAdRequest newRequest = new PublisherAdRequest.Builder()
        .addCategoryExclusion("some_unwanted_category")
        .addCategoryExclusion("some_other_unwanted_category")
        .build();

Another new feature is the setRequestAgent method that’s been added to AdRequest.Builder and PublisherAdRequest.Builder. Third party libraries that reference the Mobile Ads SDK should call this method to denote the platform from which the ad request originated. For example, if a third-party ad network called "CoolAds" mediates requests to the Mobile Ads SDK, it should call this method with "CoolAds":

AdRequest newRequest = new AdRequest.Builder()
        .setRequestAgent("CoolAds")
        .build();

This SDK release coincides with version 7.0 of Google Play services, which was recently announced on the Android Developer blog. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

When announcing version 7.0.0 of the Google Mobile Ads SDK for iOS, we mentioned that developers could roadblock creatives and prevent competing ads in mobile apps.

The launch of the roadblocks feature in version 7.0.0 had an unintended side effect for DFP reservations. By default, ad requests from the same device were getting frequency capped for 30 seconds unless the app called the updateCorrelator method between requests.

To restore the default behavior, we have rolled back the roadblocks feature. What this means is that updateCorrelator effectively does nothing in version 7.0.0. We will relaunch support for roadblocks and competitive exclusions in a future iOS SDK release after improving the feature to preserve the default behavior.

If you have any questions about this change, leave us a note on the forum.

Today we’re releasing v7.0.0 of the Google Mobile Ads SDK for iOS. For this release, we focused on making the SDK easier to use, including distributing it as a framework. We’re also showing our DFP publishers some love by launching new first-class APIs to support the common DFP features they’re already using with Google Publisher Tag. A detailed list of these and other changes can be found on our release notes page.

SDK as a framework

The SDK is being distributed as a framework in this release. This comes with the following benefits:

  • You only have to add one item to your project. No more worrying about adding headers separately!
  • The SDK automatically links frameworks it depends on. No more manually adding framework dependencies!
  • Classes that use the SDK can now automatically import the necessary headers files with a single line of code:
    @import GoogleMobileAds;
    Previously, you had to import header files separately.
    #import "GADBannerView.h"
    #import "GADBannerViewDelegate.h"
    #import "GADRequest.h"
    

If all that wasn’t awesome enough, we also removed the need to include the -ObjC linker flag in your project! Just drag in the library to start using it.

If you’re using CocoaPods, you automatically get all of these changes by referencing version 7.0.0 of the Google-Mobile-Ads-SDK podspec. Since this is a major release, make sure you update your Podfile to grab major version 7:

pod 'Google-Mobile-Ads-SDK', '~> 7.0'

Introducing new friendly DFP APIs

Version 7.0.0 also adds first-class support for custom targeting and category exclusions in a brand new DFPRequest object.

DFPRequest *request = [DFPRequest request];
request.customTargeting = @{
  @"gender", @"male"
};
request.categoryExclusions = @[@"cars", @"sports", @"pets"];

New to 7.0.0 is the ability to roadblock creatives and prevent competing ads in mobile apps. The SDK does this by adding an updateCorrelator method with similar functionality to the same method in GPT:

[DFPRequest updateCorrelator];

All subsequent DFP ad requests will use the new correlator value until the correlator is updated again. Requests with the same correlator are capable of being roadblocked, and will not serve competing ads.

For more information on the DFP API improvements, see the developer docs.

Dropping support for iOS 5

With this release, we are also dropping support for iOS 5. We’ve noticed that almost all users are running iOS 6 or higher, and dropping support for older versions means the library can take advantage of the newer iOS APIs and offer more stability for you and your users. The SDK now supports only iOS 6.0 and up.

Sounds great! Where can I download the SDK?

As always, the latest SDK can be found on our downloads page. If you have any technical questions about these updates, drop us a line on the forum.

Today, we’re excited to announce the launch of new Google Mobile Ads APIs as part of the Google Play services 4.1 update. The update includes:

  • Support for DoubleClick for Publishers (DFP), Search Ads for Apps, and DoubleClick Ad Exchange
  • A new location API

DoubleClick for Publishers

This release adds new DFP specific APIs to the com.google.android.gms.ads.doubleclick package. For example, you can use the new APIs to request a 320x50 banner ad from DFP as follows:

PublisherAdView adView = new PublisherAdView(this);
adView.setAdUnitId("MY_DFP_AD_UNIT_ID");
adView.setAdSizes(AdSize.BANNER);
LinearLayout layout = (LinearLayout) findViewById(R.id.mainLayout);
layout.addView(adView);
PublisherAdRequest request = new PublisherAdRequest.Builder().build();
adView.loadAd(request);

Check out the DFP docs for more examples on how to use the new DFP APIs. If you’re migrating from the old AdMob Android SDK to Google Play services, be sure to also consult our migration guide which summarizes implementation details for the new APIs.

Search Ads for Apps

Search Ads for Apps support has also been added in this release, with new APIs in the com.google.android.gms.ads.search package. A search ads banner request in Google Play services looks like this:

SearchAdView adView = new SearchAdView(this);
adView.setAdUnitId("MY_ADSENSE_ID");
adView.setAdSize(new AdSize(320, 60));
LinearLayout layout = (LinearLayout) findViewById(R.id.mainLayout);
layout.addView(adView);
SearchAdRequest request = new SearchAdRequest.Builder()
    .setQuery("flower")
    .build();
adView.loadAd(request);

Consult the Search Ads documentation for more information on how to customize your SearchAdRequest.

DoubleClick Ad Exchange

The latest release now supports DoubleClick Ad Exchange, which shares the same AdView and AdRequest classes with AdMob in Google Play Services:

adView = new AdView(this);
adView.setAdUnitId("MY_AD_EXCHANGE_ID");
adView.setAdSize(AdSize.BANNER);
LinearLayout layout = (LinearLayout) findViewById(R.id.mainLayout);
layout.addView(adView);
AdRequest request = new AdRequest.Builder().build();
adView.loadAd(request);

See the Ad Exchange documentation for more information on implementing Ad Exchange with the new library.

Location

We’ve added back the setLocation method to enable you to provide location to an ad request. Note that location should only be provided if your app already makes use of location.

Assuming you’ve grabbed location via a suitable method, you can pass the location when building an AdRequest:

Location location = … // get location.
AdRequest request = AdRequest.Builder().setLocation(location).build();

The new library can be downloaded from Android’s SDK manager. Consult the setup guide for detailed installation instructions. You can see a full list of changes on our release notes page.

Give us a shout on our forum with any questions or concerns about the release, and stay tuned on our G+ page for the latest updates (and maybe even a tips/tricks campaign!) on Google Mobile Ads APIs.

We have just released version 6.4.1 of the Google AdMob SDK for both Android and iOS. The Android release includes:

  • The ability to resize a DfpAdView using dfpAdView.resize(AdSize)
  • A fix for the ANR errors seen in v6.3

The iOS release fixes a crash that occurs if the Advertising Identifier is nil.

You can get the latest SDKs from our downloads page. Find us on the forum if have questions about the new Google AdMob SDKs. You can also check out our Google+ page for ads-related updates.


The next step is to have the application code listen for these app events. Here are the iOS and Android versions of this method, respectively:

// iOS
- (void)adView:(DFPBannerView *)banner
    didReceiveAppEvent:(NSString *)name
    withInfo:(NSString *)info {
  NSLog(@"Received app event (%@, %@)", name, info);
  // Checking for a "color" event name with information being a color.
  if ([name isEqualToString:@"color"]) {
    if ([info isEqualToString:@"red"]) {
      self.view.backgroundColor = [UIColor redColor];
    } else if ([info isEqualToString:@"green"]) {
      self.view.backgroundColor = [UIColor greenColor];
    }
  }
}

// Android
@Override
public void onAppEvent(Ad ad, String name, String info) {
  String message = String.format("Received app event (%s, %s)", name, info);
  Log.d(LOG_TAG, message);
  if ("color".equals(name)) {
    LinearLayout layout = (LinearLayout) findViewById(R.id.mainLayout);
    if ("red".equals(info)) {
      layout.setBackgroundColor(Color.RED);
    } else if ("green".equals(info)) {
      layout.setBackgroundColor(Color.GREEN);
    }
  }
}

Remember to register this callback on the banner view:

// iOS
[bannerView_ setAppEventDelegate:self];

// Android
adView.setAppEventListener(this);

That’s it! If you load this ad into your banner view, your application will change its background color to red when the ad is loaded, and green when the ad is clicked. This example can be extended to change the implementation of the app event listener or to fire app events at any point during the creative’s lifecycle.

Let us know on the forum if you have any questions about app events specifically or the Google AdMob SDK in general. You can also follow us on our plus page for AdMob-related updates.

Edit: Fixed plus page link.

App Events, a feature introduced in v6.1.0 of the AdMob SDK, provides DFP developers the ability to create ads that can send messages to their application code. The application can listen for and react to these messages by executing custom code.

This powerful feature lets you do some pretty cool things, such as sending the entire creative code to the app, or telling the app what ad is running. In this example, we’ll show how the app can change background colors when it receives an app event.

The first step is to set up your creative in DFP. The sample below is a 320x50 creative which sends a color=red event when the ad is first displayed, and a color=green event when the ad is clicked.

<html>
<head>
  <script src="//media.admob.com/api/v1/google_mobile_app_ads.js"></script>
  <script>
    // Send a color=red event when ad loads.
    admob.events.dispatchAppEvent("color", "red");
    
    handleClick = function() {
      // Send a color=green event when ad is clicked.
      admob.events.dispatchAppEvent("color", "green");
    };
  </script>
  <style>
    #ad {
      width: 320px;
      height: 50px;
      top: 0px;
      left: 0px;
      font-size: 24pt;
      font-weight: bold;
      position: absolute;
      background: green;
      color: red;
      text-align: center;
    }
  </style>
</head>
<body>
  <div id="ad" >Happy Holidays!</div>
</body>
</html>

The creative above references the AdMob API for Ads JavaScript, and calls admob.events.dispatchAppEvent to send app events. You can check out an example of the creative below, and view the developer console to see logging statements when the app events are being fired.


The next step is to have the application code listen for these app events. Here are the iOS and Android versions of this method, respectively:

// iOS
- (void)adView:(DFPBannerView *)banner
    didReceiveAppEvent:(NSString *)name
    withInfo:(NSString *)info {
  NSLog(@"Received app event (%@, %@)", name, info);
  // Checking for a "color" event name with information being a color.
  if ([name isEqualToString:@"color"]) {
    if ([info isEqualToString:@"red"]) {
      self.view.backgroundColor = [UIColor redColor];
    } else if ([info isEqualToString:@"green"]) {
      self.view.backgroundColor = [UIColor greenColor];
    }
  }
}

// Android
@Override
public void onAppEvent(Ad ad, String name, String info) {
  String message = String.format("Received app event (%s, %s)", name, info);
  Log.d(LOG_TAG, message);
  if ("color".equals(name)) {
    LinearLayout layout = (LinearLayout) findViewById(R.id.mainLayout);
    if ("red".equals(info)) {
      layout.setBackgroundColor(Color.RED);
    } else if ("green".equals(info)) {
      layout.setBackgroundColor(Color.GREEN);
    }
  }
}

Remember to register this callback on the banner view:

// iOS
[bannerView_ setAppEventDelegate:self];

// Android
adView.setAppEventListener(this);

That’s it! If you load this ad into your banner view, your application will change its background color to red when the ad is loaded, and green when the ad is clicked. This example can be extended to change the implementation of the app event listener or to fire app events at any point during the creative’s lifecycle.

Let us know on the forum if you have any questions about app events specifically or the Google AdMob SDK in general. You can also follow us on our plus page for AdMob-related updates.

Edit: Fixed plus page link.

We’re excited to announce the release of the AdMob SDK v6.2.0 for Android and v6.2.1 for iOS. The iOS update is mostly a bugfix release, but now requires you to link against the StoreKit framework, which will allow us to experiment with innovative ad experiences. The Android release includes changes to DFP App Events and Custom Events that we’ll discuss below.

DFP App Events

The Android AppEventListener interface has changed slightly to include the ad that fired the app event. The new interface definition is:

public interface AppEventListener {
  void onAppEvent(Ad ad, String name, String info);
}

If you previously implemented onAppEvent(String name, String info), you’ll have to update this method signature when upgrading to v6.2.0.

Custom Events

Due to popular demand, we’ve added the ability to pass information to your custom event. We’ve also added a destroy() method so you can clean up your custom event. The new CustomEventBanner interface definition is:

public interface CustomEventBanner extends CustomEvent {
  void requestBannerAd(CustomEventBannerListener listener,
                       Activity activity,
                       String label,
                       String serverParameter,
                       AdSize size,
                       MediationAdRequest mediationAdRequest,
                       Object customEventExtra);
  void destroy();
}
The customEventExtra object is sent to your custom event by creating an instance of CustomEventExtras and passing it to the AdRequest. The following example sends the string “hello custom event” to your custom event class:
final String CUSTOM_EVENT_LABEL = “MyCustomEventLabel”;
AdRequest adRequest = new AdRequest();
CustomEventExtras extras = new CustomEventExtras();
extras.addExtra(CUSTOM_EVENT_LABEL, "hello custom event");
adRequest.setNetworkExtras(extras);

When calling CustomEventExtras.addExtra(), make sure the key is the same as the label of the custom event you defined in the AdMob UI. The AdMob SDK searches CustomEventExtras for the object corresponding to the label of the custom event, and invokes requestBannerAd on your custom event class with that object. You can call addExtra() for each custom event class you have, and AdMob Mediation will send the appropriate object to the custom event it invokes. If AdMob can’t find an object for your custom event label, it will pass null to requestBannerAd().

A destroy() method has also been added to the custom event interface so you can perform any necessary cleanup. The AdMob Mediation framework will invoke destroy() when it refreshes the AdView.

Check out the release notes for the full list of changes in this version. If you have any questions about the latest AdMob SDK, please reach out to us on the forum or join us for AdMob office hours. You can also follow us on the Google Ads Developer plus page for AdMob-related updates.

At Google, we enjoy hearing from you, the developer community, and working with you to ensure that progress is being made. We think the latest DFP API release reflects positively on how we work better together and we're excited to announce version v201208. This release adds new types of creatives, support for optimization, rich media, and video interaction report columns, along with new options for downloading reports. A full list of improvements from this release can be found on our release notes page. We also want to remind you that we host virtual office hours via Google+ hangouts in order to make sure your voice is heard. Stay tuned to our Google Developers Live calendar to catch the next one on September 18th.

Reporting improvements

In v201208, we’ve added 64 new columns which enable you to pull metrics for optimization, rich media, and video. Using these new columns, you’ll now be able to better track performance of your network including determining the interaction time of your rich media (e.g. RICH_MEDIA_INTERACTION_TIME), locating videos which complete the most (e.g. VIDEO_INTERACTION_COMPLETE), or analyzing the revenue resulting from optimized impressions (e.g. OPTIMIZATION_OPTIMIZED_REVENUE). In addition to these columns, we’ve added the CREATIVE_TYPE dimension and the ability to include custom fields to help you better break down your reports.

For applications which cannot process gzip files, you can now download reports already deflated using the new ReportService.getReportDownloadUrlWithOptions method. If you choose to not use gzip compression, we still highly recommend that you set the HTTP header Accept-Encoding: gzip to speed up downloads. We’ve also added the ability to include report properties (e.g. network, user, generation date, etc...) and remove the totals row. If there are any other types of report download options you’d like to see, we’d love to hear about them on the forum.

Creative additions

For publishers who are using the cutting edge features of DFP, we’ve added support for four new creative types: AdSenseCreative, AdExchangeCreative, RichMediaStudioCreative, and AspectRatioImageCreative. AdSense and Ad Exchange creatives allow you to traffic line item level dynamic allocation ads by serving ad slot code snippets as the creative asset. Rich media studio creatives allow you to fetch creatives created using the DoubleClick rich media studio. Although these creatives are mostly used in a read-only manner (since they are created in the rich media studio and not DFP), some fields are mutable, such as the duration, any CSS overrides, and URLs. Finally, aspect ratio image creatives let you upload multiple image assets of the same aspect ratio to give you control of how images should be scaled; these creatives are mostly used in a mobile environment given the variety of screen sizes and resolution of today’s devices.

Last but not least

In our ongoing effort to bring the API up to parity with the UI, we’ve also added a number of smaller features. These include additional company partner types, the ability to set the mobile platform type on ad units, a friendly display string for inventory sizes, the option to associate line items with creative sets , and support for the recently released device category targeting criteria.

Our API and outreach efforts are constantly growing, but we can't do it without you. If there is anything you'd like to see us do better, please let us know or introduce yourself in the next Google+ hangout on September 18th.

 - , DFP API Team

Last week, we released AdMob SDK v6.1 for both Android and iOS. This SDK contains a number of important bug fixes and exciting new features including:


Additional DoubleClick support

DoubleClick publishers will be happy to know that AdMob now provides support for app events, giving them the ability to execute custom code in their application when a creative dispatches an app event. Additionally, the new SDK provides support for multiple ad sizes using the same banner.


Easy access to Google Analytics

You’ll notice we’ve included the latest Google Analytics package in the “Add-Ons” directory. The new mobile app analytics provides the same best-in-class Google Analytics reporting, but for mobile apps.


If you have any questions about the AdMob SDK, please let us know on the forum or hang out during our upcoming AdMob/DFP office hours. For more information about this new SDK, take a look at our release notes.


We would like to announce the release of the DFP Showcase application for iOS and Android, as well as v2 of the Ad Catalog project for Android.

DFP Showcase

DFP Showcase is a sample project that features the various creative types you can display in mobile applications with DoubleClick for Publishers (DFP) Mobile. DFP Mobile provides publishers the ability to set up campaigns with different ad types, and uses the Google AdMob Ads SDK to display the ads in mobile applications.

The DFP Showcase application features expandable ads, image animation, click to map, and more!


You can download DFP Showcase directly or clone the source code from the dfpshowcase-android or dfpshowcase-ios repositories.

Ad Catalog v2

We are pleased to announce the release of Ad Catalog v2 for Android. This new version shows examples of best practices for ad placement in four different types of layouts - TabView, ListView, OpenGLView, and ScrollView.


Here are some details about the implementation of these examples:

  • The TabView example makes use of Android’s v4 support library to implement fragments for tabs while maintaining support for Android 1.5 and higher.
  • The ListView example adapter was written to accept any type of list items, and will embed ads every kth item in the list provided.
  • The OpenGLView and ScrollView examples show how to dock an ad to the top or bottom, but outside the content on the screen.

You can get v2 of the Ad Catalog by downloading a zip file from the google-mobile-dev download page or by cloning the source code.

Have any questions, comments, or feature requests for the DFP Showcase or Ad Catalog projects? Let us know on the forum, or join us during office hours! Also, stay tuned for the release of Ad Catalog v2 for iOS.