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:
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:
AndroidManifest.xml
<manifest> <application> <!-- TODO: Replace with your real AdMob app ID --> <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."
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.
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%.
UnifiedNativeAd
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.
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
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:
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
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.
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:
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
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.
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.
For native advanced test ads, the headline asset has the text "Test Ad" prepended.
headline
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.
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.
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:
GADMultipleAdsAdLoaderOptions
numberOfAds
GADAdLoader
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.
-adLoader:didReceiveNativeAppInstallAd:
-adLoader:didReceiveNativeContentAd:
To determine when ads have finished loading, there are two new APIs available:
loading
true
false
GADAdLoaderDelegate
adLoaderDidFinishLoading:
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.
AdLoader
loadAds()
isLoading()
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
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.
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.
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.
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.
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.
Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.
In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android:
In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app.
In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this:
pod 'GoogleMobileAdsMediationMoPub'
...or their build.gradle file with a line like this:
compile 'com.google.ads.mediation:mopub:11.10.1.0'
With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section.
Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry.
To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter.
For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android).
If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.
With the advent of video players that support streaming media formats such as HLS and DASH, publishers can now easily support these formats with the IMA SDK for Android. Here is a list of steps to make this work:
The latter is done via the SDK's AdsRenderingSettings API. Create a new instance of AdsRenderingSettings and then create a list of MIME types you plan to support:
AdsRenderingSettings
AdsRenderingSettings adsRenderingSettings = ImaSdkFactory.getInstance().createAdsRenderingSettings(); ArrayList arrayList = new ArrayList(); arrayList.add("application/x-mpegURL"); //HLS arrayList.add("application/dash+xml"); //DASH adsRenderingSettings.setMimeTypes(arrayList);
Then initialize the AdsManager using these AdsRenderingSettings:
adsManager.init(adsRenderingSettings);
This will allow the SDK to choose streaming ad media to play in your video player. Make sure to add any additional MIME types you plan to support, such as MP4, as this approach assumes that any MIME types not passed in are not supported.
How do I play HLS ads using the IMA SDK for iOS?
The default video player used by the iOS IMA SDK supports HLS, so it is not necessary to set that in AdsRenderingSettings.
Will this work with the SDK-owned player?
No, currently you must use custom playback by implementing the VideoAdPlayer interface. For an example of how to do this, check out our guide on custom playback or AdvancedExample.
VideoAdPlayer
If you have any questions, feel free to contact us via the support forum.
If you've created a Native Express ad unit recently, you may have noticed a new template format alongside App Install and Content: Video App Install. In the past few weeks, AdMob has rolled out support for video assets in Native Ads Express, giving publishers a new way to create more engaging presentations for their users.
Enabling video demand for a Native Express ad unit is easy. Just open the ad unit's settings in the AdMob console, and look for the Ad type checkboxes at the top of the editor:
Check the checkbox marked "Video app install," and save the change. In a short while, your ad unit will start serving video creatives alongside the other two formats, with no code changes to your app required. That means you can update your existing apps to display this new format without redeploying to the Play Store or App Store.
An important thing to note is that video creatives are only available for ad units using the Large template size. The video player needs a certain amount of space, and the Large template ensures that it's available.
While there's no mobile code required to take advantage of Native Express Video, AdMob has introduced some new features to the API that allow publishers to customize the user experience. In particular, a new video options class (VideoOptions on Android, and GADVideoOptions on iOS) gives publishers a way to influence how the ads behave.
For example, the following code will cause video ads appearing in an Android NativeExpressAdView to begin playing with their audio on:
mAdView = (NativeExpressAdView) findViewById(R.id.adView); mAdView.setVideoOptions(new VideoOptions.Builder() .setStartMuted(false) .build());
App publishers can retrieve information about the video assets in their ads through the use of a video controller object (VideoController on Android, GADVideoController on iOS). The ad view classes for native express have been updated to include video controller properties that apps can grab and query for info like whether a video is present in the ad, and what its aspect ratio is. Even if the ad doesn't contain an video asset (or no ad has been loaded at all), you'll always get a valid reference to the ad view's video controller.
For example, here's a Swift snippet that shows how to check if an ad that just loaded contains a video asset:
func nativeExpressAdViewDidReceiveAd(_ nativeExpressAdView: GADNativeExpressAdView) { if nativeExpressAdView.videoController.hasVideoContent() { print("Received an ad with a video asset.") } else { print("Received an ad without a video asset.") } }
Native Express is designed to make implementing native ads easy, but if you have questions about how to get up and running or how you can best put it to use in your apps, stop by our support forum. The Mobile Ads Garage recently released an episode covering Native Express Video as well, with feature details and screencasts for iOS and Android:
Today we're excited to announce iOS and Android sample projects that display AdMob Native Express ads in a feed. These samples address a common use case for monetizing apps with feeds or lists of content. The iOS (Swift and Objective-C) apps display Native Express ads in a UITableView and the Android app shows them in a RecyclerView.
Native Express ads work well in lists of content for two reasons. First, impressions are not counted until the ad is on screen, which enables you to preload the ads ahead of time. Preloading can help with optimizing scroll performance by making sure the ad is ready to be displayed when the user scrolls through the list. Second, you have more control over the styling of the ads, allowing you to create presentations that fit naturally with your content.
You can check out these sample apps by downloading them from our iOS and Android GitHub repos, and you can see them being coded in the Mobile Ads Garage YouTube series. Episode 11 walks you through the implementation for adding native ads into an Android RecyclerView. Episode 12, which will cover the implementation of native ads in an iOS UITableView, is due out next week.
If you have any questions or feedback regarding our SDK, feel free to contact us through our forum.
Episode 11 of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
In a break with tradition, this video is a deep technical dive on one subject: Native Ads Express in an Android RecyclerView. You'll learn how to modify an existing RecyclerView implementation to include Native Express ads, all the way from updating the adapter to loading the ads. In addition, you'll get a clever trick that makes sure your ads are always sized to match the UI, so they fit right in with your content.
If you haven't used Native Ads Express before, you can see them in action in Episode 7. Andrew and Gary cover all the basics: loading ads, placing them in layouts and storyboards, and using CSS to style the ads to match your app.
If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.
We'd love to hear which AdMob features you'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.
Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.
On February 1, 2017, we will implement a new deprecation policy for the IMA SDKs for iOS and Android. The Flash and HTML5 SDKs are unaffected by this policy because they are downloaded at runtime, so all developers are always using the latest version.
Each release will be deprecated 12 months after its successor is released.
As of February 1, 2017, the following SDK versions will no longer be supported:
If you are currently on one of these versions, we strongly suggest upgrading to the latest version before the new policy takes effect.
Once an SDK version is deprecated, we cannot guarantee that version will continue to work. If we receive reports of crashes related to a deprecated version of the IMA SDK, we may discontinue serving ads to that version. We will also no longer field support requests for these versions on the IMA SDK support forum.
To maintain support, publishers on the latest version of an SDK will have 12 months to move to a new version once its successor is released. To "support" an SDK means we will investigate bugs in that SDK version and work on fixes. If a bug fix requires a change to the library itself, the fix will be applied to the newest version.
For a list of supported SDK versions and their deprecation dates, see the new deprecation schedule pages for iOS and Android. As always, if you have any questions, feel free to contact us via the support forum.
Integrating with the IMA SDK for Android has historically meant implementing the VideoAdPlayer interface and playing video ads in your content player. While this approach offers maximum flexibility, it also requires a lot of extra work to get up and running. In our mission to make developers' lives easier, we are proud to offer an alternative: SDK-owned ad playback, added in our newest release, v3.5.2.
Using SDK-owned ad playback, the SDK takes care of playing ads in its own player, allowing you to focus on content playback and the normal ad request flow in your player. With SDK-owned playback, you no longer have to implement a VideoAdPlayer, or worry about VideoAdPlayerCallbacks. Enabling SDK-owned playback is straightforward: simply omit the setAdPlayer call on your AdDisplayContainer.
AdDisplayContainer
With the new, simplified integration flow using SDK-owned playback, integrating with the IMA SDK for Android is easier than ever! For a step-by-step guide, head over to our revamped Get Started guide or download the BasicExample project from GitHub and try it out.
SDK-owned ad playback allows publishers to simplify their IMA implementation, but using it is not required. If you already have a VideoAdPlayer implementation or want to use a single video player for both ads and content, you can keep using custom playback. SDK-owned playback merely gives you the option to let the SDK handle some of the implementation complexity for you.
If you have any questions about SDK-owned playback, feel free to contact us via the support forum.
Episode 10 of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, the Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
Knowing what's going on with your ads is a big part of maintaining a great user experience. In the latest episode of the Mobile Ads Garage, you'll see how to tap into the ad lifecycle so your app's informed of loads, clickthroughs, and other key events. You'll also get a detailed breakdown of the steps that occur in the life of an ad, info about which classes and callbacks to use for common tasks like pausing game engines and muting audio, and a real world example of how to put it all together.
Following its launch at the 2016 Game Developer’s Conference, AdMob’s mediation support for rewarded video ads has been a hit with publishers and users alike, with rapid adoption on both Android and iOS platforms.
Our growing list of mediation partners includes eight different ad networks. Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of them, while you develop against a single API from AdMob. Now, with the launch of custom events for rewarded video, you can also request and display rewarded videos from ad networks that are not directly supported by AdMob.
Our implementation guide for rewarded video adapters (Android | iOS) outlines how to implement an adapter that can serve rewarded video ads from a third party ad network. Special attention should be paid to steps specific to custom events that are summarized below:
To define a custom event, you must first create it in the AdMob interface at apps.admob.com. You can find instructions for creating a custom event in this help center guide.
The optional server parameter passed to your custom event is accessed via a special key. Here’s an example showing how to access the value in a rewarded video adapter:
String parameter = serverParameters.getString( MediationRewardedVideoAdAdapter.CUSTOM_EVENT_SERVER_PARAMETER_FIELD);
NSString *parameter = [self.connector.credentials objectForKey:GADCustomEventParametersServer];
You can find additional documentation on rewarded video ads in our Get Started guides (Android | iOS), and more information about mediation is available in our mediation guides (Android | iOS). For any other questions about rewarded video mediation, you can reach us through our developer forum.
Episode nine of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
In this episode of The Mobile Ads Garage, we discuss mediation, which is a way for publishers to get multiple networks of advertisers competing to display ads in their apps. We’ll show you how AdMob mediation works and what it can do for your business. Learn the pros and cons of mediation, see the details of implementation, and find out whether it’s right for your app. You'll also get screencasts for Android and iOS showing the integration of a third-party SDK, plus links to samples, written resources, and Gary the Graphics Guy acting like his usual, snarky self.
We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.
We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.
This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.
The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.
The source code and a sample app for the plugin are available in our GitHub repo, as is a changelog for this release. If you have any questions about Unity integration, you can reach us on our developer forum.
