Best Offerwall SDKs for Android Apps in 2026

What is the best offerwall SDK for an Android app?

The best offerwall SDK for an Android app is the one that credits rewards to your own server through signed server-to-server postbacks, supports your app’s minimum Android version, and adds as little as possible to your build: few dependencies, few permissions, and no advertising ID unless you need it. Offer coverage in your users’ countries decides how much it earns, so test two or three before you commit. Among the SDKs with current Android documentation in October 2026 are Unity Offerwall (formerly Tapjoy), DT Offer Wall from Digital Turbine, AdGem, BitLabs, ayeT-Studios, and the Sharklio Android SDK.

This guide is about choosing. For step-by-step Kotlin code, see How to add an offerwall to an Android app. If you also need web walls for a site, the best offerwalls for publishers compares providers more broadly.

How to choose an Android offerwall SDK

An SDK becomes part of your app: whatever it collects, Google treats as collected by you. Check these points before you add one:

You can check the first five yourself in a few minutes. Download the AAR and POM from the provider’s Maven repository, open the AAR (it is a zip file), and read AndroidManifest.xml. That is exactly what we did for the comparison below. What is an SDK? covers the general trade-offs if you are new to the term.

Android offerwall SDKs compared

We downloaded the latest release of each SDK from its official Maven repository on October 22, 2026, and read its manifest and dependency list. The reward column comes from each provider’s developer documentation. Listed alphabetically, not ranked.

AAR size is the download, not what the SDK adds to your APK. R8 shrinks code, and dependencies such as Compose, Retrofit, or OkHttp add more unless your app already uses them. Versions move fast: AdGem’s docs still show 5.0.0 and ayeT-Studios’ show 1.0.3, while Maven had newer releases. Checked on October 22, 2026.

What each provider documents

• AdGem. The AdGem Android SDK docs require API level 23 and say the SDK collects the GAID and forwards it automatically when Google Play services is available, falling back to less reliable fingerprint matching without it. AdGem’s docs home marks server-to-server postbacks as the recommended reward path.
• ayeT-Studios. Its Android SDK v2 docs ask only for the internet permission and describe S2S conversion callbacks secured with an HMAC hash and an IP whitelist.
• BitLabs. The BitLabs Android SDK docs say SDK callbacks currently work only for surveys and that offers need the server-to-server callback, which BitLabs “highly recommends” anyway. The docs also tell you to update your Data safety form before publishing.
• DT Offer Wall. Digital Turbine’s Android integration page says the Offer Wall and DT FairBid ship in the same SDK, with Android 6.0 (API 23), Kotlin 2.1.0, and Google Play services 11.4.0 as prerequisites. Its SDK APIs page says the SDK includes the Google Ad ID in all communications with its backend by default, with a disableAdvertisingId option for Families apps.
• Unity Offerwall. Unity’s Android quickstart says the SDK checks for the Google Advertising ID by default and fails to initialize without it, unless you set DISABLE_ADVERTISING_ID_CHECK. Its FAQ says 16 KB page size support starts with SDK 14.1.0.
• Sharklio. The Sharklio Android SDK docs list Android 5.0 (API 21) with Android System WebView or Chrome, the internet permission only, and built-in R8 and ProGuard rules. The SDK is free under the Apache License 2.0.

Comparing Tapjoy with other options in more depth? Tapjoy alternatives covers that question.

Currency control and server-to-server postbacks

Every offerwall has to answer one question: who holds the user’s balance? There are two models.

• Provider-managed currency. The provider stores balances and your app asks for them. Unity’s virtual currency overview says Tapjoy-managed currency removes the need for a backend, but an app using it cannot support additional Tapjoy currencies, and you cannot migrate back to it once you switch to self-managed. DT’s DT-hosted currency works in a similar way.
• Self-managed currency. Balances live on your server, and the provider calls your callback URL for each reward. Unity lists more control, reward IDs for troubleshooting, and visibility into transactions as its advantages.

If your app has accounts and a backend, choose self-managed. A client-side callback such as onOfferwallRewardReceived is convenient, but anything that runs on the device can be faked on a rooted or modified phone. The safe flow is the same for every provider:

1. Your app asks your server to open the wall for the signed-in user ID.
2. The user completes an offer. The provider sends a signed postback to your server.
3. Your server checks the signature, ignores any transaction ID it has already processed, and adds the currency.
4. When a reward is reversed, your server takes the currency back or records the debt.
5. The app reloads the balance from your server when the wall closes.

