Tag Archives: deprecation

Deprecation of DBM API v1 and SDF Download Service

Today we’re announcing the deprecation of the Doubleclick Bid Manager (DBM) API v1 and the DBM API v1.1 Structured Data File (SDF) Download service. These services will no longer be supported and will be fully sunset on June 15, 2020. Refer to the table below to verify if methods you’re using will be available in v1.1 after June 15, 2020:


Service Methods Available in v1.1 after June 15, 2020?
Reporting queries.createquery
queries.deletequery
queries.getquery
queries.listqueries
queries.runquery
reports.listreports
Yes
Line Item Settings lineitems.downloadlineitems
lineitems.uploadlineitems
Yes
SDF Download sdf.download No. Use the new Display & Video 360 API instead.



If you are using the DBM API v1 Line Item Settings service or Reporting service, you must migrate to v1.1 by the sunset date to avoid an interruption of service. Consult the API release notes for the finer details of the changes between v1 and v1.1. Important things to know are:
  • Queries created and accessed through the Reporting service require more specific filters in the params.groupBy field in v1.1. You might have to add more values to the params.groupBy field in order to create the same report structure they generated in v1.
  • Responses from listqueries and listreports calls are paginated in v1.1. Users have to update their implementation to traverse multiple pages if they wish to consume more than the first 100 items returned.
  • The Line Item Settings service had no changes between v1 and v1.1. Users only have to update the version they are using.
The SDF Download service is deprecated in DBM API v1 and v1.1. Users should immediately migrate to the new Display & Video 360 API, which was released earlier this week. The Display & Video 360 API offers a new asynchronous SDF Download Service featuring new filter options and a new download format compared to its DBM API counterpart.

Guides are available to help you set up the new Display & Video 360 API, as well as use it to get started downloading SDFs.

Changes to stats retrieval for Search campaigns with Display Expansion

What’s changing?

We are changing how stats for Search campaigns with Display Expansion (previously known as Search campaigns with Display Select) are reported by the AdWords API, the Google Ads API, and Google Ads scripts.

Starting the week of Feb 17, 2019, we will no longer return display keyword stats for Search campaigns with Display Expansion in

Why is this changing?

Search campaigns with Display Expansion historically used keywords to perform Display Expansion. As we strive to improve targeting for Display Expansion, it is no longer possible to meaningfully and consistently attribute stats to keywords. As a result, this view has been removed from the Google Ads UI. The changes in this announcement aim to create parity between APIs and UI.


What should I do?

Before the sunset date, we recommend switching to alternate reports for fetching stats for Search campaigns with Display Expansion.

If you have any questions or need help, please contact us via the Google Ads scripts forum or the AdWords API and Google Ads API forum.

Google Play Instant feature plugin deprecation

Posted by Miguel Montemayor and Diana García Ríos

As of Android Gradle plugin 3.4.0 (included in Android Studio 3.4), we are starting the deprecation process of the feature plugin (com.android.feature) and instant app plugin (com.android.instantapp) as a way to build your instant app. When building your app, you will receive a warning flagging com.android.feature as deprecated. If you have an existing instant app built with the feature plugin, migrate your existing app to an instant-enabled app bundle as soon as possible.

What is changing?

Last year, we introduced Android App Bundles—a new way to build and publish your Android apps. App bundles simplify delivering optimized APKs, including instant delivery, by unifying uploads into a single artifact. Google Play handles distribution by serving the correct APKs to your instant and installed app users—this is called Dynamic Delivery. To learn more about app bundles, visit the documentation site.

Dynamic Delivery is based on the idea of shipping dynamic features (com.android.dynamic-feature) to app users when they need them and only if they need them. There are currently three delivery types, based on the different values you will give the dist:module tag attributes on the dynamic feature module’s manifest file:

    <dist:module
       dist:instant="..."
       dist:onDemand="..."
       ...
    </dist:module>
dist:instant="false" dist:instant="true"
dist:onDemand="false" Dynamic feature delivered at install time Dynamic feature delivered instantly and at install time
dist:onDemand="true" Dynamic feature delivered on demand (beta) N/A

By migrating your instant app to an instant-enabled app bundle with dynamic features, you will be ready to leverage the full power of this new paradigm and you will be able to simplify your app’s modular design.

The migration

Previously, instant apps required creating a feature module that acted as the base module for your app. This base feature module contained the shared code and resources for both your instant and installed application. The rest of your codebase was comprised of:

  • multiple non-base feature modules, which contained the instant app entry points,
  • an application module, which contained the code and activities required only for your main installed application, and
  • an instant app module, which represented the instant app and mapped its dependencies.

With the new app bundle implementation, your base feature module takes the role as your app module (com.android.application), hosting the code and resources common to all features (instant and installed). You organize additional, modular features as one of three types of dynamic feature modules, based on when you want to deliver them to the user. The instant app module disappears, since the dist:instant attributes in the manifest are enough to identify which features will be included as part of the instant experience.

If you don’t have an instant experience added to your app and you’d like to create one, use Android Studio 3.3+ to create an instant-enabled app bundle.

Changes to responsive ads in the AdWords API and Google Ads API

