Tag Archives: mobile_ads_sdk

SwiftUI Case Study: Presenting from View Controllers

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!

Announcing a deprecation schedule for the Google Mobile Ads SDK

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

Use the new Google Mobile Ads SDK getVersion() method

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.

Introducing Ad Placements for the Google Mobile Ads Unity plugin

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.

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

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.

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

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.

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

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.

Introducing adaptive anchor banners

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:

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

Share your feedback about AdMob and Ad Manager mobile app integration

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.

Google Mobile Ads SDK for Android: How to migrate to v18.0.0

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.