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

The minimum Android API level is 21

Starting in version 23.0.0, the Google Mobile Ads SDK requires all apps to be on a minimum Android API level 21 to run. To adjust the API level, change the value of minSdk in your app-level build.gradle file to 21 or higher.

Ad Manager builder methods can now be chained

In version 23.0.0, AdManagerAdRequest.Builder methods inherited from its parent can be chained together to build an AdManagerAdRequest using a single call:

var newRequest = AdManagerAdRequest.Builder()
  .addCustomTargeting("age", "25") // AdManagerAdRequest.Builder method.
  .setContentUrl("https://www.example.com") // Method inherited from parent.
  .build() // Builds an AdManagerAdRequest.

A side effect of this change is AdManagerAdRequest.Builder no longer inherits from AdRequest.Builder.

SDK deprecation and sunset timelines activated

With this Android major version 23 launch and the iOS major version 11 launch last month, we are announcing new deprecation and sunset dates for older major releases. Specifically:

• Android Google Mobile Ads SDK versions 21.x.x are officially deprecated, and will sunset in Q2 2025.
• Android versions 20.x.x and iOS versions 8.x.x will sunset on June 30, 2024.
  • While there are currently no plans to disable ad serving on Android versions 20.x.x and iOS versions 8.x.x, we strongly recommend updating to a supported SDK version to avoid being impacted in the future.

For the full list of changes in v23.0.0, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade. As always, if you have any questions or need additional help, contact us via the developer forum.

 - Jill Song, Mobile Ads Developer Relations

Today, we are announcing that version 11.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.

Simplified SwiftUI development

Version 11.0.0 no longer requires publishers to declare a view controller to present full-screen ads. As a result, SwiftUI Publishers can now present full-screen ads without the need for UIKit or UIViewControllerRepresentable workarounds. See our SwiftUI guide for more information.

struct ContentView: View {
  private let adCoordinator = AdCoordinator()

  var body: some View {
    ...

    Button("Watch an ad") {
      adCoordinator.showAd()
    }
  }
}

private class InterstitialAdCoordinator: NSObject, GADFullScreenContentDelegate {
  private var interstitial: GADInterstitialAd?

  ...

  func showAd() {
    guard let interstitial = interstitial else {
      return print("Ad wasn't ready")
    }

    // The SDK uses the app's main window to look up view controllers
    // automatically when one is not provided.
    interstitial.present(fromRootViewController: nil)
  }
}

Continue collecting user metrics in AdMob

The Google Mobile Ads SDK dependency on GoogleAppMeasurement has been removed. This dependency that powered the user metrics toggle in AdMob will be discontinued in early 2024. To continue collecting user metrics in AdMob, link your AdMob app to Firebase and integrate the Google Analytics for Firebase SDK into your app.

Changes to minimum OS and Xcode requirements

• The minimum OS version to load ads has been bumped from 12 to 13. Applications can still be built for iOS 12, but the SDK will only load ads on iOS 13 and higher.
• The minimum supported Xcode version has been bumped to 15.1.

For the full list of changes, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade.

SDK Deprecation Reminder

Per the deprecation schedule, the release of version 11.0.0 means that:

• iOS Google Mobile Ads SDK versions 9.x.x are officially deprecated, and will sunset in Q2 2025.
• Versions 8.x.x and below will sunset in Q2 2024, approximately 60 days following the release of Android Google Mobile Ads SDK major version 23.0.0.
  • While there are currently no plans to disable ad serving on version 8.x.x, we strongly recommend updating to a supported SDK version to avoid being impacted in the future.

As always, if you have any questions or need additional help, contact us via the developer forum.

 - Justin Malandruccolo, Mobile Ads Developer Relations

In case you missed it, we announced new consent management platform requirements for serving ads in the EEA and UK. Beginning January 16, 2024, Google will require all publishers to use a Google-certified consent management platform (CMP) when serving ads to users in the European Economic Area or the UK.

In addition to growing our list of certified CMPs, we explored how to improve the User Messaging Platform (UMP) SDK developer experience for those who choose to use Google’s consent management solution. We are excited to share several updates in the latest iOS and Android versions that we think will streamline your integration.

Loading and presenting a consent form

The latest UMP SDK release introduces a new API, loadAndPresentIfRequired(), that consolidates the existing individual load and present consent form methods into a single method. The new API loads a consent form and if consent is required, automatically presents the consent form. This method is intended to be used at the beginning of a new app session.

Here is a code example of how to use the new API on iOS:

class ViewController: UIViewController {

  private var isMobileAdsStartCalled = false

