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:

If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

AdMob mediation needs two classes to maintain their original names in your final APK: AdUrlAdapter and AdMobAdapter. If either of those has been renamed by ProGuard, it can cause the SDK to incorrectly return “no fill” responses for the AdMob demand in your mediated ad units.

The good news is that it’s easy to avoid this problem. Just add the following two keep options to your ProGuard configuration file:

-keep class com.google.ads.mediation.admob.AdMobAdapter {
    *;
}

-keep class com.google.ads.mediation.AdUrlAdapter {
    *;
}

These options instruct ProGuard to avoid renaming the two classes, and to leave the names of their fields and methods unobfuscated as well. With the original names intact, the mediation system will be able to instantiate them dynamically whenever they’re needed, and your otherwise obfuscated application won’t miss out on any AdMob impressions.

The third-party networks your app mediates may also need certain classes exempted from obfuscation. Be sure to check with those networks to find out if they have recommendations for ProGuard configuration.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

tags: android, admob_mediation, mobile_ads_sdk

Posted:

Smart banners are a handy thing for publishers. You can drop an AdMob smart banner into a layout or storyboard, and it’ll stretch or squeeze itself at runtime until it’s just the right size for the device, then request an ad to match. They’re a great feature with all the extra work hidden under the hood.

If you’re building an Android mediation adapter or custom event, though, things aren’t quite as simple -- after all, you’re under that hood, too! A common rough spot for developers is retrieving a smart banner’s size. Because the Google Mobile Ads SDK uses constants to internally represent a smart banner’s height and width, the getHeight and getWidth methods of a smart banner’s AdSize will return those constants (they’re negative numbers, so they’re quite hard to miss). That means relying on calls to getHeight and getWidth to determine a smart banner’s true size isn’t a workable strategy.

So how should adapter and custom event developers calculate sizes correctly? By avoiding getHeight and getWidth, and instead asking for pixel counts using getHeightInPixels and getWidthInPixels, two other methods offered by AdSize. You can scale their return values according to the device’s metrics and end up with the same kind of DPI values returned by getWidth and getHeight for other ad sizes. Here’s a code snippet that shows how it’s done:

// Get the raw pixel counts.
int widthInPixels = size.getWidthInPixels(context);
int heightInPixels = size.getHeightInPixels(context);

// These metrics include screen density, which is what we’re after.
DisplayMetrics displayMetrics = Resources.getSystem().getDisplayMetrics();

// These are values you can send to your mediated network’s SDK.
int widthInDpi = Math.round(widthInPixels / displayMetrics.density);
int heightInDpi = Math.round(heightInPixels / displayMetrics.density);

Once you finish the math, you’ll have proper DPI values that can be sent to whichever network you’re mediating. The calls to getHeightInPixels and getWidthInPixels require a valid Context, but you can use the one provided as a parameter to the requestBannerAd methods in MediationBannerAdapter and CustomEventBanner.

Now you know the best way to gauge the size of a smart banner! Use this approach and it’ll help keep your mediation running smoothly.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

Posted:

Today we’re announcing two new versions of the Google Mobile Ads SDK: version 7.8 for Android, and version 7.4.1 for iOS. Those of you using Android Studio can download Google Repository (Rev. 20) to get the latest Gradle artifacts. Eclipse developers will find it listed as Google Play services (Rev. 26) in the Android SDK manager. Publishers with iOS apps can get the latest SDK for that platform by updating their CocoaPods Podfile to pull version 7.4.1 or by downloading it manually. These releases contain a number of stability and performance improvements, as well as some new features — including beta support for MRAID v2.0 on iOS and Android!

MRAID v2.0 Beta

MRAID v2.0 offers a number of new methods that advertisers can use to improve their creatives. Ads using the new standard can store photos, resize themselves on the fly, query screen dimensions, and make calendar events using calls like this:

