We’ve seen an increase in support questions recently on fatal and non-fatal errors in the IMA SDKs, so we’re here to explain when and why each is fired, and how you should handle one versus the other.
Simply put, a fatal error is fired by the SDK when there is no chance for the SDK to play an ad for the remainder of the current video. There are two common scenarios for fatal ad errors. The first is when the SDK itself fails to load. The second (and more common) is when you are requesting one and only one ad, and that ad request fails to return a valid ad.
A non-fatal error is fired by the SDK when something goes wrong with an ad, but the SDK could potentially play other ads. The most common scenario for a non-fatal error occurs when you’re requesting a pod or playlist of ads, and one ad fails to load. Because it could still play other ads in that pod or playlist, the SDK fires a non-fatal error and moves on to attempt the next ad.
Fatal errors are what we call “top-level” errors. They trigger one of the following events, depending on your particular SDK:
Non-fatal errors are wrapped in a LOG type AdEvent. That event is sent to your AdsManager event listener or delegate. You can access the error message from the LOG event as follows:
When you get a fatal error, you should destroy your AdsManager and play your content video. When you get a non-fatal error, you are not obliged to do anything for video and ad playback to continue - you can log the error message using the snippets shown in the table above for informational purposes.
As always, if you have any questions, feel free to contact us via the support forum.
It’s common to have multiple applications access your DFP network(s) when integrating with DFP. How you keep track of these applications and their authentication credentials can be just as important as writing code, particularly if you work with many other developers, or on more than one application. You want to avoid scenarios where you don’t know who or what is accessing your network, or where you can’t determine who owns the Google API Console project from which a set of OAuth2 credentials were generated. Here are some best practices to help mitigate this.
Similarly, when choosing a Google account for DFP API authentication, you may want to consider an OAuth2 service account. That way, all members of an API Console project can easily access this account’s credentials through the console. This is much better than using an arbitrary individual’s account for authentication in case that person leaves your team, or has their account disabled.
This is particularly troublesome during sunsets when we send out emails identifying which application names are making calls to your network(s) using a deprecated API version. It’s difficult to track down what an application is doing, or who owns it, when it’s named something like "abcxyz". Here are some examples of better application names:
As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.
- Vincent Tsao, DFP API Team
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,asisa changelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.
See the code snippets to learn how to use this feature. As always, let us know your questions and feedback on our developer forum.
- Anash P. Oommen, AdWords Scripts Team
UserList.isEligibleForSearch = false
isEligibleForSearch
get
query
IsEligibleForSearch
IsEligibleForDisplay
criterion
UserList
With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.
Firebase/AdMob
Google-Mobile-Ads-SDK
With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendaror Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:
"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."
"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."
The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.
To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.
mraid.createCalendarEvent()
mraid.storePicture()
mraid.supports("calendar")
mraid.supports("storePicture")
false
If you have any questions regarding these changes, please contact us through our forum.
ExperimentService
As a result of this expanded functionality, the ExperimentService will be sunset. If you’re still using the ExperimentService, please take the time to update your code to use campaign drafts and experiments instead.
On February 1, 2017, all experiments running via the ExperimentService will be stopped. After this date, all ExperimentService experiments will be deleted, stats will be unavailable, and API calls to the ExperimentService across all API versions will result in an error.
Please move off the ExperimentService before February 1, 2017 to ensure that you are able to continue running experiments.
If you have any questions, please post on the forum.
- Mike Cloonan, AdWords API Team
Additionally, increasing the runtime requirement allows us to make use of new framework functionality, to further improve and modernize the library.
If you have any questions or concerns, feel free to open an issue on the client library's issue tracker.
- Jonathon Imperiosi, Ads Developer Relations Team