  override func viewDidLoad() {
    super.viewDidLoad()

    UMPConsentInformation.sharedInstance.requestConsentInfoUpdate(with: parameters) {
      [weak self] requestConsentError in
      guard let self else { return }

      // Call the helper method once consent information has been updated.
      UMPConsentForm.loadAndPresentIfRequired(from: self) {
        [weak self] loadAndPresentError in
        guard let self else { return }

        if UMPConsentInformation.sharedInstance.canRequestAds {
          self.startGoogleMobileAdsSDK()
        }
      }
    }

    // canRequestAds will be true if consent was gathered in the previous session.
    if UMPConsentInformation.sharedInstance.canRequestAds {
      startGoogleMobileAdsSDK()
    }
  }

  private func startGoogleMobileAdsSDK() {
    DispatchQueue.main.async {
      guard !self.isMobileAdsStartCalled else { return }

      self.isMobileAdsStartCalled = true

      // Initialize the Google Mobile Ads SDK.
      GADMobileAds.sharedInstance().start()
      // Request an ad.
      GADInterstitialAd.load(...)
    }
  }
}

Checking when to request ads

We added a new boolean property canRequestAds to use as a check before initializing the Google Mobile Ads SDK and requesting ads. canRequestAds returns true when the consent status is either OBTAINED or NOT_REQUIRED; as a result you don’t need to implement any enum checking yourself.

You should use the canRequestAds API in two places (as seen in the code snippet above):

1. Once consent has been gathered in the current session.
2. Immediately after you have called requestConsentInfoUpdate. It is possible consent has been gathered in the previous session in which case it is not necessary to wait for the callback to finish.

Checking privacy options requirement status

GDPR requires that publishers allow users to withdraw their consent choices at any time. It should be as easy to withdraw consent as it is to gather consent. To simplify this process, we have added two new APIs:

1. privacyOptionsRequirementStatus to determine whether you should include a UI element that can re-present the consent form, such as a button in your application’s settings page.
2. presentPrivacyOptionsForm() to show the form so the user can update their consent status at any time.

Here is a code example of how to use the new APIs on iOS:

// Show a privacy options button if required.
private var isPrivacySettingsButtonEnabled: Bool {
  return UMPConsentInformation.shared.privacyOptionsRequirementStatus == .required
}

// Present the privacy options form when a user interacts with your app.
@IBAction func privacySettingsTapped(_ sender: UIBarButtonItem) {
  UMPConsentForm.presentPrivacyOptionsForm(from: self) {
    [weak self] formError in
    guard let self, let formError else { return }

    // Handle the error.
  }
}

Developer resources

We updated our AdMob banner samples applications for iOS and Android to showcase integrating the UMP SDK. Keep an eye out as we add UMP SDK support to the rest of our samples soon.

Also take a look at our iOS and Android developer documentation for instructions on how to implement the UMP SDK.

If you have any questions or need additional help integrating the UMP SDK, please contact us via the developer forum.

 - Justin Malandruccolo, Mobile Ads Developer Relations

We are excited to announce the release of Version 8 of the Google Mobile Ads for Unity plugin! This new version contains a number of new features and upgraded APIs.

Minimum Unity version is now 2019.4

The Google Mobile Ads Unity plugin now has a minimum Unity Engine version requirement of 2019.4. This was done to align with Unity’s long term support.

Compatibility with Android v22.0.0

This release supports the Android Google Mobile Ads SDK version 22.0.0 major version release.

User Messaging Platform (UMP) support

The Google Mobile Ads Unity plugin now includes support for the Google User Messaging Platform (UMP) to help you gather consent from app users. To enable UMP support, see the user privacy get started guide.

Plugin now has C# reference documentation

With the release of version 8, we now have launched C# reference documentation. Moreover, this version added xml-doc summaries to all public fields, properties, methods, and classes. This makes the plugin easier to use and provides full IntelliSense support when developing in Visual Studio.

Migrate ad format events to the new interface

Full-screen ad formats APIs now have a uniform interface and we are removing the old ad event APIs. These changes make the APIs for each ad format more consistent and easier to use. The new interface includes a static Load() method, use of generic delegates instead of EventArgs, and consistent ad events names across formats.

For a full list of changes and steps for upgrading your code, please see the version 8 migration guide.

Use RaiseAdEventsOnUnityMainThread() to guarantee thread safety

The Google Mobile Ads Unity plugin now includes an optional support feature for Unity thread safety. This feature means you no longer need to manage threading concerns when handling platform events or callbacks.

If you use this feature, the SDK may pause events during full screen ad presentations. This means that you might not get some events, like OnAdFullScreenContentOpened or OnAdImpressionRecorded, until after the user comes back to the game. If you need to collect this data in real time, this might not be a good option. We recommend you test this feature to see if it works for you.

Here's an example of how to use Google Mobile Ads new thread safety support:

Deprecation of Ad Placements

