GMA Next-Gen SDK migration: 3 deadlines, 2 breaking changes and 1 mediation trap

Summary. On 6 July 2026 Google designated GMA Next-Gen SDK as the preferred mobile ads SDK for Android and reclassified Google Mobile Ads SDK 25.x.x as legacy. Three dates govern what happens next: the legacy SDK stayed supported through 1 July 2026, loses technical support on 30 June 2027, and sunsets on 30 June 2028, at which point ads are at risk of not serving and the SDK is reported as outdated, which blocks further app releases. The code migration is modest, on the order of a day for a single-format integration: AdRequest.Builder() now takes the ad unit ID, initialize() must run on a background thread, and every callback arrives off the UI thread. The expensive part is buried in the setup guide. GMA Next-Gen SDK works only with no mediation at all or with AdMob as the mediation platform; other mediation platforms are not compatible. It also raises the floor to minSdk 24 and compileSdk 34. For context on why Google cares, Alphabet reported Google Network revenue, the segment covering AdSense, AdMob and Ad Manager, down 4 percent year on year to $6.97 billion in Q1 2026.

The three dates that matter

Google's announcement, posted to the Google Ads Developer Blog by Natalia Vargas-Caba of Mobile Ads Developer Relations, describes GMA Next-Gen SDK as "a significant rewrite" of the Google Mobile Ads SDK. The deprecation clock it started applies to legacy version 25.x.x.

Stage	Date	Ads serve?	Google support?	Can you ship updates?
Supported	through 1 July 2026	Yes	Yes	Yes
Deprecated	from 30 June 2027	Yes	No	Yes
Sunset	from 30 June 2028	At risk of no fill	No	No, SDK reported as outdated
GMA Next-Gen v1.x.x	released 14 April 2026	Yes	Yes	Yes
GMA Next-Gen v0.x.x-alpha	deprecated 1 July 2026	Yes	No	Yes, until Q2 2027 sunset

The sunset stage is the one to plan around, and not because of the ad revenue. Google's documentation says ad requests from a sunset version return a no fill with an error indicating the version is sunset. The second consequence is worse for a product team: the outdated SDK designation prevents further app releases. A team that misses the date loses ad revenue and, worse, the ability to ship a bug fix.

GMA Next-Gen SDK has its own schedule already. Version 1.x.x shipped on 14 April 2026, is deprecated in Q1 2028 and sunsets in Q2 2029. The lifecycle rule is mechanical: when a new major version N is released, everything at N-2 is deprecated immediately and everything at N-3 sunsets roughly two months later. Google plans one major release in the first quarter of each year, so a version lives about two years supported and one year deprecated. Migrating once does not end the maintenance obligation; it resets a rolling three-year clock.

The mediation restriction is the actual decision

The setup guide states the constraint plainly: to use GMA Next-Gen SDK you must either integrate without mediation or use AdMob as the mediation platform, because other mediation platforms are not compatible with it.

For a large share of the app economy, that sentence is the whole story. Publishers running AppLovin MAX, ironSource or any other third-party mediation layer as their primary waterfall cannot adopt GMA Next-Gen SDK without changing mediation platforms. The 30 June 2028 sunset therefore is not a migration deadline for them; it is a platform decision with revenue consequences that need modelling, not a refactor a mobile engineer can schedule into a sprint.

Your setup today	What the sunset actually asks of you	Realistic effort
AdMob only, no mediation	Swap the dependency, fix the API changes	1 to 3 days per app
AdMob mediation with adapters	Same, plus the Gradle exclusion for duplicate symbols	3 to 5 days per app
Third-party mediation as primary	Move mediation to AdMob, or stay on legacy and lose ad serving in 2028	Weeks, plus revenue modelling
Flutter, Android and iOS	Opt in on Android only; iOS stays on the legacy line	2 to 4 days plus dual-SDK build config
iOS native	Nothing to migrate yet	Track the iOS deprecation table instead

Effort figures are eCorpIT estimates for planning, not vendor benchmarks. Model your own from the number of ad formats and adapters you run.

If you sit in the third row, do the arithmetic now rather than in 2027. You have until June 2028, which sounds generous until you price a mediation platform change against a revenue baseline you cannot A/B test cleanly.

The code changes, exactly

There are two changes that touch every integration and several that touch specific ones. None of them are difficult. All of them are silent failures if missed.

The dependency swap and the exclusion nobody reads

// Google Mobile Ads SDK (legacy)
implementation("com.google.android.gms:play-services-ads:25.4.0")

// GMA Next-Gen SDK
implementation("com.google.android.libraries.ads.mobile.sdk:ads-mobile-sdk:1.2.1")

Mediation adapters still depend on the legacy Google Mobile Ads SDK, and GMA Next-Gen SDK ships all the classes those adapters need. Without an exclusion you get duplicate symbol errors at compile time:

configurations.configureEach {
    exclude(group = "com.google.android.gms", module = "play-services-ads")
    exclude(group = "com.google.android.gms", module = "play-services-ads-lite")
}

The namespace moves wholesale from com.google.android.gms.ads.* to com.google.android.libraries.ads.mobile.sdk.*. That is a find-and-replace in most projects, with one exception worth knowing: InitializationStatus becomes InitializationConfig, which is a different object with a different job.

Initialization is now mandatory, and threading is not a suggestion

The legacy SDK recommended background-thread initialization to reduce Application Not Responding errors. GMA Next-Gen SDK requires it. Google's migration guide states that MobileAds.initialize() "must be called on a background thread, failure to do so may cause an 'Application Not Responding' (ANR) error", and that calling other MobileAds methods before initialization may throw an UninitializedPropertyAccessException.

val backgroundScope = CoroutineScope(Dispatchers.IO)
backgroundScope.launch {
  MobileAds.initialize(
    this@MainActivity,
    InitializationConfig.Builder("SAMPLE_APP_ID").build()
  ) {
    // Adapter initialization is complete.
  }
  // SDK initialization is complete. If you don't want to wait for bidding adapters
  // to finish initializing, start loading ads now.
}

Two details in that snippet repay attention. The AdMob app ID moves out of AndroidManifest.xml and into the initialization call, though the User Messaging Platform SDK still needs the app ID in the manifest, so consent-managing apps keep both. And the trailing lambda fires when adapter initialization finishes, not when SDK initialization finishes. SDK initialization is complete when initialize() returns, which means you can start loading ads without waiting for bidding adapters to settle. Teams that treat the lambda as a gate on first ad load are leaving startup latency on the table.

Ad requests carry the ad unit ID now

// Legacy
val adRequest = AdRequest.Builder().build()
InterstitialAd.load(
  this, "AD_UNIT_ID", adRequest,
  object : InterstitialAdLoadCallback() { }
)

// GMA Next-Gen SDK
val adRequest = AdRequest.Builder("AD_UNIT_ID").build()
InterstitialAd.load(adRequest, object : AdLoadCallback<InterstitialAd> {})

The load method drops both the Context and the ad unit ID, going from four arguments to two. Any wrapper class you built to hide the old signature needs rewriting, and any test double that mocks the four-argument call will compile against nothing.

Two builder methods were renamed at the same time:

Legacy	GMA Next-Gen SDK
AdRequest.Builder()	AdRequest.Builder("AD_UNIT_ID")
.addNetworkExtrasBundle(AdMobAdapter::class.java, extras)	.setGoogleExtrasBundle(extras)
.addNetworkExtrasBundle(SampleAdapter::class.java, extras)	.putAdSourceExtrasBundle(SampleAdapter::class.java, extras)
com.google.android.gms.ads.MobileAds	com.google.android.libraries.ads.mobile.sdk.MobileAds
InitializationStatus	InitializationConfig

The non-personalized-ads pattern survives unchanged in substance: you still put npa into a bundle, you just hand it over through setGoogleExtrasBundle and the AdMobAdapter class argument disappears.

Every callback now arrives on a background thread

This is the change most likely to ship a crash. Google's guidance is explicit: GMA Next-Gen SDK runs ad load and event callbacks on a background thread, and UI work inside those callbacks must be dispatched to the UI thread explicitly.

adView.loadAd(
  adRequest,
  object : AdLoadCallback<BannerAd> {
    override fun onAdLoaded(ad: BannerAd) {
      runOnUiThread {
        Toast.makeText(activity, "Ad loaded.", Toast.LENGTH_SHORT).show()
      }
    }
  },
)

Per-format callback classes such as InterstitialAdLoadCallback give way to a generic AdLoadCallback<T>. If your existing callbacks touch a view, update a LiveData on the main thread, or call into a UI framework that asserts thread affinity, they will now throw at runtime rather than at compile time. Grep every ad callback for view access before you ship, because the compiler will not find these for you.

The API floor moved

GMA Next-Gen SDK requires a minimum Android API level of 24 and a compile API level of 34. If you still support API 21 or 23 devices for a specific market, that decision now has an ad-revenue consequence attached, and it is worth checking against your own install base before the migration is scheduled.

What Google says you get, and how to read those numbers

Google's benefits page lists up to 27 percent faster ad request latency for banner ads against the previous SDK, a smaller on-device size, background startup to reduce app launch impact, and removal of remote procedure calls, which cuts crash risk from process communication failures. The SDK is written in Kotlin with Kotlin and Java APIs.

The latency figure carries a footnote worth reading: it is Google internal data, measured on banner ads between 21 August and 3 September 2025. At the January 2026 beta launch Google published a 27 percent reduction in banner ad latency alongside a 17 percent cut in device footprint, and cited early adopters reporting a 36 percent eCPM increase over a three-week test, a 16 percent fill rate increase, a one-third reduction in Application Not Responding rates and a 50 percent cut in slow cold starts.

