The Capacitor AdMob Plugin Built on Google's Next-Gen Ads SDK

Google operates two Android ad SDKs concurrently, one of which will be discontinued. If you choose an AdMob library for a Capacitor app this year, this crucial detail should influence your decision. We have unveiled the Capacitor AdMob plugin, the inaugural Capacitor-compatible AdMob plugin constructed upon Google's Next-Gen Mobile Ads SDK.

This marks our contribution, made available as part of Capawesome Insiders, a premium subscription offering. The remainder of this report serves as a condensed version of the comprehensive announcement published on our official blog. Understanding the Significance of the Next-Gen SDK The current Google Mobile Ads SDK for Android is at version 24 or 25, with Google announcing a deprecation timeline for both.

These versions will reach their sunset date on June 30, 2028, and their respective deprecation date on June 30, 2027. Upon sunset, ads may fail to display, with sunset ad requests yielding no fill. The alternative is the GMA Next-Gen SDK. It is disseminated as a new Kotlin-based artifact, com.google.android.libraries.ads.mobile.sdk, featuring a distinct API structure rather than an upgraded major version of the outdated library, which is why plugin developers must port rather than simply elevate a version number.

Our plugin operates on the Next-Gen SDK from its initial release, defaulted to ads-mobile-sdk 1.2.1 on Android, and the most recent Google Mobile Ads SDK on iOS, where Google has not yet released a Next-Gen variant. Both dependency versions are managed via Gradle project variables, enabling you to assign $adsMobileSdkVersion and $userMessagingPlatformVersion in variables.gradle when another plugin inadvertently introduces a distinct version.

Google's ad ecosystem comprises five formats: banner, interstitial, rewarded, rewarded interstitial, and app open. Our plugin supports each of these formats. Regardless of the full-screen format, the process involves a load method that returns an identifier and a show method that utilizes it, simplifying the learning curve. Below is an example of a rewarded ad, with the reward listener registered prior to the ad's appearance: import { Admob } from "@capawesome-team/capacitor-admob"; const showRewardedAd = async () => { await Admob . addListener ( "rewardEarned", ({ amount , type }) => { grantReward ( amount , type ); }); const { id } = await Admob . loadRewardedAd ({ adUnitId : "ca-app-pub-3940256099942544/5224354917" , }); await Admob . showRewardedAd ({ id }); }; Simply substitute loadRewardedAd with loadInterstitialAd, loadRewardedInterstitialAd, or loadAppOpenAd, and the underlying code remains unchanged.

By returning separate identifiers for each load call, you can manage multiple ads concurrently - for instance, preloading one interstitial ad for the conclusion of a level and maintaining a rewarded ad ready behind a "watch for coins" button. You can assign your preferred identifiers or accept the plugin's generated ones. The rewarded formats accommodate a server-side verification option, allowing you to transmit a userId and customData to your verification callback, ensuring that the reward is granted based on Google's recorded data rather than the client's self-reporting.

App open ads have a streamlined process: enableAppOpenAutoShow(...) loads and displays an ad each time the app transitions to the foreground, with a default minimum interval of 14400 seconds, and it remains inactive while a consent form or another full-screen ad is displayed. AdMob is exclusively available for Android and iOS platforms; attempts to use it on the web will result in an "unimplemented" error.

Banner ads present unique challenges, as they are native views overlaid on a web view that is unaware of their existence. The plugin provides three banner placement options, each suited to different web layouts. By default, the overlay mode places the banner at the top or bottom edge of the web view, respecting safe area insets.

If your CSS already reserves space for banners, the resize mode can be employed, allowing the web view to contract so the banner remains visible without altering your CSS structure. You would specify the ad unit, size, and position in this case. Inline placement is ideal for positioning the banner between list items, requiring an anchor element's bounding rectangle and the banner frame when the layout changes.

Multiple banners can be managed simultaneously by retaining the returned identifier, which is also used by methods to hide, resume, or remove the banners. Seven banner sizes are offered, including AdaptiveBanner (which adjusts the height based on the screen or frame width), InlineAdaptiveBanner (limited by the specified frame height), and fixed sizes such as 320x50, 320x100, 300x250, plus 468x60 and 728x90 for tablets.

The collapsible property can be enabled to allow the banner to expand into a larger ad and then return to its original size, triggering a bannerSizeChanged event to update your layout accordingly. Google mandates User Messaging Platform consent before requesting any ads from users in the European Economic Area, the UK, or specific US states.

The requestConsent(...) method handles both obtaining consent information and presenting a conditional form, streamlining the compliance process.