The Google Mobile Ads Unity plugin's Ad Placements feature is deprecated. There are no plans to move it into public release.

If you have any questions or concerns about migrating your project, please reach out on our developer forum.

 - Nicholas Ventimiglia, Mobile Ads Developer Relations

We are excited to announce the release of our newest version of the Google Mobile Ads SDK. We recommend upgrading as soon as possible to stay up-to-date with our latest features.

Version 22.0.0 Changes

Google Mobile Ads SDK version 22.0.0 introduces a few major changes:

• MobileAds.getVersionString() is removed in version 22.0.0 in favor of MobileAds.getVersion(). The new method returns the expected external version number (for example, 22.0.0), helping you more clearly identify your SDK version. For more information about this change, see the Use the new Google Mobile Ads SDK getVersion() method blog post.
• In version 21, the Google Mobile Ads SDK provided you the NativeCustomFormatAd.getVideoMediaView() method to get the media asset for an Ad Manager native custom ad format. In version 22, NativeCustomFormatAd provides direct access to getMediaContent() enabling you to define your MediaView in layout files along with the rest of your other views, and simply populate that view with its content once the ad loads.

See release notes for the full changelog. See our migration guide to help you migrate your apps.

SDK deprecation/sunset activated

Per the deprecated schedule announced last year, the release of iOS version 10.0.0 in February and this Android version 22.0.0 release activate the sunset period of earlier Android/iOS releases. Specifically:

• Android Google Mobile Ads SDK version 20.x.x is officially deprecated, meaning that you will be asked to update to at least version 21.0.0 to receive full support from the Google Mobile Ads SDK developer forum.
• Android versions 19.x.x and below, as well as iOS versions 7.x.x will sunset on June 30th, 2023, meaning that ad serving could be disrupted. See details below.

Updated definition of sunset

We remain committed to regularly disabling old SDK versions balanced with minimizing disruption to ad serving. Aligned with this goal, we are making some changes to the previously announced sunset definition for 2023:

1. We previously communicated that the sunset notice period would be 2 months. For this 2023 sunset, the sunset date is June 30th, approximately 3 months notice.
2. We will leverage the “Outdated” feature on the Google Play SDK Index, requiring you to move off a sunset SDK version for future releases of your Android apps. See Understanding issues with your app’s third-party SDK for more information.
3. Starting June 30th, you may notice some disruptions in your ad serving. While we do not plan to stop ad serving for iOS version 7.x.x and Android versions 19.x.x and earlier at this time, we will regularly review usage of all sunset versions going forward to consider disabling ad serving. The oldest versions with lower usage and higher maintenance costs will be targeted first. Therefore, ad traffic from sunset SDKs versions will be at risk of receiving automatic no fill due to stopped ad serving going forward.

To avoid disruptions in ad serving, we highly recommend upgrading to a supported version as soon as possible so your users have a chance to update before June 30th, 2023.

Check if your apps are affected

To help you prepare for these changes, there are several ways you can check if your apps are affected:

• Use the Ads Activity report and enable the “GMA SDK” dimension to see iOS app traffic running on iOS 7.x.x or earlier. Currently, only the Google Mobile Ads SDK for iOS is supported.
• In Android Studio, check your build.gradle file for build warnings, which are thrown when compiling with Android SDK version 19.x.x or earlier.
• Check your console logs for warning logs when making ad requests.

As always, if you have any questions or need additional help, contact us through the developer forum.

 - Jill Song, Mobile Ads Developer Relations

Today, we’re excited to announce the launch of our 2023 Google Mobile Ads SDK Developer Survey. As part of our efforts to continue updating the AdMob and Ad Manager products, we’d like to hear from you about where we should focus our efforts. This includes product feedback as well as feedback on our guides, code samples and other resources. Your feedback will help shape our future product and resource roadmap.

Take the survey

This anonymous survey should only take about 15 minutes to complete and will provide our team with your valuable feedback as we plan for the months ahead. Whether you’re an engineer, Ad Ops personnel, or a PM, your feedback on AdMob, Ad Manager, and the Google Mobile Ads SDK is valuable to us. We appreciate you taking the time to help improve our developer experience!

 - Chris Giglio, Mobile Ads Developer Relations

The volume control APIs provided by the Google Mobile Ads SDK are intended to mirror your app’s own custom volume controls. Utilizing these APIs ensures that the user receives video ads with the expected audio volume.

We’ll talk about some best practices implementing the volume control APIs in your iOS, Android or Unity project.

Why are we mentioning this?

Publishers can lose revenue when using these APIs to lower or mute the volume of the Google Mobile Ads SDK. Two issues we have commonly seen:

1. Apps are using their own custom volume controls not sending the app’s accurate volume to the Google Mobile Ads SDK, but always sending zero
2. App are just muting the SDK