Treat that second set as vendor-reported anecdotes from named beta participants, not as an expected outcome. Every one of those figures came from Google's own announcement material during a beta, on unnamed apps, with no published methodology. The structural claims, no RPCs and background initialization, are verifiable in the SDK's own behaviour and matter more than the percentages. The real cost of waiting is not the missed eCPM; it is the 2028 release block.

iOS and Flutter are on different tracks

This is where cross-platform teams get their planning wrong, because the Android story does not transfer.

On iOS there is nothing to migrate. Google's iOS deprecation page shows only the legacy line: v13.x.x released 4 February 2026 and supported, v12.x.x released 3 February 2025 and supported, v11.x.x deprecated as of 4 February 2026 with a Q2 2027 sunset, and versions 6.x.x and below with ad serving already disabled. There is no GMA Next-Gen SDK for iOS in that documentation set. An iOS team's obligation is the ordinary annual major-version treadmill, not a rewrite.

Platform	Next-Gen available?	What you track	Nearest hard date
Android native	Yes, v1.x.x since 14 April 2026	Legacy 25.x.x sunset	30 June 2028
iOS native	Not in the current documentation	Legacy v11/v12/v13 schedule	Q2 2027 for v11.x.x
Flutter, Android side	Yes, opt-in behind a build flag	Plugin version and flag rollout	Follows Android
Flutter, iOS side	No	iOS dependency schedule	Follows iOS
Unity	Legacy documentation only	Unity plugin schedule	Check the Unity table

The Flutter plugin's sunset rule is the trap: Google states that if either the Android or the iOS dependency of a plugin version is sunset, the entire plugin version can be considered sunset. Your Flutter release is gated by whichever platform dependency expires first, which is usually not the one you have been watching.

Flutter teams can opt into GMA Next-Gen SDK on Android today. Google's guide requires Google Mobile Ads Flutter Plugin 9.0.0 or later and an environment declaration:

flutter run --dart-define USE_NEXT_GEN_SDK=true

Native ad templates need two edits: the import changes from io.flutter.plugins.googlemobileads.GoogleMobileAdsPlugin.NativeAdFactory to io.flutter.plugins.googlemobileads.NativeAdFactory, and the layout element changes from com.google.android.gms.ads.nativead.NativeAdView to com.google.android.libraries.ads.mobile.sdk.nativead.NativeAdView. Google documents a pattern for supporting both SDKs at once by defining dependencies conditionally in android/app/build.gradle against the environment declaration, which is the right way to stage a rollout behind a flag. One caution: Google's own Flutter deprecation table tops out at plugin 6.x.x while the opt-in guide asks for 9.0.0 or later, so confirm the current plugin version on pub.dev before you plan the work.

Teams already running a Flutter upgrade should fold this into that work rather than run it separately. Our Flutter 3.44 production upgrade guide covers the sequencing for a plugin-heavy app.

Migration order that avoids a revenue dip

Ad SDK changes are the rare migration where the regression is invisible in QA and obvious in the revenue dashboard three days later. Sequence accordingly.

1. Audit mediation first. If a third-party platform is your primary mediation layer, stop and make the platform decision before touching code.
2. Check minSdk against your install base. Below API 24, decide who you are dropping.
3. Migrate one format in one app, behind a staged rollout. Banner or interstitial, not native.
4. Grep every ad callback for UI work and wrap it. This is the crash source.
5. Move the app ID from the manifest into InitializationConfig, and leave the manifest entry in place if you use the User Messaging Platform SDK.
6. Compare eCPM, fill rate and ANR rate against the previous build for at least a week before widening the rollout.
7. Only then migrate the remaining formats and apps.

Google also ships an agent skill named google-mobile-ads-android-migrate-to-next-gen for AI-assisted migration, alongside the manual guides and a gma-next-gen-sdk-android-examples sample repository. An agent handles the mechanical namespace and signature edits well. It will not audit your mediation contracts or catch a callback that mutates a view, which is exactly where this migration hurts. Use it for step 3 and do steps 1, 4 and 6 yourself.

India-specific considerations

Two things change the calculation for Indian app teams.

The first is device mix. An API 24 floor removes a slice of the low-end Android install base that still matters in India, and ad-monetised apps are exactly the category where that tail carries volume. Pull your own Play Console distribution before accepting the floor as costless; the answer differs sharply between a fintech app and a casual game.