Server-to-server tracking explains why only the postback can be trusted, how to prevent duplicate reward credits covers the transaction ID check, and postback security lists what to verify. Ask every provider whether reversals arrive as their own callbacks, because a wall that never tells you about reversals leaves you paying for rewards that the advertiser took back.

Advertising ID, permissions, and user privacy

Four of the six SDKs above depend on Google’s play-services-ads-identifier library, whose manifest declares the com.google.android.gms.permission.AD_ID permission. Google’s advertising ID help page says apps targeting Android 13 or higher must declare that permission to read the ID, and that an SDK’s AD_ID permission merges into your app’s manifest by default. So adding one of these SDKs quietly adds the permission to your app, even if your own code never reads the ID.

The same page says a user who deletes the ID returns a string of zeros to any app that asks, and that apps should use the advertising ID instead of other device identifiers for any advertising purpose. What are GAID and IDFA? explains the ID itself, and GAID deprecation in 2026 covers where it is heading.

If you must not send the advertising ID, for example in an app for a mixed audience that includes children, you can remove the merged permission. Unity’s docs show the manifest line:

<uses-permission android:name="com.google.android.gms.permission.AD_ID"
    tools:node="remove"/>

Test the result. Unity Offerwall fails to initialize without the advertising ID unless you set its flag, and AdGem says attribution gets less reliable without it. An SDK that never uses the ID avoids that trade-off.

How an offerwall SDK changes your Data safety form

Google’s Data safety help page is clear that you must declare data collected or shared by third-party libraries and SDKs in your app. “Collect” means transmitting data off the user’s device, and the “Device or other IDs” type includes advertising identifiers. Fraud prevention, security, and compliance is a purpose you select, not an exemption. Google suggests you check each SDK provider’s published Data safety information.

The answers differ by provider, which is a real point of comparison:

• Unity’s Offerwall Data safety guidance lists approximate location, app activity, app performance data, and device or other identifiers as collected and shared, for purposes that include analytics, fraud prevention, personalization, and advertising or marketing.
• Sharklio’s Android SDK docs list four data types: user IDs (the pseudonymous ID your server sends), device or other IDs (a device identifier for fraud prevention), approximate location (country, region, and city from the IP address), and app interactions (offers viewed, started, and completed). All are used for the offerwall to work and to prevent fraud, not for advertising, and the SDK does not track users across apps.

If you run several walls, your answers combine all of them. Also watch Play Console after release: Google’s third-party SDK help page says you get warnings for SDK versions their owners report as outdated or critical, have 90 days to update a version with critical issues, and can have releases rejected for an SDK version that breaks Play policy.

Build requirements that bite later

• Target API level. Android’s target API requirements say that from August 31, 2026, new apps and app updates must target Android 16 (API level 36), with extensions available to November 1, 2026. Ask whether the SDK is tested on that target.
• 16 KB memory pages. Android’s page sizes guide says apps targeting Android 15 and higher must support 16 KB pages on 64-bit devices, and from February 1, 2027 updates that do not cannot be released. Apps made only of Java or Kotlin code, including all their SDKs, already support it. An SDK with native libraries needs a version that supports 16 KB pages.
• Java and Gradle versions. AdGemAdGem’s SDK, for example, sets Java 17 in its build configuration examplersquo;s Android example project, for example, builds with Java 17. Check this before a release week, not during it.

Google Play policy for offerwalls in Android apps

Google Play does not ban opt-in rewarded offers inside your app, but its User Ratings, Reviews, and Installs policy forbids manipulating app placement, including through incentivized ratings and reviews and by “incentivizing users to install other apps as the app’s main functionality”. In practice:

• Keep the wall optional and make your app useful on its own. An app that is little more than a list of install offers is the pattern the policy describes.
• Never reward a rating or review, of your app or anyone else’s, and never show a reward next to a rating prompt.
• If your app targets children, Google’s Families policy requires Families self-certified ad SDKs and says apps that solely target children must not transmit the advertising ID. An offerwall is the wrong tool for that audience; see offerwalls in kids apps and COPPA.

Policy text changes, so read the live pages before you launch (checked on October 22, 2026). Incentivized installs and Google Play policy goes through each rule in detail.

Do you need an SDK at all?

Not always. Many walls, Sharklio included, also open from a signed link in a WebView or the browser. A link adds nothing to your APK and changes without an app update. An SDK handles the parts that are easy to get wrong in your own WebView: sending Google Play offers to the Play Store app, back and close buttons, rotation, and safe WebView settings. Offerwall integration: iframe, link or API? compares the paths.

Once you pick, placement decides how often users open the wall. Where to place an offerwall covers the entry points that work, and the virtual currency calculator helps you price rewards in your coins.

Frequently asked questions