Some apps have close to a 100% mute rate which doesn’t sound correct (pun intended). Setting application volume to zero or muting the application reduces video ad eligibility, which as a result may reduce your app’s ad revenue.

Volume control APIs

The Google Mobile Ads SDK offers two volume control APIs: setting the volume and toggling mute. These APIs are applicable to App Open, Banner, Interstitial, Rewarded and Rewarded Interstitial ad formats. For Native ads, use GADVideoOptions.

Setting application volume on each platform

iOS	GADMobileAds.sharedInstance().applicationVolume = 1.0
Android	MobileAds.setAppVolume(1.0f)
Unity	MobileAds.SetApplicationVolume(1.0f)

Use applicationVolume to set your custom volume relative to the device volume. The range can be from 0.0 (silent) to 1.0 (current device volume). For example, if the device volume level was at half level and the user set your app’s custom volume to max level, set the applicationVolume to 1.0 and the user will receive an ad with the volume at half level.

Setting application mute on each platform

iOS	GADMobileAds.sharedInstance().applicationMuted = true
Android	MobileAds.setAppMuted(true)
Unity	MobileAds.SetApplicationMuted(true)

Use applicationMuted if your custom volume controls include a mute button. Only toggle applicationMuted if the user selects your custom mute button. For example, if the user adjusts your custom volume to 0 you do not need to call applicationMuted; just call applicationVolume = 0.0.

Setting mute for native ads on each platform

iOS	let videoOptions = GADVideoOptions() videoOptions.startMuted = true adLoader = GADAdLoader( adUnitID: "AD_UNIT_ID", rootViewController: self, adTypes: [ ... ad type constants ... ], options: [videoOptions])
Android	val videoOptions = VideoOptions.Builder() .setStartMuted(false) .build() val adOptions = NativeAdOptions.Builder() .setVideoOptions(videoOptions) .build() val adLoader = AdLoader.Builder(this, "AD_UNIT_ID") .forNativeAd( ... ) .withNativeAdOptions(adOptions) .build()
Unity	N/A - Native video ads are not supported in Unity.

Use startMuted if your custom volume controls include a mute button. Only toggle startMuted if the user selects your custom mute button.

Best Practices

To use our APIs as intended:

1. applicationVolume should be called only when your custom volume control settings are set to reflect the new volume
2. applicationMuted or startMuted should only be toggled to true if the user has muted your custom volume

As a rule of thumb, if your app does not have custom volume controls then you should not use these APIs.

What should you do?

To verify that your mobile applications are using these APIs correctly, we recommend that you enable test ads and force load a video test ad in your application. If your app has custom volume controls, the ad’s volume should be at the same level as the custom volume. Otherwise, the ad’s volume should match the device volume.

If you have any questions or need additional help, please contact us via the forum.

 - Justin Malandruccolo, Mobile Ads Developer Relations

We are excited to announce the release of our newest version of the Google Mobile Ads SDK. We recommend upgrading as soon as possible to stay up-to-date with our latest features.

Version 10.0.0 Changes

Google Mobile Ads SDK version 10.0.0 introduces a few major changes:

• The minimum OS version has been bumped from 11 to 12. Given the high adoption rate of iOS 16, we are continuing the trend of incrementing the minimum support level. Applications can still be built for iOS 11, however, the SDK will not load any ads on iOS 11.
• Since bitcode is deprecated in Xcode 14, we have disabled bitcode in the SDK. As a result, this has decreased the download size of our SDK by ~35MB. What this means for you is to integrate with SDK version 10.0.0, you also have to disable bitcode (if you haven’t already) in the build settings of your Xcode project.
• Ad Manager applications require an app ID upon initialization of the SDK. This also means the key GADIsAppManagerApp will no longer bypass this check. App IDs are added to the Info.plist with a key of GADApplicationIdentifier. See Update your Info.plist for more details.
• Ad Manager applications require GoogleAppMeasurement.xcframework as a dependency. If you install the Google Mobile Ads SDK through CocoaPods or Swift Package Manager, no additional action is required. If you install frameworks manually, see Manual Download for more details.
• We also have removed deprecated APIs of various properties and classes.

For the full list of changes, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade.

SDK Deprecation Reminder

Per the deprecation schedule announced last year, the release of version 10.0.0 means that:

• iOS Google Mobile Ads SDK versions 8.x.x is officially deprecated, and will sunset in Q2 2024.
• Versions 7.x.x and below will sunset sometime in Q2 2023, approximately 60 days following the release of Android Google Mobile Ads SDK major version 22.0.0.

As always, if you have any questions or need additional help, contact us via the forum.

 - Justin Malandruccolo, Mobile Ads Developer Relations