mraid.createCalendarEvent({
    description: “A big sale at our store!”,
    location: ‘123 Savings Street’,
    start: ‘2015-9-01T09:00-05:00’, 
    end: ‘2012-12-22T10:00-05:00’
});

The new standard creates some great opportunities for increased engagement, so for more info about MRAID, see our iOS MRAID guide, our Android MRAID guide, or the IAB’s specifications document.

Checking ad loading status on Android

In the new Android release, we’ve added an isLoading method to the AdLoader, AdView, and InterstitialAd classes so publishers can check whether an ad request is in progress. If you’re using an AdLoader to fetch a native ad, for example, you can use a call like this to see if the request has completed:

if (!myAdLoader.isLoading()) {
    /* The AdLoader isn’t busy making a request. */
    myAdLoader.loadAd(new AdRequest.Builder().build());;
}

iOS global settings

This SDK release introduces the GADMobileAds class, which provides global settings for controlling certain information collected by the SDK. In-app purchase reporting and crash reporting are enabled by default. However, if you’d like, you can disable these settings in most instances by using the disableAutomatedInAppPurchaseReporting and disableSDKCrashReporting methods. See the global settings guide for more information.

For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

Posted:

We’re excited to announce the v2.3.0 release of the Google Mobile Ads Unity Plugin! The new release brings support for AdMob in-app purchase ads to the Unity game engine. You can grab the updated Unity package on GitHub.

In-app purchase ads in Unity with AdMob

In-app purchase (IAP) ads are interstitial ads that display offers for your in-app products. They allow users to make purchases directly from within your app as part of your normal ad flow.

Note: The plugin currently only supports IAP ads on Android. iOS support is not yet available.

Before integrating IAP ads into your app, make sure you’ve set up an IAP house ad campaign and created an IAP house ad. You should also install the plugin as explained in the AdMob Unity Quick Start guide.

Once you’ve set up your campaign, there are five steps to integrate IAP ads:

  1. In the AndroidManifest.xml in Assets/Plugins/Android/GoogleMobileAds/Plugin, uncomment the following line to enable billing permissions:
    <!--<uses-permission android:name="com.android.vending.BILLING"/> -->
  2. Create a class that implements the IInAppPurchaseHandler interface. See GoogleMobileAdsDemoScript.cs for an implementation example. You need to define the following methods:
    1. OnInAppPurchaseFinished -- here you credit the user with the purchase, and then call result.FinishPurchase() to finish the transaction.
    2. IsValidPurchase -- check the SKU against valid SKUs and return true if this purchase is valid.
    3. AndroidPublicKey { get; } -- return the public key for your Android app, which you obtain from the Google Play console.
  3. Pass in the above implementation of IInAppPurchaseHandler to InterstitialAd.SetInAppPurchaseHandler.
  4. Make sure you request an in-house IAP ad by setting the correct adUnitId when creating the InterstitialAd. See In-App Purchase Overview for detailed instructions on how to set up IAP house ads in your AdMob account.
  5. Add the Conversion Tracking and Remarketing SDK to the Plugins/Android directory.

That’s it!

An example IAP ad.

If you have any questions, please drop by our forum.

Posted:

Today we’re announcing the availability of three new reporting dimensions created specifically for AdMob publishers: APP_ID, APP_NAME, and APP_PLATFORM.

Here’s how they work:

  • APP_ID - This dimension matches the store ID of an application. It will be prefixed with “1:” for an App Store ID (iOS) and “2:” for a Google Play ID (Android). For example, “1:476954712” or “2:com.labpixies.lineup”.
  • APP_NAME - Matches the name of an application, like “Flood-It!” or “Line Up”.
  • APP_PLATFORM - This dimension can partition results by platform (e.g. “Android” or “iOS”).

These new dimensions are available now in the AdSense Management API. If you’re unfamiliar with it, the AdSense Management API is a web-based API that you can query to get information about your AdSense account. There are client libraries for a number of platforms, though any standard HTTP client can send requests to it and parse the responses. With a little code and these new dimensions, you can create custom reports about a single app, a family of them, or even your entire platform lineup!

