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.

 - Andrew Brogdon, Mobile Ads Developer Relations

The rollout of iOS 9 is expected to come this Fall and will introduce a new privacy feature called App Transport Security (ATS) to enforce best practices in secure connections between an app and its back end. This change may need your action if you are developing with the Google Mobile Ads SDK and building an app against the iOS 9 SDK.

We recommend using HTTPS exclusively if you’re developing a new app. If you’re working on an existing app, we suggest using HTTPS as much as possible and creating a plan to migrate the rest of your app toward ATS compliance.

All iOS 9 devices running apps built with Xcode 7 that don’t disable ATS will be affected by this change. The following log message appears when a non-ATS compliant app attempts to serve an ad via HTTP on iOS 9:

“App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.”

While Google remains committed to industry-wide adoption of HTTPS, there isn’t always full compliance on third party ad networks and custom creative code served via our systems. To ensure ads continue to serve on iOS9 devices for developers transitioning to HTTPS, the recommended short term fix is to add an exception that allows HTTP requests to succeed and non-secure content to load successfully.

Publishers can add an exception to their Info.plist to allow any insecure connection:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

If you have any questions regarding these changes, feel free to contact us through our forum.

Update (8/27/2015): We've received important feedback about this post and wanted to clarify a few points. We wrote this because developers asked us about resources available to them for the upcoming iOS 9 release, and we wanted to outline some options. To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.

We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products.

 - Tristan Emrich, Mobile Ads Developer Relations

In response to the growing popularity of Swift development, we’ve added Swift samples for the Google Mobile Ads SDK to our GitHub repo. To make it easier for developers to get started using Swift, we’ve also added Swift code snippets to our Get Started and Interstitial guides.

If you have any questions about using Swift with the Google Mobile Ads SDK, you can reach us on our forum. Remember that you can also find us on Google+, where we post updates on all of our Google Ads developer products.

 - Ram Parameswaran, Mobile Ads Developer Relations

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.

 - Andrew Brogdon, Mobile Ads Developer Relations

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.

 - Yury Pavlotsky, Mobile Ads Team

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.

 - Andrew Brogdon, Mobile Ads Developer Relations

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.

 - Andrew Brogdon, Mobile Ads Developer Relations

We have launched the Google Mobile Ads Unity Plugin v2.2.1. The updated v2.2.1 Unity package is available for download on GitHub here.

Multiple ad positions

Google Mobile Ads Unity Plugin v2.2.1 introduces support for additional banner position locations. The full list of banner positions is as follows:

• Top
• Bottom
• TopLeft
• TopRight
• BottomLeft
• BottomRight

The additional positions are specified by setting the AdPosition value when instantiating a bannerView:

//Create a banner at the top-right of the screen.
BannerView bannerView = new BannerView(adUnitId, AdSize.Banner, AdPosition.TopRight);

iOS Ads SDK 7.0.0 Compatibility

With the v7.0.0 release, the iOS Ads SDK became a module framework and Google Mobile Ads Unity Plugin v2.2.1 complies with this change. For modules to work, you must enable them in the project build settings. Search for "modules", and set Enable Modules to YES. The Link Frameworks Automatically option should be set to YES as well.

Unity 5.0 and ARC

Unity 5.0 has moved out of beta and brings with it support for Automatic Reference Counting (ARC) for iOS. v2.2.1 of the Unity plugin takes advantage of ARC with no additional changes in project settings or code.

The source code and a sample app for the plugin are available on our GitHub repo. A changelog for this release is listed here. If you have any questions about Unity integration, you can reach us on our forum. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.

 - Ram Parameswaran, Mobile Ads Developer Relations

A few weeks back we hosted a workshop for the Display Ads APIs and SDKs where we gave presentations on the DFP API, IMA SDK, and Mobile Ads SDK. If you weren’t able to attend, or want a refresher on something you saw that day, you can check out our presentation videos and slides. If you have any questions about those videos, feel free to ask on our respective forums:

• DFP
• IMA
• Mobile Ads

 - Shawn Busolits, IMA SDK Team

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.

 - Andrew Brogdon, Mobile Ads Developer Relations

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.

 - Andrew Brogdon, Mobile Ads Developer Relations