{"id":368,"date":"2025-12-23T08:14:37","date_gmt":"2025-12-23T08:14:37","guid":{"rendered":"https:\/\/gtaroads.com\/blog\/?p=368"},"modified":"2026-10-17T17:32:27","modified_gmt":"2026-10-17T17:32:27","slug":"creating-and-publishing-an-android-sdk-a-simple-step-by-step-guide-that-actually-works","status":"publish","type":"post","link":"https:\/\/gtaroads.com\/blog\/creating-and-publishing-an-android-sdk-a-simple-step-by-step-guide-that-actually-works\/","title":{"rendered":"Ad SDK for App Monetization: How to Choose and Integrate One on Android"},"content":{"rendered":"\n

An ad SDK is a library you add to your app so it can request, show and count ads from an ad network. Its job is to turn your app’s users into ad revenue without you building an ad server. Which SDK you choose decides how much you earn per user. How you integrate it decides whether that revenue costs you crashes, slow screens and bad reviews.<\/p>\n\n\n\n

This guide is for Android developers and app owners who are choosing a monetization SDK. It covers what the SDK actually does, network SDKs vs mediation, how to compare options, the integration steps that matter, and the numbers to watch after launch.<\/p>\n\n\n\n

What an ad SDK does inside your app<\/h2>\n\n\n\n

From your code it looks like a few calls: initialize, load an ad, show it. Under the hood, the SDK handles the whole cycle for every impression:<\/p>\n\n\n\n

    \n
  1. Ad request.<\/strong> The SDK sends the ad server what it needs to pick an ad: placement, format, device, OS version, country, and (with consent) the advertising ID.<\/li>\n\n\n\n
  2. Auction or selection.<\/strong> The network picks the best-paying ad, either from its own advertisers or through a real-time auction.<\/li>\n\n\n\n
  3. Loading and caching.<\/strong> Creatives (images, video, HTML) are downloaded and cached so the ad is ready when the user reaches the placement.<\/li>\n\n\n\n
  4. Rendering.<\/strong> The SDK draws the ad in a banner view, a full-screen activity, or your native layout.<\/li>\n\n\n\n
  5. Tracking.<\/strong> Impressions, clicks and video completions are reported back. This is what you get paid for.<\/li>\n\n\n\n
  6. Consent and privacy.<\/strong> The SDK reads the user’s consent signal and limits data collection if the user said no.<\/li>\n<\/ol>\n\n\n\n

    All of this runs inside your app’s process, with your app’s memory, network and battery. That is why SDK quality matters as much as the eCPM it promises.<\/p>\n\n\n\n

    Ad network SDK vs mediation SDK<\/h2>\n\n\n\n

    There are two kinds of monetization SDKs, and most apps end up using both.<\/p>\n\n\n\n

    <\/th>Ad network SDK<\/th>Mediation SDK<\/th><\/tr><\/thead>
    What it is<\/td>Connects your app to one network’s demand<\/td>Connects many networks and picks the best ad for each impression<\/td><\/tr>
    How the winner is chosen<\/td>The network’s own selection<\/td>Waterfall<\/a> (networks asked one by one) or in-app bidding (all networks bid at once)<\/td><\/tr>
    Good for<\/td>Small apps, one main market, simple setup<\/td>Apps with traffic in many countries, where no single network fills everything at a good price<\/td><\/tr>
    Cost<\/td>One integration<\/td>Mediation SDK plus an adapter for every network you add<\/td><\/tr>
    Risk<\/td>Low fill in markets the network doesn’t cover well<\/td>More code, more dependencies, more things to update<\/td><\/tr><\/tbody><\/table>
    Network SDK vs mediation: start with one network, add mediation when fill or eCPM in key countries stops growing.<\/figcaption><\/figure>\n\n\n\n

    In-app bidding works like real-time bidding on the web<\/a>: every connected network bids for the impression at the same moment, and the highest bid wins. It usually beats a manually tuned waterfall because prices update per impression rather than per setting.<\/p>\n\n\n\n

    Ad formats in apps and where each fits<\/h2>\n\n\n\n
    Format<\/th>What the user sees<\/th>Where it fits<\/th><\/tr><\/thead>
    Banner<\/td>A strip at the top or bottom of the screen<\/td>Utility and reading apps with long screen time; low revenue per impression<\/td><\/tr>
    Interstitial<\/td>A full-screen ad between screens<\/td>Natural breaks: after a level, after a finished task. Never in the middle of an action<\/td><\/tr>
    Rewarded<\/td>A video the user chooses to watch for a reward<\/td>Games and freemium apps; highest eCPM and the least annoying, because the user opts in<\/td><\/tr>
    Native<\/td>An ad styled like your own content<\/td>Feeds, lists, content apps; needs careful layout work and a visible “Ad” label<\/td><\/tr>
    App open<\/td>A full-screen ad when the app starts or returns from background<\/td>Apps opened many times a day; cap the frequency or it hurts retention<\/td><\/tr><\/tbody><\/table>
    Common in-app ad formats. Most apps combine two or three of them.<\/figcaption><\/figure>\n\n\n\n

    How to choose an ad SDK: 8 checks<\/h2>\n\n\n\n

    Ignore the headline eCPM on a network’s landing page. It comes from their best countries and formats, not yours. Check these instead:<\/p>\n\n\n\n

      \n
    1. Demand in your countries.<\/strong> Ask for eCPM and fill rate in your top 5 GEOs for your formats, or run a test on part of your traffic. A network strong in the US can be weak in India or Brazil.<\/li>\n\n\n\n
    2. Formats you need.<\/strong> Rewarded and native are not supported everywhere, and native quality varies a lot.<\/li>\n\n\n\n
    3. Mediation and bidding support.<\/strong> If you plan to use mediation, check that the network has an official adapter for your mediation platform, ideally with bidding.<\/li>\n\n\n\n
    4. Weight and startup cost.<\/strong> Build your app with and without the SDK and compare the size of the release bundle and cold start time. Check which libraries it pulls in transitively (OkHttp, Play Services, ExoPlayer and so on). Version conflicts there are a common source of crashes.<\/li>\n\n\n\n
    5. Stability.<\/strong> Ask how often the SDK is updated and look at its changelog. A good SDK has regular releases with fixes for new Android versions. Check reviews from other developers for crash and ANR reports.<\/li>\n\n\n\n
    6. Privacy and policy compliance.<\/strong> The SDK must read TCF consent signals and be declared correctly in Google Play’s Data safety form. If your app is for children, use only SDKs self-certified under Google Play’s Families policy.<\/li>\n\n\n\n
    7. Payments.<\/strong> Payment schedule, minimum payout, payment methods, and whether earnings are ever held back.<\/li>\n\n\n\n
    8. Reporting and support.<\/strong> Reports by country, format and placement, a reporting API for your own dashboards, and a person who answers when fill drops.<\/li>\n<\/ol>\n\n\n\n

      How to integrate an ad SDK on Android<\/h2>\n\n\n\n

      Every network has its own API, so follow its documentation for exact calls. The steps below apply to any SDK and are where most integrations go wrong.<\/p>\n\n\n\n

      1. Add the dependency from the official source<\/h3>\n\n\n\n

      Add the SDK through Gradle from the vendor’s official repository (Maven Central, Google Maven, or the repository URL in the vendor’s docs). Pin an exact version instead of a “+” range, so a new release can’t change your build without you knowing.<\/p>\n\n\n\n

      3. Initialize once, early, and off the main thread if the SDK allows it<\/h3>\n\n\n\n

      Initialize in your Application<\/code> class, not in every activity. If the SDK supports background initialization, use it. Heavy work on the main thread at startup is a direct path to ANRs.<\/p>\n\n\n\n

      4. Use test ads while you build<\/h3>\n\n\n\n

      Register your devices as test devices or use the network’s test ad units. Clicking your own live ads can get the account flagged for invalid traffic and suspended.<\/p>\n\n\n\n

      5. Place ads at natural breaks and cap frequency<\/h3>\n\n\n\n

      Preload full-screen ads before the moment you need them, so the user never waits. Show interstitials at transitions, not on app launch and not over a button the user is about to tap. Set a frequency cap: one full-screen ad every few minutes is a common starting point. Then tune it against retention, not just revenue.<\/p>\n\n\n\n

      6. Respect the lifecycle<\/h3>\n\n\n\n

      Pause and resume banner views with the activity, and destroy banner and native ad objects in onDestroy()<\/code>. An ad view that keeps a reference to a closed activity leaks memory. Over a long session, that ends in lag and out-of-memory crashes. Run LeakCanary in debug builds to catch this early.<\/p>\n\n\n\n

      7. Add the R8\/ProGuard rules<\/h3>\n\n\n\n

      Many SDKs use reflection. If the vendor’s keep rules are missing, R8 can strip or rename classes the SDK needs, and ads silently stop working only in release builds. Copy the rules from the docs and test a release build, not just debug.<\/p>\n\n\n\n

      8. Publish app-ads.txt<\/h3>\n\n\n\n

      app-ads.txt is a text file that lists which ad networks are allowed to sell your app’s inventory. It sits at the root of the developer website listed on your Google Play page. Many buyers don’t bid on inventory they can’t verify, so a missing or outdated file costs revenue. Update it every time you add a network.<\/p>\n\n\n\n

      9. Update your Google Play declarations<\/h3>\n\n\n\n

      In Play Console, mark that the app contains ads. Update the Data safety form with the data the ad SDK collects: most collect device identifiers and approximate location. The vendor usually documents what to declare.<\/p>\n\n\n\n

      10. Roll out gradually and watch Android vitals<\/h3>\n\n\n\n

      Release the version with ads to a small share of users first. Google Play can lower visibility for apps above its bad behavior thresholds: a 1.09% user-perceived crash rate and a 0.47% user-perceived ANR rate overall. If either jumps after the SDK goes in, stop the rollout before it reaches everyone.<\/p>\n\n\n\n

      Metrics to watch after launch<\/h2>\n\n\n\n