For more information on building and customizing AdMob reports, check out the reporting section of the AdMob developer site. You can also use the API Explorer to test out queries that include these fields.

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:

As you know, interstitials are a great way to monetize your app while still providing a great user experience, with natural "commercial breaks" in your user flow. However, interstitials can take a while to load, and we know that this can make it tricky to implement since you must explicitly call loadAd() before calling show().

A common mistake is to call interstitial.show() in the onAdLoaded() callback. This makes the show() call not dependent on the app state, but on the asynchronous loading. Since the developer doesn't control when the onAdLoaded() callback happens, this provides a terrible user experience; the ad will show as soon as it's finished loading, which could be in the middle of another user interaction. This can result in policy violations due to accidental clicks.

Instead, we recommend loading the ad earlier in the lifecycle of the application, then polling interstitial.isLoaded() to see if the ad is ready to be shown. If it isn't ready, we recommend moving to the next state in the application.

We provide an example of proper interstitial loading in our sample "Impossible" game. When the game begins, we call loadAd() on the interstitial. When the user loses and clicks the button to try the game again, we check to see if the ad is loaded with isLoaded(). If it is, then we show an ad before starting the new round. Otherwise, we show a toast message that the ad isn't loaded and begin a new round.

This example focuses on the Android experience, but the same ideas apply to iOS. We hope our new interstitial example can help you create the best user experience as you integrate the Mobile Ads SDK into your apps. Check out this video for more on interstitial best practices. And as you're adding interstitials to your app, hit us up with technical questions on our developer forum!

Posted:

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

  1. Split JAR Architecture

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

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

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

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

  2. Shrink Resources

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

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

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

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

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

Posted:

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

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

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

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

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

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

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

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

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

Posted:

Greetings developers!

We're happy to launch a new version of our Google Mobile Ads SDK for Android. You should see Google Play Services 6.1 (rev 20) available for download in your SDK manager.

This version includes the following changes:

  • Added a getLocation method to com.google.android.gms.ads.MediationAdRequest.
  • Added a content description for the interstitial close button.
  • Removed logging of "Google Play resources not found" when the library project is linked correctly.
  • Added getMediationAdapterClassName to AdView for getting the class name of the ad network mediation adapter currently showing an ad.

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

Posted:
We're enthused to announce a new version of our Mobile Ads SDK for Android.

Our big change for this version are our new Custom Event APIs. After updating our mediation APIs in our last release, Custom Events were up for a refresh. Our new-and-improved Custom Event APIs make it even easier to implement your own mediation adapter or show a custom view in your ad space.

Remember that after August 1st the Play Store will no longer accept submissions using the legacy SDK, so please update your apps to use the latest version of Google Play Services.

For a full list of SDK changes, check out our release notes. For technical questions, post them on our forum. We're stoked about these improvements, and hope you find them useful!

Posted:

Summary: Legacy AdMob will sunset August 31st, 2014. The Google Play store will not accept apps using the legacy SDK after August 1st, 2014. Please update.

Greetings AdMob Developers!

We're pleased to announce we've completed the rollout of the new AdMob to over 200 countries. AdMob is now a complete platform for developers to monetize, promote and analyze their apps, with Google Analytics directly available in the AdMob interface. We hope you enjoy the new features it provides, including ad network optimization and simplified mediation. You can read more about the new features and changes in this help center doc.

Since the new AdMob is now available to everyone, we’re beginning our deprecation of the legacy AdMob, and will be sunsetting the old platform on August 31st, 2014. After August 31st:

  • Ads will stop serving to legacy ad units
  • Legacy house ad campaigns will stop serving
  • The legacy AdMob UI will be inaccessible

Please upgrade to the new AdMob as soon as possible - and definitely before the end of August. If you encounter difficulties, please see the help docs and support forms in our Help Center.

