Reduce ANRs when implementing mobile ads

Wednesday, July 10, 2024

We heard your feedback via Play Console crash reports regarding Application Not Responding (ANRs) errors related to the Google Mobile Ads SDK. After analyzing these reports, we updated our SDK implementation best practices to reduce ANR rates. The recommended best practices are as follows:

Initialize the Mobile Ads SDK on a background thread

Enable optimization flag for ad loading

1. Initialize the Mobile Ads SDK on a background thread Our previous best practice was to specify the OPTIMIZE_INITIALIZATION manifest flag. However, some work on the calling thread is still required to prepare MobileAds to handle other method calls synchronously. We now recommend calling MobileAds.initialize() on a background thread, enabling the work required on the calling thread to happen in the background. import com.google.android.gms.ads.MobileAds import kotlinx.coroutines.CoroutineScope import kotlinx.coroutines.Dispatchers import kotlinx.coroutines.launch class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) CoroutineScope(Dispatchers.IO).launch { // Initialize the Google Mobile Ads SDK on a background thread. MobileAds.initialize(this@MainActivity) {} runOnUiThread { // Load an ad on the main thread. loadAd() } } } } Note: When calling MobileAds.initialize() on a background thread, the OPTIMIZE_INITIALIZATION manifest flag is no longer required. 2. Enable optimization flag for ad loading By enabling the OPTIMIZE_AD_LOADING manifest flag, you can offload most ad loading tasks to a background thread. We recommend enabling this flag in your app's AndroidManifest.xml file to reduce the occurrence of ad loading causing ANRs. <manifest> ... <application> ... <meta-data android:name="com.google.android.gms.ads.flag.OPTIMIZE_AD_LOADING" android:value="true"/> </application> </manifest> We’ve updated all of our Android example apps to implement these best practices. For more details on initialization and optimization flags, see Get started and Optimize initialization and ad loading. Contact us if you have any questions or need additional help.

- Joshua Hui, Mobile Ads Developer Relations

Announcing Android Google Mobile Ads SDK Version 23.0.0

Friday, March 15, 2024

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

We’ve Made Updates to the User Messaging Platform SDK APIs

Monday, August 7, 2023

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):

Once consent has been gathered in the current session.

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:

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.

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

Announcing new testing features for ad inspector

Tuesday, May 2, 2023

Alongside single ad source testing, these new testing features will allow you to rigorously test each individual ad network integration in your app.

To learn more about how to test your ads with ad inspector, check out our developer guides here:

Android (AdMob | Ad Manager)
iOS (AdMob | Ad Manager)
Flutter (AdMob | Ad Manager)
Unity (AdMob)
C++ (AdMob)

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

- Chris Giglio, Mobile Ads Developer Relations

We’re excited to announce the launch of new testing features on ad inspector across all platforms for our AdMob and Ad Manager publishers. Previously, ad inspector tested all ads in context - in other words, you had to fire up your app, navigate to the appropriate screen in the UI, and have your ad load as it would for any other user. While this provides for the most accurate testing scenario, it also puts more work on you as the publisher and tester of your app. You don’t want ads buried in more obscure screens in your app to lose out on the testing attention and care they need! With our latest update, you can now use test ads to load requests for any ad unit - no matter where it's located in your app. Rather than needing to navigate through your app to test each ad unit, you can execute your tests directly from ad inspector. How do I use ad inspector’s new testing features? Beginning with version v10.0.0 on iOS and v21.4.0 on Android of the Google Mobile Ads SDK, ad inspector supports running tests directly from the ad unit detail screen via a “Request test ad” button:

All of your requests made from your app’s UI or within ad inspector will appear in the SDK request log; your requests made from within ad inspector will be differentiated by being labeled with “Requested from ad inspector”. For these special requests you’ll be able to tap the “View” button one time to view the actual ad, see which network filled the slot, and more. Alongside single ad source testing, these new testing features will allow you to rigorously test each individual ad network integration in your app. To learn more about how to test your ads with ad inspector, check out our developer guides here:

Android (AdMob | Ad Manager)

iOS (AdMob | Ad Manager)