We are happy to announce the release of an iOS sample application that demonstrates how to integrate the Google Mobile Ads SDK into a SwiftUI-based app. This post covers how we implemented full screen ad formats (interstitial, rewarded, rewarded interstitial) in SwiftUI.

The Google Mobile Ads SDK relies heavily on the UIKit Framework, depending on UIView or UIViewController for each ad format. For example, the SDK currently presents full screen ads using the following method:

present(fromRootViewController rootViewController: UIViewController)

In UIKit, ads are typically implemented in a UIViewController, so it is rather trivial to pass in a rootViewController value by simply invoking self. SwiftUI requires us to diverge from this approach, however, because UIViewController cannot be directly referenced in SwiftUI. Since we can’t just pass in self as the root view controller, we needed to achieve a similar result using a SwiftUI-native approach.

Our solution

We created an implementation of the UIViewControllerRepresentable protocol with a UIViewController property. Its one job is to provide access to the UIViewController reference in SwiftUI.

private struct AdViewControllerRepresentable: UIViewControllerRepresentable {
  let viewController = UIViewController()

  func makeUIViewController(context: Context) -> some UIViewController {
    return viewController
  }

  func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {}
}

AdViewControllerRepresentable needs to be included as part of the view hierarchy even though it holds no significance to the content on screen. This is because canPresent(fromRootViewController:) requires the presenting view controller’s window value to not be nil.

private let adViewControllerRepresentable = AdViewControllerRepresentable()

var body: some View {
  Text("hello, friend.")
      .font(.largeTitle)
      // Add the adViewControllerRepresentable to the background so it
      // does not influence the placement of other views in the view hierarchy.
      .background {
        adViewControllerRepresentable
          .frame(width: .zero, height: .zero)
      }
}

To present the full screen ads in our sample app, we leveraged action events in SwiftUI.

Button("Watch an ad!") {
  coordinator.presentAd(from: adViewControllerRepresentable.viewController) 
}

And our AdCoordinator class does the honor of presenting it from our view controller.

private class AdCoordinator: NSObject {
  private var ad: GADInterstitialAd?

  ...

  func presentAd(from viewController: UIViewController) {
    guard let ad = ad else {
      return print("Ad wasn't ready")
    }

    ad.present(fromRootViewController: viewController)
  }
}

And voila!

An alternative option

Instead of creating a UIViewControllerRepresentable, there was always the option to query the rootViewController property from UIWindow.

UIApplication.shared.windows.first?.rootViewController

We decided against this option for the following reasons:

1. There is the inherent nullability risk to querying an optional array index.
2. The default value of rootViewController is nil.
3. If your app utilizes more than one window, the windows array will have multiple elements and therefore, makes querying the “first” window object unreliable.
4. windows on the UIApplication object is deprecated in iOS 15 and UIWindowScene now holds the reference to this property.

Conclusion

We know there is more than one way to cook an egg when it comes to writing code in SwiftUI. For our use case, we chose the most low-code friendly option. If you have any questions, reach out to our developer forum.

Try it out!

 - Justin Malandruccolo, Mobile Ads Developer Relations

To provide Google Mobile Ads SDK developers for AdMob and Ad Manager more transparency and predictability on the expected lifetime of an SDK version, we are introducing a deprecation schedule for the Google Mobile Ads SDKs for Android and iOS.

Benefits

Introducing a predictable deprecation schedule offers the following benefits for app developers and publishers:

1. Ability to predict and plan for SDK updates with a year of lead time.
2. Legacy SDK code that only exists to support old versions can be deleted, thereby decreasing SDK size and lowering the risk of bugs.
3. Engineering resources are freed up to focus more on support for newer SDKs and innovation of new SDK features.

Glossary

To understand the deprecation schedule, let’s first align the terms used to describe the state of a Google Mobile Ads SDK version:

SDK State	Impact
Supported	Ads serve to this SDK. Technical SDK support questions are welcomed on the Google Mobile Ads SDK developer forum.
Deprecated	Ads will still serve to this SDK. Support questions specific to this SDK version are no longer answered on the Google Mobile Ads SDK developer forum. Users will be asked to validate the issue in a supported SDK version to receive full support.
Sunset	Ads will not serve to this SDK. Ad requests return a no fill with an error indicating that this version is sunset.

Timelines

The deprecation and sunset timelines will revolve around major SDK version releases. We plan to do a major version release annually, in the first quarter of each year. The release of a new major version on both Android and iOS will trigger changes in SDK state for older major versions on both platforms.

Once we release a new major version N for both Android and iOS:

• All SDK versions with major version N-2 on their respective platforms are considered deprecated immediately. Questions specific to these versions will no longer receive support.
• All SDKs versions with major version N-3 on their respective platforms will sunset after 2 months.
  • We will publish subsequent blog posts communicating specific sunset dates to activate this two-month sunset period. The first sunset announcement is expected in Q1 2023 with a sunset date in Q2 2023.