We also want to remind you that after August 1st, 2014, the Google Play Store will no longer accept apps using the legacy AdMob SDK. If you're an Android publisher, you should migrate to Google Play Services as soon as possible. We have plenty of resources for you including our migration guide and intro video - and if you still need help, please ask your technical questions on our forum.

We hope that you're as excited about the evolution of AdMob as we are!

Posted:

When you make an ad request using the Google Mobile Ads SDK, you’re probably setting an AdListener or GADBannerViewDelegate to listen for ad events. The click events for these listeners are slightly different on Android and iOS, so today we’ll take a deeper look at what events get invoked when an ad click:

  • opens an overlay, for example an in-app browser
  • launches an external application, for example an external browser or app store

Ad Opens an Overlay

Here are the ad events that get called when an ad opens an overlay:

Event Android Callback(s) iOS Callback(s)
Ad Opens Overlay
onAdOpened
adViewWillPresentScreen
Ad Overlay is Closed
onAdClosed
adViewWillDismissScreen
adViewDidDismissScreen

These events are pretty straightforward. When the ad overlay opens, you get a single callback. When the ad overlay closes, Android notifies you the moment the event happens, while iOS notifies you right before and after the event happens.

Ad Launches an External Application

When an ad launches an external application, the ad events are slightly different:

Event Android Callback(s) iOS Callback(s)
Ad Launches External App
onAdOpened
onAdLeftApplication
adViewWillLeaveApplication
User relaunches App
onAdClosed
-----

Notice how on Android you still get the onAdOpened and onAdClosed events even if an ad leaves an application. But on iOS, the adViewWillPresentScreen and adViewWillDismissScreen/adViewDidDismissScreen events are only invoked when presenting and dismissing modal views.

So how do you know when the user returns to your iOS app? You can listen for the applicationWillEnterForeground delegate method that iOS provides.

Testing The Different Click Behaviors

Hopefully you’re already requesting test ads during application development. If you’re making test requests, you should already see these ads showing up in your development environment:



On iOS, you can use these ads to test both ad click behaviors. If you click the banner, the Google Mobile Ads SDK will launch an external web browser and call adViewWillLeaveApplication. If you click the icon in the bottom-left corner of the ad, the SDK will launch an overlay and adViewWillPresentScreen will get called.

Hopefully this clears up any confusion regarding any ad click events. If you have any additional questions, we’ll field them on our forum. You can also find us on Google+.

Posted:

Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.

In-App Purchase Ads

In this release we’ve added SDK-level support (front-end support coming soon!) for running house ads that can initiate an in-app purchase. In-app purchase ads require that you set an in-app purchase listener on your interstitial ad. If an in-app purchase ad is shown, it will present the user with an option to buy one or more items that you have configured:

When the user clicks Buy now, the SDK will invoke your in-app purchase listener with the purchase information necessary to start a transaction for that product. You are responsible for implementing the in-app purchase flow from this point. Full implementation details can be found in our Android and iOS documentation.

Note: Front-end support for this feature is not available yet, but is coming soon.

New Mediation APIs

As part of our Google Play services API revamp, we’ve added new mediation APIs (which we’re calling mediation v2) to make it easier for ad networks to create mediation adapters.

Don’t worry! We’re still supporting mediation adapters written against mediation v1 APIs. This change won’t require any immediate updates to your apps.

If you previously passed extra parameters to third party networks, note that this process has changed for mediation v2. You’ll now pass a bundle to the ad network, keyed by its mediation v2 adapter class. Here is an example of passing extra parameters to AdMob:

Bundle adMobBundle = new Bundle();
adMobBundle.putString("color_bg", "AAAAFF");
AdRequest request = new AdRequest.Builder()
    .addNetworkExtrasBundle(AdMobAdapter.class, adMobBundle)
    .build();

