Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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.

Posted:

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" onClick="handleClick()">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.

Posted:

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.

Posted:
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

Posted:

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.


Posted:

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.