Tag Archives: mobile_ads_sdk

Announcing version 7.0.0 of the Google Mobile Ads SDK for iOS

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.

Mobile Ads SDK Interstitial Best Practices

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!

Reducing Google Play services’ impact on APK size

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.

Announcing v6.5 of the Google Mobile Ads SDK for Android

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.

Monetize your Cocos2d games with AdMob

With more than $1 billion paid to app developers in the last two years, AdMob is committed to supporting industry growth. So we are happy to announce that Cocos2d developers can now easily monetize their games with AdMob!

AdMob has integrated with the AnySDK platform, which means Cocos2d developers who use the AnySDK Ads System can now easily include AdMob when publishing their Android and iOS apps. If you haven’t checked out Cocos2d before, you can learn more here.

Getting started with the AnySDK Framework and AdMob

  1. If your app isn’t already integrated with AnySDK, download the AnySDK Framework.
  2. Follow the getting started guide to import the framework.
  3. Update your app to integrate the AnySDK Ads System. AdMob supports the AD_TYPE_BANNER and AD_TYPE_FULLSCREEN ad types. The games guide discusses the calls that are relevant for AdMob.
  4. Use the AnySDK package tool so specify AdMob as your desired ad system.

AnySDK package tool

Once you’ve configured your app for ads, the AnySDK package tool is where the magic happens. In the SDK Management section of your app configuration, specify AdMob as your ad provider.

In the Parameter Config section, configure your ad unit IDs for banners and/or interstitials, as well as the size and position for banner ads.

When you reach the Publishing section, simply Browse for your app and select Start.

That’s it! This step will generate the new version of your app with AdMob included!

Where to get help

For help integrating AnySDK into your apps, consult the contact link on AnySDK’s homepage.

We’d also love to get your feedback! Please let us know your experience integrating AdMob into your Cocos2d apps on our developer forum.

Launching v6.1 of the Google Mobile Ads SDK for Android

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.

Launching v6.12.0 of the iOS Mobile Ads SDK with iOS 8 Support

Today, we’re happy to announce the launch of Google Mobile Ads SDK v6.12.0 with support for iOS 8. Specifically, it includes the following iOS 8 updates:

  • Less time is spent on the main thread while loading ads
  • Smart Banner ads are displayed correctly in landscape

New Framework Dependencies

Version 6.12.0 also requires that your app link to two additional frameworks:

  • EventKit
  • EventKitUI

If you’re using CocoaPods, simply run pod update to grab the update, and these new frameworks will be automatically linked for you. If you’re not using Cocoapods, the getting started guide has the full list of required frameworks.

See the release notes for a full list of updates. You can grab the latest SDK from the downloads page. If you have any technical questions about the new release, post them on the developer forum. Also follow our Google+ page to keep abreast of the latest developments for the Mobile Ads SDK.

Announcing New Google Mobile Ads SDK for Android

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!

Legacy AdMob Sunset and Legacy SDK Deprecation Reminder

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!

Google Mobile Ads SDK – A Note on Ad Click Events

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+.