The second is consent. Ad SDKs process personal data, and the User Messaging Platform SDK is how consent reaches the ad stack. Under the Digital Personal Data Protection Act, 2023, penalties are fixed rupee amounts in the Schedule rather than a share of turnover, assessed per instance, with a ceiling of ₹250 crore for failure to take reasonable security safeguards and ₹200 crore for failure to notify a breach. Because the app ID stays in the manifest for the User Messaging Platform SDK while moving into code for the ads SDK, the migration is a natural moment to re-verify that consent state actually gates ad requests rather than merely being collected. Our DPDP Act engineering playbook covers where consent enforcement belongs in a mobile stack.

Indian publishers should also read this against the wider platform picture rather than in isolation. Google Play's own billing and fee changes land in the same period, and the two together reshape unit economics for a monetised app. Our analysis of the Google Play service fee split and the Play Billing Library 8 migration deadline covers that side, and the enterprise mobile app development guide sets out how these deadlines stack across a portfolio.

FAQ

When does the legacy Google Mobile Ads SDK stop working?

The legacy SDK sunsets on 30 June 2028. From that date ads are at risk of not serving, returning a no fill with a sunset error, and the SDK is reported as outdated, which prevents further app releases. Technical support ends earlier, on 30 June 2027, while ads continue serving through that stage.

Can I keep my current mediation platform on GMA Next-Gen SDK?

Only if that platform is AdMob. Google's setup guide states you must either integrate without mediation or use AdMob as the mediation platform, because other mediation platforms are not compatible with GMA Next-Gen SDK. Publishers running a third-party waterfall face a platform decision rather than a code migration.

What is the minimum Android API level for GMA Next-Gen SDK?

GMA Next-Gen SDK requires a minimum Android API level of 24 and a compile API level of 34. Teams still shipping to API 21 or 23 devices need to check that decision against their install base, because those users will not receive a build carrying the new ads SDK.

Is there a GMA Next-Gen SDK for iOS?

Not in Google's current iOS documentation. The iOS deprecation page shows only the legacy line, with v13.x.x released 4 February 2026, v12.x.x supported, and v11.x.x deprecated since 4 February 2026 with a Q2 2027 sunset. iOS teams track the ordinary annual major-version schedule instead.

How do Flutter apps adopt GMA Next-Gen SDK?

It is opt-in and Android-only. Google's guide asks for Google Mobile Ads Flutter Plugin 9.0.0 or later, then an environment declaration passed as --dart-define USE_NEXT_GEN_SDK=true. Native ad templates need an import change and a layout element change, and Google documents a pattern for supporting both SDKs at once.

What breaks silently rather than at compile time?

Callbacks. GMA Next-Gen SDK runs ad load and event callbacks on a background thread, so any UI work inside them must be dispatched to the UI thread explicitly. The compiler will not flag it. Initialization is the other one: calling MobileAds methods before initializing may throw an UninitializedPropertyAccessException.

Are Google's performance figures reliable?

The 27 percent banner latency improvement carries a footnote naming it Google internal data measured between 21 August and 3 September 2025. The beta figures for eCPM, fill rate and Application Not Responding rates came from unnamed early adopters in Google announcement material. Treat them as vendor-reported directional signals, not as forecasts.

How long does the migration actually take?

For an AdMob-only integration with one or two ad formats, the code work is small: a dependency swap, a namespace replace, an initialization move and a callback audit. The schedule risk sits in staged rollout and revenue comparison, which needs at least a week of data per app before widening.

How eCorpIT can help

eCorpIT builds and maintains monetised Android, iOS and Flutter apps for product teams in India and abroad, and SDK deadlines like this one are portfolio work rather than single-app work. Our senior engineering teams handle mediation assessment, staged ad SDK rollouts with revenue comparison, and the consent plumbing that connects the User Messaging Platform SDK to your ad requests, and we design applications aligned with DPDP Act requirements. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified. If you are weighing a mediation platform change against the June 2028 sunset, talk to our mobile engineering team.

References

1. Deprecation and sunset, GMA Next-Gen SDK for Android — Google, timetable and lifecycle rules.
2. Learn the benefits of GMA Next-Gen SDK — Google, performance claims and their footnote.
3. Initialize GMA Next-Gen SDK — Google, dependency swap, exclusions, API levels and mediation constraint.
4. Handle callbacks from background thread — Google.
5. Migrate ad requests — Google, AdRequest and builder method changes.
6. Deprecation and sunset, iOS — Google, iOS version timetable.
7. Deprecation and sunset, Flutter — Google, plugin timetable and the dependency sunset rule.
8. Use GMA Next-Gen SDK with the Flutter plugin — Google, opt-in flag and template changes.
9. Google forces Android developers off legacy Mobile Ads SDK by 2028 — PPC Land, Luis Rijo, 12 July 2026.
10. Google's new Android SDK promises to double your mobile ad speed — PPC Land, January 2026 beta figures.
11. Alphabet Q1 2026: Google Network ad revenue falls 4% — PPC Land.
12. Penalties and adjudication under India's DPDP Act, 2023 — King Stubb & Kasiva.

Last updated: 4 August 2026.