With this schedule, a new major version will live in the supported state for about 2 years, and in the deprecated state for an additional year before moving to the sunset state.

The graphic below helps visualize the schedule:

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.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

We heard your feedback that MobileAds.getVersionString() was confusing as it didn’t match the external version. We addressed it by adding a new method - MobileAds.getVersion(). In doing so, we have deprecated MobileAds.getVersionString().

Distinctions between getVersionString() and getVersion()

	getVersionString() [deprecated]	getVersion()
Sample return value	afma-sdk-a-v214106000.214106000.0	21.0.0
Requires calling initialize() first?	Yes	No

Calling MobileAds.getVersionString() returns an internal version number. The MobileAds.getVersion() method outputs a simplified, external version number that matches the version in the release notes. For example, 21.0.0.

Also as part of the v21.0.0 release, you can call MobileAds.getVersion() before calling MobileAds.initialize(). Previously, you had to initialize the SDK to query the SDK version number, or else the app would crash.

Querying the SDK version number can be accomplished in your Android apps with the following code snippet:

// Log the Mobile Ads SDK Version.
Log.d("MyApp", MobileAds.getVersion()); // "21.0.0"

// Initialize the SDK.
MobileAds.initialize(this, new OnInitializationCompleteListener() {
    @Override
    public void onInitializationComplete(InitializationStatus status) {} 
});

For the full list of changes in the v21.0.0 release, check the release notes. If you have any questions or need additional help, contact us via the forum.

 - Justin Malandruccolo, Mobile Ads Developer Relations

We’re excited to announce a new feature for app developers who use Unity: Ad Placements. It is now available in Open Beta.

What are Ad Placements?

Ad Placements provide a cleaner and more intuitive way to place ad units from Google AdMob in your games. Ad Placements allow developers to add ad units with a Unity Editor interface, making the specification of ad units for your game centralized, re-usable, and decoupled from your scripts.

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.

 - Samuel Stow, Mobile Ads Developer Relations

In order to help mobile app publishers review ad issues (e.g., out-of-memory caused by graphic intense creatives, violations of Ad Manager policies, or AdMob policies and restrictions) in production apps, we have recently added an ad response ID to the ResponseInfo and GADResponseInfo objects in the Google Mobile Ads Android SDK (v. 19.0.0) and iOS SDK (v. 7.49.0). An ad response ID is a unique string for each ad response from the AdMob or Ad Manager server, regardless of ad formats. If the same ad is returned more than once, the ad response ID will differ each time.

You can look up an ad response ID in the Ad Review Center (AdMob, Ad Manager) to find and block the offending ad. You can also report problematic ads to Google using the ad response ID, especially when it is difficult to capture a mobile ad's click string.

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.

 - Thang Duong, Mobile Ads Developer Relation

In today’s mobile-first world, app publishers who use banner ads must serve them across a greater variety of screen sizes and layouts than ever before. Existing responsive banner ad formats often produce ads that are too small and not optimally tailored to the specifications of each device.

To address this, we’ve created a new banner type called adaptive anchor banners. These banners dynamically adjust creative size to deliver an ad that is ideally sized across all of your user’s devices, without the need to write any custom code.

These banners are designed to replace standard 320x50 and leaderboard banner sizes, as well as smart banners. Here is a comparison of the 3 formats on a standard mobile device:

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:

• Adaptive banner guide (AdMob iOS | AdMob Android | AdMob Unity | Ad Manager iOS | Ad Manager Android)
• Adaptive banner sample app (AdMob iOS | AdMob Android | Ad Manager iOS | Ad Manager Android)

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

 - Samuel Stow, Mobile Ads Developer Relations

We’re continuously improving our guides, code samples, and other developer resources for the Google Mobile Ads SDK to help you integrate AdMob and Ad Manager into your mobile apps.

To learn more about what's working well and what could be improved, we're announcing our second annual developer feedback survey for the Google Mobile Ads SDK. We'd like to hear from you about where we should focus our efforts.

SHARE YOUR FEEDBACK

Your answers will be completely anonymous. The survey should take about 15 minutes to complete and will close on September 30, 2019.

Your feedback is truly important to us. Here are a few highlights of the changes we made based on feedback from last year’s survey:

1. Continuous translations of the developer docs in several languages
2. Continuous build integration of sample applications via Travis CI
3. Launched a Developer tutorials playlist on the Google AdMob YouTube channel
4. Launched the App Policy Center to help publishers handle policy violations

Please let us know what you’d like us to focus on next. Thank you in advance for helping us continue to improve the developer experience for everyone.

 Eric Leichtenschlag, Mobile Ads Developer Relations

