Version 12.0.0 of the Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

Updated Swift APIs

We’ve updated the Google Mobile Ads SDK to define an NS_SWIFT_NAME for every API to follow the naming conventions from Apple’s Swift API Design Guidelines. For example, we have:

Ad inspector empowers you to thoroughly test all your ad sources before releasing those changes to your users so you can verify everything is working properly. To help you understand and utilize ad inspector effectively, we published a 7-part ad inspector video series on our Google AdMob YouTube channel.

Each video focuses on a specific challenge in testing your ad integration, offering in-depth tutorials and demonstrations on how to:

Check out our ad inspector documentation (Android, iOS, Unity, Flutter) to learn more. If you have questions, comments, or general feedback about ad inspector, contact us in the developer forum. And remember to subscribe to our Google AdMob YouTube channel for more technical content.

How does the change apply to existing versions?

Effective today, Android v19 and iOS v7 versions are considered deprecated. In accordance with the schedule above, we plan to sunset Android v19 and iOS v7 versions in Q2 2023 following the releases of Android v22 and iOS v9 planned for Q1 2023. We will provide more specific sunset dates following the releases of Android v22 and iOS v9.

The graphic below helps visualize the state of existing Google Mobile Ads SDK versions for Android and iOS with today’s announcement.

Note: Versions 6.x.x and below for both Android and iOS have been sunset since 2018.

Exceptions

The deprecation schedule provides a framework for predictable lifetimes for an SDK version. However, there may be exceptions in the future. This schedule does not preclude us from sunsetting an SDK version at an earlier date, but we are committed to providing proactive communication with ample lead time for any future changes.

Next Steps

  1. Refer to the deprecation developer pages (Android | iOS) for the latest updates to the deprecation schedule. If you are on a deprecated version, see the Android migration guide or iOS migration guide for more information on how to update.
  2. Stay tuned for future updates to this blog, where more specific sunset dates will be communicated once new major Google Mobile Ads SDK versions are released.

If you have any questions about this announcement, please reach out to us on the Google Mobile Ads SDK Developer Forum.

You can then create Ad GameObjects that reference these Ad Placements entirely from the Unity Editor, which means no need for additional scripts!

Developers don’t need to write code to manage the ad unit. Callback functions and ad unit creation are all managed directly in the Unity UI.

Why use Ad Placements?

We’ve developed Ad Placements to help address the feedback that many of you have shared, which is integrating the Google Mobile Ads Unity plugin APIs requires too much scripting. Now with Ad Placements and their associated Ad GameObjects, implementing Google Mobile Ads into your Unity games should be a lot easier and more intuitive. You can add placements, load ads and show them all from easy-to-use Unity Editor integrations. With this new UI-driven approach, we can help you insert ad placements into your game with almost no additional code.

How do I get started?

See the Ad Placement documentation for a download link to the early access build and instructions to help you get started.

As always, please reach out on our developer forum if you have any questions.

The screenshot above shows an ad response ID in Android Studio logcat.

If you use Firebase, you can refer to the Firebase Crashlytics Android (AdMob, Ad Manager) or iOS (AdMob, Ad Manager) guide for logging the ad response ID. This technique can be useful for debugging production app crashes as you would have both the SDK symbols and the ad response ID data in the same log.

We hope this new feature makes it easier to troubleshoot ad issues.

If you would like to give us feedback on this feature, please post your comments and questions on our Google Mobile Ads SDK Technical Forum.

Standard banner vs. smart banner vs. AdMob’s adaptive anchor banner


Migrating your banner implementation to adaptive

Here are a few simple steps to update your banner implementation to use adaptive banners:

  1. Ensure your UI supports a variable height banner. Depending on what constraints or layout mechanism you are using to position your banner, you may need to remove height constraints such that the layout accepts variable content size.
    • For Android this can be done using WRAP_CONTENT.
    • For iOS constrain your banner in terms of X and Y positions, you may also give it a width constraint, but ensure any height constraint or content size is placeholder only.

    Note that the max height is 15% of the device height or 90px, whichever is smaller.

  2. Use the adaptive banner ad size APIs to get an adaptive ad size. The adaptive ad size APIs are available for different orientations.

    Android:
    AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(context, width)
    AdSize.getPortraitAnchoredAdaptiveBannerAdSize(context, width)
    AdSize.getLandscapeAnchoredAdaptiveBannerAdSize(context, width)

    iOS:
    GADCurrentOrientationAnchoredAdaptiveBannerAdSizeWithWidth(width)
    GADPortraitAnchoredAdaptiveBannerAdSizeWithWidth(width)
    GADLandscapeAnchoredAdaptiveBannerAdSizeWithWidth(width)

    Unity:
    AdSize.GetCurrentOrientationAnchoredAdaptiveBannerAdSizeWithWidth(width)
    AdSize.GetPortraitAnchoredAdaptiveBannerAdSizeWithWidth(width)
    AdSize.GetLandscapeAnchoredAdaptiveBannerAdSizeWithWidth(width)

    Which one you use depends on your use case. If you want to preload ads for a given orientation, use the API for that orientation. If you only need a banner for the current orientation of the device, use the current orientation API.

    Once you have an ad size, set that on your banner view as usual before loading an ad. The banner will resize to the adaptive ad size as long as you have laid it out without any conflicting constraints.

  3. Update your mediation adapters. If you use mediation, update your mediation adapters to the latest version. All open source mediation adapters that support banners have been updated to support the adaptive banner ad size requests. Note that adapters will still only return ad sizes supported by their corresponding ad network SDK, and those ads will be centered in your adaptive banner view.

Review our developer resources

For further information including detailed implementation guidance, review our developer resources:

As always, please reach out on our developer forum if you have any questions.

And here is the project afterwards:

First, you’ll notice that the package name for AppCompatActivity has changed to androidx.appcompat.app. The refactor has changed this project’s com.android.support:appcompat-v7:26.1.0 dependency to androidx.appcompat:appcompat:1.0.0 and fixed the associated imports.

Second, this migration added a gradle.properties file with these two lines:

android.useAndroidX=true
android.enableJetifier=true

These properties ensure your project and its dependencies use AndroidX, by rewriting any binaries that are using an Android support library. See Using AndroidX for more details on these flags.

Now that your project is converted to AndroidX, you can safely update your play-services-ads dependency to 18.0.0 in your project-level build.gradle file:

dependencies {
   implementation 'androidx.appcompat:appcompat:1.0.0'
   implementation 'com.google.android.gms:play-services-ads:18.0.0'
}

As always, you can follow the release notes to learn what’s changed in the Google Mobile Ads SDK. We’d also love to hear about how your migration went! If you have any questions about the release or have trouble migrating, please reach out to us on the Google Mobile Ads SDK developer forum.