Flutter (AdMob | Ad Manager)

Unity (AdMob)

C++ (AdMob)

If you have any questions or need additional help, please contact us via the developer forum. - Chris Giglio, Mobile Ads Developer Relations

Android Google Mobile Ads SDK Version 22.0.0 activates SDK sunset timelines

Monday, April 3, 2023

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:

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.

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.

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

Take the 2023 Google Mobile Ads SDK developer survey

Friday, March 24, 2023

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

Use Mobile Ads SDK Volume APIs Correctly to Maximize Video Ad Revenue

Thursday, February 9, 2023

table, th, td { border: 1px solid black; border-collapse: collapse; padding:10px; } 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:

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

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:

applicationVolume should be called only when your custom volume control settings are set to reflect the new volume

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

Announcing a deprecation schedule for the Google Mobile Ads SDK

Wednesday, October 5, 2022

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

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

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:

Ability to predict and plan for SDK updates with a year of lead time.

Legacy SDK code that only exists to support old versions can be deleted, thereby decreasing SDK size and lowering the risk of bugs.

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

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.

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

Use the new Google Mobile Ads SDK getVersion() method

Monday, July 18, 2022

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() td { text-align: center; }

getVersionString() [deprecated]

getVersion()

Sample return value

afma-sdk-a-v214106000.214106000.0

21.0.0

Requires calling initialize() first?

Yes

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

The Interactive Media Ads (IMA) SDK for Android moves to Google's Maven repository

Tuesday, December 17, 2019

With the release of version 3.16.0 of the Interactive Media Ads SDK (IMA SDK) for Android, the location where we host the SDK has changed to Google's Maven Repository. As a result of this change, your Android project should include a reference to the google() repository (Google's Maven Repository) as a dependency. Previously, the SDK was hosted on JCenter. You can now remove the jcenter() reference from your Android project’s build.gradle file, as long as none of your other dependencies are hosted there. The google() repository should be referenced in the project-level build.gradle file of your project. You should then import the IMA SDK in the app/build.gradle file. See an example in the following code snippet from the Adding the IMA Android SDK to the player app section of the Android IMA SDK getting started guide. repositories { google() } dependencies { implementation 'androidx.appcompat:appcompat:1.1.0' implementation 'com.google.ads.interactivemedia.v3:interactivemedia:3.16.0' } Another change that comes from this update is that the com.google.android.gms:play-services-ads-identifier target is now included as a dependency of the IMA SDK and is no longer required to be explicitly included in the app/build.gradle file. If you have questions about the IMA SDK for Android, please see the SDK documentation, or reach out to us on the IMA SDK forum.

- Jackson Sui, Interactive Media Ads Developer Relations

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

Friday, June 21, 2019

And here is the project afterwards:

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

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.

Change the project’s compileSdkVersion to 28. This is a prerequisite for migrating to AndroidX.

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.

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

Announcing v17.0.0 of the Android Google Mobile Ads SDK

Monday, October 8, 2018

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:

A tag is now required in AndroidManifest.xml.

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

Announcing the Mediation Test Suite Beta

Thursday, August 9, 2018

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

Google Media Framework for Android is Deprecated

Monday, March 26, 2018

As previously announced, as of March 15th, 2018, the Google Media Framework (GMF) for Android is deprecated in favor of the IMA ExoPlayer plugin. All development and support for GMF has been halted. If you are a GMF Android user, we recommend you migrate to the IMA ExoPlayer plugin at your earliest convenience. Alternatively, to keep using GMF Android, you will have to fork and maintain it yourself.Note: We are NOT deprecating GMF for iOS.If you have any questions, feel free to contact us via the IMA SDK developer forum.

- Yury Pavlotsky, IMA SDK Team

Use ad content filtering to help improve your users’ ad experience

Thursday, January 18, 2018

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

Simpler testing with new AdMob test ads

Wednesday, January 3, 2018

New Test Ad Behavior

Starting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity.

Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad.

Sample 300x250 Banner ad

For native advanced test ads, the headline asset has the text "Test Ad" prepended.

Sample native content ad.

Test ads with Mediation

When using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guide for more information on how to enable test ads on those networks.