Earlier this week, Google Play services released a major update to many of its libraries to migrate all Android support library dependencies to Jetpack (using androidx.* packages). This includes the play-services-ads library from the Google Mobile Ads SDK, which has been updated to 18.0.0.

While the Google Mobile Ads SDK itself hasn’t changed between version 17.2.1 and 18.0.0, you’ll need to migrate your own app and all of your dependencies to AndroidX in order to pick up play-services-ads 18.0.0 or any future versions. This is particularly important if you use AdMob mediation, as several mediation partners have dependencies on Android support libraries that aren’t compatible with AndroidX.

To make the migration process as smooth as possible for you, Android Studio offers an easy way to convert your project and its dependencies to AndroidX using the Migrate to AndroidX option.

Migrate to AndroidX

Android Studio 3.2 or higher includes a Refactor > Migrate to AndroidX menu option to convert your project to use AndroidX. We’ll demonstrate what happens when converting our BannerExample to AndroidX.

1. Change the project’s compileSdkVersion to 28. This is a prerequisite for migrating to AndroidX.
2. Right click the app module, and select Refactor > Migrate to AndroidX. You’ll be given an option to save your project as a zip file before Android Studio converts it.
3. Select Do Refactor to complete the migration.

What changed?

Here is the project before the migration:

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.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Updated on 10/9/2018 to fix the format of the AdMob application ID. The format of an AdMob app ID is ca-app-pub-################~##########.

Google Mobile Ads SDK v17.0.0 for Android has just been released, and it comes with two important changes that you should be aware of:

1. A tag is now required in AndroidManifest.xml.
2. NativeAppInstallAd and NativeContentAd APIs are deprecated in favor of UnifiedNativeAd.

Required AndroidManifest.xml changes

Starting in version 17.0.0, if you are an AdMob publisher you are now required to add your AdMob app ID in your AndroidManifest.xml file. Once you find your AdMob app ID in the AdMob UI, add it to your manifest adding the following tag:

<manifest>
    <application>
        <!-- TODO: Replace with your real AdMob app ID -->
        <meta-data
            android:name="com.google.android.gms.ads.APPLICATION_ID"
            android:value="ca-app-pub-################~##########"/>
    </application>
</manifest>

Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly."

What if I'm using Google Ad Manager instead of AdMob?

Publishers using Google Ad Manager will need to declare themselves as an Ad Manager app with a different tag to avoid the same crash:

<manifest>
    <application>
        <meta-data
            android:name="com.google.android.gms.ads.AD_MANAGER_APP"
            android:value="true"/>
    </application>
</manifest>

See the getting started guide (AdMob | Ad Manager) for additional details on how to make this change.

NativeAppInstallAd and NativeContentAd APIs are deprecated

This release also officially deprecates the NativeAppInstallAd and NativeContentAd APIs in favor of the previously released UnifiedNativeAd API. The UnifiedNativeAd APIs offer a consolidated way to render any type of native ad, reducing the number of lines of code needed to integrate native ads by up to 50%.

The following example shows how to load both app install and content ads using the new unified API:

AdLoader adLoader = new AdLoader.Builder(context, "ca-app-pub-3940256099942544/2247696110")
    .forUnifiedNativeAd(new UnifiedNativeAd.OnUnifiedNativeAdLoadedListener() {
        @Override
        public void onUnifiedNativeAdLoaded(UnifiedNativeAd unifiedNativeAd) {
            // Show the ad.
        }
    })
    .build();
adLoader.loadAd(new AdRequest.Builder().build());

Check out the native ads guide to get started with the unified API.

What else changed?

See the release notes for a full list of changes. If you have any questions about the release, please reach out to us on the Google Mobile Ads SDK developer forum.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Today we're announcing the release of Mediation Test Suite Beta. Mediation Test Suite is a lightweight SDK that enables Google AdMob publishers to easily test mediation ad network integrations without having to make changes in the AdMob UI, saving you and your developers time. It is available on Android, iOS, and Unity.

Mediation Test Suite allows you to:

• View a full list of mediation ad source configurations for your app
• Automatically check your project for missing SDKs, adapters, and manifest changes required by partner ad sources
• Load a banner, interstitial, rewarded, or native ad for any ad source using a certified Google Mobile Ads SDK implementation
• Batch test multiple ad sources for the same ad unit
• Test both open source mediation adapters and custom event adapters

Integrating Mediation Test Suite is easy -- once you have the SDK imported, it can be launched with just a single line of code. All you need is your AdMob app ID.

On Android, the launch code looks like this:

import com.google.android.ads.mediationtestsuite.MediationTestSuite;
...
String appId = "YOUR-ADMOB-APP-ID";
MediationTestSuite.launch(MainActivity.this, appId);