You can also use this snippet to check for the existence of mediation v2 support. If this snippet compiles, then the adapter supports mediation v2. If there is a compilation error saying that the arguments don’t match the arguments for addNetworkExtrasBundle(Class, Bundle), then that adapter class does not support mediation v2.

See the documentation for more information on passing parameters to mediation v2.

Dropped Support for iOS 4.3

The 6.9.2 iOS SDK release has dropped support for iOS 4.3. By dropping iOS 4.3, the SDK can take advantage of automatic reference counting (ARC) weak references to provide a more stable release. The SDK still supports iOS 5.0 and above.

Check out the downloads page to grab the latest iOS release. A new Google Play services revision will soon be available in Android’s SDK Manager.

For a full list of SDK changes, see the release notes. If you have any technical questions about these changes, we’re available on the forum. Finally, stay tuned for an update on front-end support for in-app purchase ads on our Google+ page.

Posted:

Update (March 24, 2015): Per recent policy updates, interstitial ads on app-load are not recommended. See the AdMob help center for the latest interstitial policy guidance.

Previously, we showed you how to create a splash screen interstitial on iOS. Today we’ll discuss how to trigger an interstitial on an Android app launch.

The cleanest solution is to have an app launch Activity for showing the splash screen image and loading/showing the interstitial. This special splash screen activity should be the activity that launches when the user starts the app. In the splash screen activity’s onCreate method, the first task is to make an ImageView and set it as the content view.

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  ImageView image = new ImageView(this);
  // Assumes you have a resource with the name kitten.
  image.setImageResource(R.drawable.kitten);
  setContentView(image);

Next, create and load the interstitial ad. Setting an AdListener is needed in order to know when the ad succeeds or fails to load. If the interstitial loads within a reasonable time limit, we’ll show it. If it fails, we’ll move on to the main activity.

  interstitial = new InterstitialAd(this);
  interstitial.setAdUnitId(AD_UNIT_ID);
  interstitial.setAdListener(new AdListener() {
    @Override
    public void onAdLoaded() {
      if (!interstitialCanceled) {
        waitTimer.cancel();
        interstitial.show();
      }
    }

    @Override
    public void onAdFailedToLoad(int errorCode) {
      startMainActivity();
    }
  });

The “reasonable time limit” mentioned earlier is enforced by creating a timer to stop waiting for the interstitial. If the interstitial doesn’t load fast enough (in this case 5 seconds), we skip it and proceed to the main activity.

  waitTimer = new Timer();
  waitTimer.schedule(new TimerTask() {
    @Override
    public void run() {
      interstitialCanceled = true;
      SplashScreenActivity.this.runOnUiThread(new Runnable() {
        @Override
        public void run() {
          startMainActivity();
        }
      });
    }
  }, 5000);
} // end of onCreate implementation.

private void startMainActivity() {
  Intent intent = new Intent(this, MainActivity.class);
  startActivity(intent);
  finish();
}

Handing Early Exits

The code so far assumes that the user will stay in the activity for the duration of the interstitial loading. But what if the user hits the back or home button before the interstitial loads or the timer goes off? The interstitial will actually continue loading and could be shown on top of the home screen! That would be a poor user experience.

We account for this edge case by implementing the onPause and onResume methods from the activity lifecycle. In onPause, we stop the timer and set the interstitialCanceled flag so the interstitial doesn’t get immediately shown. In onResume, we show the interstitial if it’s ready when the user returns to the app again, otherwise we start the main activity.

@Override
public void onPause() {
  waitTimer.cancel();
  interstitialCanceled = true;
  super.onPause();
}

@Override
public void onResume() {
  super.onResume();
  if (interstitial.isLoaded()) {
    interstitial.show();
  } else if (interstitialCanceled) {
    startMainActivity();
  }
}

If you’re wondering why interstitialCanceled is checked again before starting the main application, it’s because onResume gets called immediately after onCreate the first time the app is loaded. And on the first app launch, we do want to wait for the interstitial to load.