See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.

- Eric Leichtenschlag, Mobile Ads Developer Relations

Today we're announcing a behavior change when requesting test ads using the Google Mobile Ads SDK. It enables you to test your own ad units while also ensuring that you are in test mode. When using the Google Mobile Ads SDK during development, we recommend that you configure your device to request test ads. Always testing with test ads is important so you avoid having your account flagged for invalid activity. Previously, enabling test ads resulted in the same sample ad like this one being shown in your app:

While this worked well as a basic check, it didn't allow for testing what real ads would look like in a production environment. For example, you couldn't test your mediation configurations or the different types of banner and interstitial formats that AdMob offers. The update we're rolling out addresses these problems. New Test Ad Behavior Starting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity. Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad.

Sample 300x250 Banner ad For native advanced test ads, the headline asset has the text "Test Ad" prepended.

Sample native content ad.Test ads with Mediation When using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guide for more information on how to enable test ads on those networks. See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.

- Eric Leichtenschlag, Mobile Ads Developer Relations

Deprecating GMF for Android

Friday, December 8, 2017

On March 15, 2018, we are stopping development and support for Google Media Framework (GMF) for Android in favor of the new ExoPlayer IMA extension. GMF's technology and approach are based on an older version of ExoPlayer. The new v2 version of ExoPlayer and the ExoPlayer IMA Extension make basic integration simple enough that a layer between ExoPlayer and the IMA SDK is no longer necessary. The new approach is cleaner, requires less code, and uses the most up-to-date version of ExoPlayer. Support for GMF for Android will end on March 15, 2018, after which we will no longer respond to issues or make any further releases of GMF for Android. The repository will also be shut down at this time. If you want to access the code, you can clone the repository before the March 15, 2018 shutdown date. Note: We are NOT deprecating GMF for iOS. If you have any questions, feel free to contact us via the IMA SDK developer forum.

- Yury Pavlotsky, IMA SDK Team

Loading multiple native ads in the Google Mobile Ads SDK

Thursday, December 7, 2017

In the Google Mobile Ads SDK Android version 11.2.0 and iOS version 7.21.0, we added multiple native ads, a new feature for AdMob Native Ads Advanced. This feature lets you load up to five unique native ads with a single request. If you're showing native ads in a scrolling feed, this will allow you to get a batch of ads different from one another. It also means fewer network calls, which improves latency. If you're displaying multiple native ads in a feed and loading ads one by one, converting to the new API should be fairly straightforward. First, make a decision about how many ads you wish to fetch in one request. This is a function of how frequently you display ads in your feed. If you request five ads, AdMob will return the top five ads, ordered by eCPM value. If only three ads are available for the ad unit, only three ads will be returned. iOS Implementation Before initializing your ad loader, you need to create an instance of GADMultipleAdsAdLoaderOptions and set the numberOfAds property. Then include this object in the array of options when calling GADAdLoader's initializer: override func viewDidLoad() { super.viewDidLoad() let multipleAdsOptions = GADMultipleAdsAdLoaderOptions() multipleAdsOptions.numberOfAds = 5 adLoader = GADAdLoader(adUnitID: YOUR_AD_UNIT_ID, rootViewController: self, adTypes: [GADAdLoaderAdType.nativeContent, GADAdLoaderAdType.nativeAppInstall], options: [multipleAdsOptions]) adLoader.delegate = self adLoader.load(GADRequest()) } When requesting multiple native ads, you will still get individual callbacks when each ad is loaded. For example, for an app install ad you will have a callback to -adLoader:didReceiveNativeAppInstallAd:, and for a content ad -adLoader:didReceiveNativeContentAd:. This way you don't need to change the way the ads are received and shown. To determine when ads have finished loading, there are two new APIs available:

On the GADAdLoader object, a new property, loading, has been added. It returns true if a request is in progress, and false otherwise. You can check this property after each ad has loaded to find out if loading ads has completed.

On the GADAdLoaderDelegate, the adLoaderDidFinishLoading: method has been added. It's invoked when all ads for a request have been returned.