On iOS, all that's required is importing the correct header and launching the Test Suite:

#import "GoogleMobileAdsMediationTestSuite.h"
...
NSString* appId = @"YOUR-ADMOB-APP-ID"
[GoogleMobileAdsMediationTestSuite presentWithAppID:appId
                                   onViewController:self delegate:nil];

Unity is just as simple, but please note that you need to use the appropriate app ID for your platform:

using GoogleMobileAdsMediationTestSuite.Api;
...
#if UNITY_ANDROID
string appId = "YOUR-ANDROID-ADMOB-APP-ID";
#elif UNITY_IPHONE
string appId = "YOUR-iOS-ADMOB-APP-ID";
#else
string appId = "";
#endif
MediationTestSuite.Show(appId);

Including Mediation Test Suite in production builds is optional

You are not required to keep the Mediation Test Suite library in the production release of your app; however, you may choose to leave it in and hide it behind a debug gesture. Doing so enables you to launch Mediation Test Suite within your production build.

You can find more information about how to use Mediation Test Suite in the developer guide (Android | iOS | Unity). Remember that Mediation Test Suite is a beta product, so if you have any questions or feedback, please contact us on the developer forum.

 - Jon Weisbaum, Mobile Ads Developer Relations

Today we're pleased to announce the release of the Unified Native Ads API, an easier way to implement AdMob Native Ads Advanced. This feature is now available in Google Mobile Ads for iOS, as of version 7.28.0. The Android version will be made available in an upcoming release.

With this feature, the existing native ad formats in Native Ads Advanced — GADNativeAppInstallAd and GADNativeContentAd — are replaced by a single format, GADUnifiedNativeAd. The corresponding views, GADNativeAppInstallAdView and GADNativeContentAdView, are replaced by a single corresponding view, GADUnifiedNativeAdView.

Using the Unified Native Ads API, you no longer need to create UIs for ad content and app install ad formats separately. Instead you will create one UI for unified native ads, saving you time from developing and maintaining two separate UIs and associated code for the two previous ad formats, while still getting the same ad demand.

Here's a short code example showing how your implementation might change when migrating from the separate formats to the new unified format:

@implementation ViewController

- (void)viewDidLoad {
  [super viewDidLoad];

// Note here we request only `kGADAdLoaderAdTypeUnifiedNative` and no
// longer request both `kGADAdLoaderAdTypeAppInstall` and
// `kGADAdLoaderAdTypeContentAd`
  self.adLoader = [[GADAdLoader alloc] initWithAdUnitID:YOUR_AD_UNIT_ID
          rootViewController:self
                     adTypes:@[ kGADAdLoaderAdTypeUnifiedNative ]
                     options:nil];
  self.adLoader.delegate = self;
  [self.adLoader loadRequest:[GADRequest request]];
  }
}

#pragma mark - GADUnifiedNativeAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveUnifiedNativeAd:(GADUnifiedNativeAd *)nativeAd {
 // A unified native ad has loaded, and can be displayed.
}

// Note that the two separate ad type delegate callbacks are no longer needed.
#pragma mark - GADNativeAppInstallAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveNativeAppInstallAd:(GADNativeAppInstallAd *)nativeAppInstallAd {
   // An app install ad has loaded, and can be displayed.
}

#pragma mark - GADNativeContentAdLoaderDelegate
- (void)adLoader:(GADAdLoader *)adLoader
    didReceiveNativeContentAd:(GADNativeContentAd *)nativeContentAd {
   // A content ad has loaded, and can be displayed.
}

With the Unified Native Ads format, you still need to respect the required and recommended assets for display, and check the availability of certain assets when displaying the Unified Native Ad.

For detailed documentation on how to implement Unified Native Ads, refer to the developer documentation and the updated sample code.

If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.

 - Samuel Stow, Mobile Ads Developer Relations

Cross posted from the AdMob blog.

Optimizing the ad experience on your app for a varied audience can be difficult. Showing users ads that are a better fit can improve their overall ad experience and help maximize your app’s revenue.

AdMob has launched a new feature that allows you to specify the content rating for Google ads served in your app. With the new max_ad_content_rating signal, you can now choose the content rating of Google demand that you want to deliver on a per-request basis.

Four content rating choices offer you the granularity you need to provide users at each level with a better user experience. The four new content rating choices are:

• G: Content suitable for general audiences
• PG: Content suitable for most audiences with parental guidance
• T: Content suitable for teen and older audiences
• MA: Content suitable only for mature audiences

You can start sending the new max_ad_content_rating signal in the Google Mobile Ads SDK by following these Android and iOS guides. To learn more about the new signal and the content rating choices, visit the AdMob help center or contact your Google account team.

Posted by Alexa Haushalter, Product Manager, AdMob