What's changing?
Starting May 15, 2019, AdWords API and Google Ads API requests that attempt to create or modify a responsive ad will fail. Make sure you migrate to the new asset-based responsive display ad before the deprecation date.

Due to changes and improvements to ad types in Display campaigns, keeping track of the names in the UI and APIs can be tricky, so here's a quick overview:
Ad type in the UI AdWords API type Google Ads API type
Responsive ad ResponsiveDisplayAd ResponsiveDisplayAdInfo
Responsive display ad MultiAssetResponsiveDisplayAd Available in an upcoming release

After the deprecation date, behavior of the APIs will change as follows:
  • AdWords API
    • AdGroupAdService requests that attempt to create a ResponsiveDisplayAd will fail with the error AdGroupAdError.CANNOT_CREATE_DEPRECATED_ADS. The API will continue to allow you to remove ResponsiveDisplayAds and modify the status of existing ads.
    • AdService requests that attempt to modify a ResponsiveDisplayAd will fail with the error AdError.CANNOT_MODIFY_AD.
  • Google Ads API
    • AdGroupAdService requests that attempt to create a ResponsiveDisplayAdInfo will fail with the error AdGroupAdError.CANNOT_CREATE_DEPRECATED_ADS. The API will continue to allow you to remove ResponsiveDisplayAdInfos and modify the status of existing ads.
Both APIs will continue to return performance statistics for the deprecated ad types.

Why is this happening?
In October, 2018, responsive display ads replaced responsive ads as the default asset-based ad type for the Display network. To simplify the product suite, we'll be deprecating creation and modification of responsive ads.

What should you do?
Before the deprecation date: If you have any questions or need help, please contact us via the forum.

Google+ APIs shutting down March 7, 2019

As part of the sunset of Google+ for consumers, we will be shutting down all Google+ APIs on March 7, 2019. This will be a progressive shutdown beginning in late January, so we are advising all developers reliant on the Google+ APIs that calls to those APIs may start to intermittently fail as early as January 28, 2019.

On or around December 20, 2018, affected developers should also receive an email listing recently used Google+ API methods in their projects. Whether or not an email is received, we strongly encourage developers to search for and remove any dependencies on Google+ APIs from their applications.

The most commonly used APIs that are being shut down include:

As part of these changes:

  • The Google+ Sign-in feature has been fully deprecated and will also be shut down on March 7, 2019. Developers should migrate to the more comprehensive Google Sign-in authentication system.
  • Over the Air Installs is now deprecated and has been shut down.

Google+ integrations for web or mobile apps are also being shut down. Please see this additional notice.

While we're sunsetting Google+ for consumers, we're investing in Google+ for enterprise organizations. They can expect a new look and new features -- more information is available in our blog post.

Google Media Framework for Android is Deprecated

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.

Ending support for iOS 8 in the IMA SDK

With the release of v3.7.0 of the IMA iOS SDK, we will stop providing forum support and bug fixes for iOS IMA SDK issues specifically related to iOS 8 and below.

What does this mean if an app is currently targeting iOS 8?

  • There are no changes in v3.7.0 specifically designed to break compatibility, so the iOS IMA SDK will continue to work with iOS 8 in the short term. However, future releases are not guaranteed to continue to work with iOS 8.
  • Bugs that only affect iOS 8 will no longer be investigated.
  • If you are using our GoogleAds-IMA-iOS-SDK CocoaPod and want to update to v3.7.0, you'll need to start targeting iOS 9+.

What about other iOS versions?

We periodically stop supporting older iOS versions when adoption levels fall below a certain level. Whenever we end support for a major iOS release, we make announcements on our blog and release notes page.

As always, if you have any questions, feel free to reach out to us on our support forum.

Deprecating GMF for Android

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.

Note: We are NOT deprecating GMF for iOS.

If you have any questions, feel free to contact us via the IMA SDK developer forum.

Deprecating Flash in the IMA SDKs

On June 1, 2017, Google will cease development of Flash in the IMA SDKs. This will end support for the IMA SDK for Flash, as well as support for Flash VPAID ads in the HTML5 SDK. We strongly encourage all publishers still using the Flash SDK to migrate to the HTML5 SDK. We also strongly encourage advertisers still trafficking Flash VPAID ads to migrate those ads to JavaScript VPAID.

What does this mean for the Flash SDK?

We will not actively prevent ad serving to the Flash SDK. However, new releases will stop after June 1st and we will no longer fix bugs or answer support questions. If ad serving or playback stops working after this date for the Flash SDK, it will not be fixed. We strongly encourage you to migrate to the HTML5 SDK.

What does this mean for the HTML5 SDK?

We will no longer support Flash VPAID ads in the HTML5 SDK. Flash VPAID ads served to the HTML5 SDK will not be rendered and the SDK will fire an error. We strongly encourage you to migrate your Flash VPAID ads to JavaScript VPAID.

As always, if you have any questions, feel free to contact us via the support forum.

Announcing a deprecation policy for older versions of the iOS and Android IMA SDKs

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:

  • IMA Android prior to version 3.1.3
  • IMA iOS prior to version 3.1.0

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 iOSand Android. As always, if you have any questions, feel free to contact us via the support forum.