Android Implementation The Android implementation is similar to iOS. There's a new method on AdLoader, loadAds() which accepts the number of ads to load. There's also a new isLoading() method that indicates whether a request is currently in progress. For a detailed walkthrough of the implementations, see the AdMob Native Ads Advanced implementation guides (iOS | Android). 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

Kotlin and the Google Mobile Ads SDK

Friday, October 27, 2017

Implementation Guides

We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations.

Questions?

If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

- Andrew Brogdon, Mobile Ads Developer Relations

One of the biggest cheers from the crowd at I/O '17 came in response to Stephanie Saad Cuthbertson's announcement that Kotlin would be an officially supported language for Android development starting with Android Studio 3.0. If you're an AdMob or Doubleclick publisher who's been eager to make the leap to a new language, we've got another announcement you might like: now that the new version of Android Studio has launched, we've released bunch of new mobile ads resources to support the Kotlin community. If you haven't seen Kotlin yet, it's a statically typed language developed by JetBrains that compiles down to the same JVM bytecode that Java does, but includes a number of new features that can make Android development faster and easier. Things like dedicated data classes with less boilerplate, the Elvis operator, lambdas, SAM conversion, explicit nullability for references, and lots of other modern language features come built-in. For more information, see Introduction to Kotlin (also from I/O '17) in which Andrey Breslav and Hadi Hariri code up examples of the language's best features: When you're done, you can see those same features in action in our new developer resources, which are now available to the AdMob and Doubleclick publisher community. Samples The Mobile Ads DevRel team maintains a GitHub repository of Android samples covering our API, and we've pushed Kotlin versions for each ad format. If you been wondering how Kotlin's Android extensions work with AdMob's banner ad layouts, for example, we've got a new sample app that'll show you. If you're curious how native ads work with all the new nullability stuff, we've got you covered with Kotlin samples for those formats as well. In addition, we've included a new version of our API Demo app, which features a navigation drawer full of individual API demos for things like banner sizes, category exclusions, and more, all in Kotlin.

Implementation Guides We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations. Questions? If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

- Andrew Brogdon, Mobile Ads Developer Relations

ExoPlayer Releases IMA Extension

Wednesday, September 27, 2017

Users of ExoPlayer, an extensible, open-source media player for Android, can now easily integrate with the IMA SDK using the new ExoPlayer IMA extension. The IMA extension, released alongside ExoPlayer 2.5, wraps the IMA SDK for Android and provides seamless ad playback. The extension ensures that ads are integrated into ExoPlayer's video timeline, and UI components are ad-aware. It also reduces buffering by eliminating the need to swap out and rebuffer the video player's source when transitioning between ads and content. You can find more details on the extension in ExoPlayer's blog post on Medium, and find the extension on GitHub. If you have any questions or issues, please file them on ExoPlayer's issue tracker.

- Yury Pavlotsky, IMA SDK Team

Ads Developer Blog

Reduce ANRs when implementing mobile ads

Announcing Android Google Mobile Ads SDK Version 23.0.0

We’ve Made Updates to the User Messaging Platform SDK APIs

Announcing new testing features for ad inspector

Android Google Mobile Ads SDK Version 22.0.0 activates SDK sunset timelines

Take the 2023 Google Mobile Ads SDK developer survey

Use Mobile Ads SDK Volume APIs Correctly to Maximize Video Ad Revenue

Announcing a deprecation schedule for the Google Mobile Ads SDK

How does the change apply to existing versions?

Exceptions

Next Steps

Use the new Google Mobile Ads SDK getVersion() method

The Interactive Media Ads (IMA) SDK for Android moves to Google's Maven repository

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

Announcing v17.0.0 of the Android Google Mobile Ads SDK

Announcing the Mediation Test Suite Beta

Google Media Framework for Android is Deprecated

Use ad content filtering to help improve your users’ ad experience

Simpler testing with new AdMob test ads

New Test Ad Behavior

Test ads with Mediation

Deprecating GMF for Android

Loading multiple native ads in the Google Mobile Ads SDK

Kotlin and the Google Mobile Ads SDK

Implementation Guides

Questions?

ExoPlayer Releases IMA Extension

Labels

Archive