A complete implementation is available in our googleads-mobile-android-examples repo on GitHub. Give us a shout on the forum if you have any questions about implementing the Google Mobile Ads SDK in your mobile applications. You can also find us on Google+.

Posted:

Calling all Unity app developers! We are excited to announce the launch of version 2.0 of the Google Mobile Ads Unity Plugin. The new version comes with a completely rewritten, but much more flexible, API. It includes the following new features:

  • A single package supporting both Android and iOS
  • Support for running apps in the Unity editor
  • Ability to create multiple banner instances
  • Ability to create banners of any size
  • Flexible ad request targeting
  • and much more!

Taking a closer look at how to integrate the plugin, a typical banner request in v2.0 looks like this:

BannerView bannerView = new BannerView(
    "YOUR_AD_UNIT_ID", AdSize.Banner, AdPosition.Top);
AdRequest request = new AdRequest.Builder().Build();
bannerView.LoadAd(request);

For custom banner sizes, simply pass in an AdSize object into the BannerView constructor:

AdSize adSize = new AdSize(250, 250);
BannerView bannerView = new BannerView(
    "YOUR_AD_UNIT_ID", adSize, AdPosition.Top);

Want to pass additional targeting parameters? No problem! Set your custom targeting when building the AdRequest:

AdRequest request = new AdRequest.Builder()
        .AddTestDevice(AdRequest.TestDeviceSimulator)
        .AddTestDevice("0123456789ABCDEF0123456789ABCDEF")
        .AddKeyword("unity")
        .SetGender(Gender.Male)
        .SetBirthday(new DateTime(1985, 1, 1))
        .TagForChildDirectedTreatment(true)
        .Build();

Listening for ad events is also extremely straightforward. Register for the callbacks you care about:

bannerView.AdLoaded += HandleAdLoaded;
bannerView.AdFailedToLoad += HandleAdFailedToLoad;
bannerView.AdOpened += HandleAdOpened;
bannerView.AdClosing += HandleAdClosing;
bannerView.AdClosed += HandleAdClosed;
bannerView.AdLeftApplication += HandleAdLeftApplication;

…

public void HandleAdLoaded()
{
    print("HandleAdLoaded event received.");
}

You can also manage the lifecycle of each BannerView by calling show(), hide(), or destroy().

To get access to these awesome features, check out the source code. Also stay tuned for upcoming support for interstitial ads.

If you have any feature requests or bug reports against the plugin, track it! If you have questions about how to use the plugin, speak up! And if you just want the latest news on what’s going on in the wonderful world of Google Ads, circle us!

Posted:

The new Google Mobile Ads SDK for Android is now included as part of Google Play services 4.0.

As an Android developer, you’re probably familiar with Google Play services, a unified platform which makes it easy to integrate Google features into your Android apps, delivered through the Play Store and updated at regular intervals. Now that AdMob is part of the package, benefits include:

  • Seamless auto-updates: Changes to the Google Mobile Ads SDK for Android get pushed seamlessly to users through Google Play services. For most SDK updates you don’t need to update your apps each time it changes, saving you development time.
  • Take advantage of Google services: Implement features easily into your apps, such as Google Maps, Google Wallet and the Location API.
  • Better for users: Android users are saved the hassle of managing updates to multiple apps, because improvements can be received automatically in the background.

This new version of Google Play services supports devices running Android 2.3 and higher. We recommend updating your apps right away to make ongoing maintenance of your apps easier. Even if you develop for Android devices that don’t receive Google Play services, the Google Mobile Ads SDK is still compatible with those devices, the difference is that users won’t receive automatic updates. Also, please note, the SDK doesn’t currently support DFP, Ad Exchange or Search Ads for Mobile Apps but support is coming soon.

You can find the new SDK in the SDK Manager; follow these instructions to get it, and find the release notes here. If you have questions about it please post to the forum or check out our G+ page.

Posted by Vishay Nihalani, Product Manager, AdMob