Tag Archives: deprecation

Announcing a deprecation schedule for the Google Mobile Ads SDK

To provide Google Mobile Ads SDK developers for AdMob and Ad Manager more transparency and predictability on the expected lifetime of an SDK version, we are introducing a deprecation schedule for the Google Mobile Ads SDKs for Android and iOS.

Benefits

Introducing a predictable deprecation schedule offers the following benefits for app developers and publishers:

Ability to predict and plan for SDK updates with a year of lead time.
Legacy SDK code that only exists to support old versions can be deleted, thereby decreasing SDK size and lowering the risk of bugs.
Engineering resources are freed up to focus more on support for newer SDKs and innovation of new SDK features.

Glossary

To understand the deprecation schedule, let’s first align the terms used to describe the state of a Google Mobile Ads SDK version:

SDK State	Impact
Supported	Ads serve to this SDK. Technical SDK support questions are welcomed on the Google Mobile Ads SDK developer forum.
Deprecated	Ads will still serve to this SDK. Support questions specific to this SDK version are no longer answered on the Google Mobile Ads SDK developer forum. Users will be asked to validate the issue in a supported SDK version to receive full support.
Sunset	Ads will not serve to this SDK. Ad requests return a no fill with an error indicating that this version is sunset.

Timelines

The deprecation and sunset timelines will revolve around major SDK version releases. We plan to do a major version release annually, in the first quarter of each year. The release of a new major version on both Android and iOS will trigger changes in SDK state for older major versions on both platforms.

Once we release a new major version N for both Android and iOS:

All SDK versions with major version N-2 on their respective platforms are considered deprecated immediately. Questions specific to these versions will no longer receive support.
All SDKs versions with major version N-3 on their respective platforms will sunset after 2 months.
- We will publish subsequent blog posts communicating specific sunset dates to activate this two-month sunset period. The first sunset announcement is expected in Q1 2023 with a sunset date in Q2 2023.

With this schedule, a new major version will live in the supported state for about 2 years, and in the deprecated state for an additional year before moving to the sunset state.

The graphic below helps visualize the schedule:

How does the change apply to existing versions?

Effective today, Android v19 and iOS v7 versions are considered deprecated. In accordance with the schedule above, we plan to sunset Android v19 and iOS v7 versions in Q2 2023 following the releases of Android v22 and iOS v9 planned for Q1 2023. We will provide more specific sunset dates following the releases of Android v22 and iOS v9.

The graphic below helps visualize the state of existing Google Mobile Ads SDK versions for Android and iOS with today’s announcement.

Note: Versions 6.x.x and below for both Android and iOS have been sunset since 2018.

Exceptions

The deprecation schedule provides a framework for predictable lifetimes for an SDK version. However, there may be exceptions in the future. This schedule does not preclude us from sunsetting an SDK version at an earlier date, but we are committed to providing proactive communication with ample lead time for any future changes.

Next Steps

Refer to the deprecation developer pages (Android | iOS) for the latest updates to the deprecation schedule. If you are on a deprecated version, see the Android migration guide or iOS migration guide for more information on how to update.
Stay tuned for future updates to this blog, where more specific sunset dates will be communicated once new major Google Mobile Ads SDK versions are released.

If you have any questions about this announcement, please reach out to us on the Google Mobile Ads SDK Developer Forum.

- Eric Leichtenschlag, Mobile Ads Developer Relations

Source: Google Ads Developer Blog

New Features Available in the Google Identity Services (GIS) Library

Posted by Gina Biernacki, Product Manager

At Google, we're committed to making authentication safer and easier for our developers, so users can easily access the apps and websites they love. Google Identity Services (GIS) continues to advance and further develop our authentication solutions that offer immense value to our partner ecosystem, including highly requested features including a new verified phone number directly embedded in our authentication flows.

For developers, our focus has always been to offer a frictionless experience that makes it easier for users to onboard and return to partner platforms, while also helping developers create a trusted relationship with their users.

What’s New

Today we are announcing a few new features that are now available across our libraries:

Android

Verified Phone Number on Android
Phone Hint on Android

Web

One Tap on Intelligent Tracking Prevention (ITP) Browsers

iOS and macOS

Added macOS Support

Android

Verified Phone Number

As an identity provider, we are making it seamless for developers to supplement additional user data leveraging the user’s Google Account, while ensuring clear user consent is woven into the experience. We understand that phone numbers are a critical piece of account management, both for our users in mobile-first markets and for our developers that require increased identity verification or two-step verification.

On Android devices, developers can now request users to share a verified phone number associated with their Google Account as part of the sign-up flow. Developers have shared with us that safeguarding their users through SMS verification represents a significant cost to their business. Now developers can simply request a phone number from the user, which has already been verified by Google, decreasing their overall SMS costs during the onboarding process.

Verified Phone Number is now available on GIS for Android and we plan to expand to other surfaces in the future.

Phone Number Hint

Another way a developer can request a user’s phone number is through the new Phone Number Hint API on Android devices. Phone Number Hint allows developers to call an API where users can share a phone number from the SIM cards of their device, independent of a sign up or sign in flow. This API is preferred over the native Android API call as it does not require any additional permissions, reducing time and effort for our developers. Phone Number Hint API does not require a user to be signed in to their Google account and does not save any information to the Google account.

Web

One Tap on ITP Browsers

ITP (Intelligent Tracking Prevention) browsers restrict the use of third party cookies, preventing the tracking of users across the web. GIS One Tap is now available on ITP browsers, including Safari, Firefox and Chrome on iOS. This creates a One Tap experience that’s consistent across multiple platforms, for both users and developers. Our developers prefer One Tap for many reasons:

increasing user conversion
Industry leading security
reduced risks associated with password management
allowing sign in and sign up without redirecting users to a dedicated sign in / up page
mitigate duplicate accounts with personalized prompts and automatic sign-in on return visits

The One Tap UX on ITP browsers will start with a warm welcome page as shown below.

Once the user chooses to continue, a popup window will be opened. The UX in the popup window is similar to the standard One Tap user experience.

We will roll out this new feature by default on October 12, 2022 to all developers who have enabled One Tap. Refer to our documentation to begin supporting One Tap on ITP browsers immediately or to opt-out of default support.

iOS and macOS

macOS Platform Expansion

Over the last few years, the Apple ecosystem has expanded to include a number of distinct platforms (iOS, iPadOS, macOS, tvOS, watchOS). As a step toward supporting the broader Apple ecosystem, we have launched macOS support as part of Google Sign-In for iOS and macOS. This provides support for the core GIS experiences (authentication, authorization, and token storage) for native macOS apps.

Deprecations

Upcoming Deprecations

In addition to new features available in the GIS library, we also want to remind our developers about upcoming deprecations.

Smart Lock for Passwords on Android Deprecation
Google Sign-In for Websites Deprecation

Smart Lock for Passwords Deprecation

We are announcing the deprecation of the Smart Lock for Passwords Android SDK, which handles password saving and retrieval, ID token requests, and sign-in hint retrieval. You can now find all Smart Lock for Passwords functionality available in the GIS library. We recommend all developers now use the GIS library for new functionality. For existing integrations, Smart Lock for Passwords traffic will be redirected to the GIS library by default, without any changes needed by developers.

Google Sign-In for Websites Deprecation

We would like to remind our developers that on March 31, 2023 we will fully retire the Google Sign-In JavaScript Platform Library for web applications. Please check if this affects your web application, and if necessary, to plan for a migration.

We are excited to see these new features continue to bring measurable value to both our developers and users, and look forward to continuing supporting our developers with their identity-related needs. Please visit our developer site to get started.

Source: Google Developers Blog

Deprecation of Structured Data Files v5.2 and v5.3

Today we’re announcing the deprecation of the Structured Data Files (SDF) v5.2 and v5.3. These versions will be fully sunset on March 8, 2023.

Please migrate to v5.5, the most recent version, by the sunset date. Once the deprecated versions are sunset:

The default version of partners and advertisers using those versions will be updated to the oldest supported version, v5.4.
sdfdownloadtasks.create requests declaring the sunset versions in the request body will return a 400 error.

If you run into issues or need help with your migration, please contact us using our support contact form.

- Trevor Mulchay, Display & Video 360 API Team

Source: Google Ads Developer Blog

Deprecation of Structured Data Files v5.2 and v5.3

Today we’re announcing the deprecation of the Structured Data Files (SDF) v5.2 and v5.3. These versions will be fully sunset on March 8, 2023.

Please migrate to v5.5, the most recent version, by the sunset date. Once the deprecated versions are sunset:

The default version of partners and advertisers using those versions will be updated to the oldest supported version, v5.4.
sdfdownloadtasks.create requests declaring the sunset versions in the request body will return a 400 error.

If you run into issues or need help with your migration, please contact us using our support contact form.

- Trevor Mulchay, Display & Video 360 API Team

Source: Google Ads Developer Blog

Deprecation of Bid Manager API v1.1

Today we’re announcing the deprecation of the Bid Manager (DBM) API v1.1. This version will be fully sunset on February 28, 2023.

Please migrate to Bid Manager API v2 by the sunset date to avoid an interruption of service. v2 introduced a number of new features and breaking changes, which are listed in our release notes. Here are some of the changes introduced in v2:

Updated API endpoints for existing services and methods.
Restructured Query and Report resources that use named object types and enums.
Added ability to request individual Report objects via queries.reports.get.
Added ability to order queries.list and queries.reports.list requests.
Improved queries.run behavior to return a Report object instead of an empty response

Follow the steps in our v2 migration guide to help you migrate from v1.1 to v2.

If you run into issues or need help with your migration, please contact us using our support contact form.

- Trevor Mulchay, Display & Video 360 API Team

Source: Google Ads Developer Blog

Discontinuing authorization support for the Google Sign-In JavaScript Platform Library

Posted by Brian Daugherty, Product Solutions Engineer

Last year, we announced our plan to deprecate the Google Sign-In JavaScript Platform Library for web applications.

On March 31, 2023 we will fully retire the Google Sign-In JavaScript Platform Library and would like to remind you to check if this affects your web application, and if necessary, to plan for a migration.

Beginning April 30th, 2022 new applications must use the Google Identity Services library, existing apps may continue using the Platform Library until the deprecation date.

What does this mean for you?

Evaluate if you are affected by the deprecation and your need to Migrate to Google Identity Services.
Complete your migration prior to March 31, 2023, after which the Platform Library will no longer be available for download and web apps relying upon deprecated authorization features to obtain access tokens for calling Google APIs will no longer work as intended.

Are you affected?

To protect users' personal information across the web, Google continues to make signing into apps and services secure by default. Delivering on this promise, we announced Google Identity Services, our family of Identity APIs that consolidate multiple identity offerings under one software development kit (SDK). Recently, we released an update to the Google Identity Services library, adding user authorization and data sharing features based on OAuth 2.0. Due to numerous security and privacy improvements, the new Identity Services library is not fully backward compatible with all features and functionality found in the older Platform Library, and so a migration to the new library and code changes are necessary.

The deprecation applies to web apps loading the Google Sign-In JavaScript Platform Library and apps using the Google API Client Library for JavaScript with access tokens.

If your web pages use the apis.google.com/js/api.js or apis.google.com/js/client.js JavaScript modules to load the Platform Library, you are affected and need to update your existing implementation to use the new Identity Services client library.

Web applications using gapi.client from the Google API Client Library implicitly load and use the Platform Library’s soon to be deprecated gapi.auth2 module when working with access tokens to call Google APIs. Updates to your web app to explicitly include the new Identity Services library, manage access token requests, and replace auth2 module references with newer equivalent methods are necessary.

Your full suite of apps and platforms may be using different methods of authentication and authorization from Google. The following are NOT affected by this deprecation announcement:

Android or iOS native app SDKs,
Backend platforms directly calling Google’s OAuth 2.0 or OpenID services.

Migration

Authorization and authentication functionalities are clearly separated in the new Identity Services library.

There are two guides to help you with migration:

(1) migrate to Google Identity Services for user authorization and obtaining access tokens for use with Google APIs, and
(2) migrating from Google Sign-In for user authentication and sign-in.

Your web application may use both authorization (to call Google APIs), and authentication (to manage user sign-in to your app). If this is the case, you’ll need to follow both migration guides to ensure separation of user authorization and authentication flows in your web application.

The migration guides are written to help you understand how the new Identity Services library differs from prior libraries, what these changes are, how to separate authentication from authorization, and how these changes affect both your users and your codebase.

Changes and benefits

Migration to our new Identity Services library includes a number of changes and benefits:

Pop-ups provide a more secure, reduced UX friction way to authorize your web app without having to use redirects or require users to leave your site.
Increased privacy and control by default: users approve individual scopes, and only when they are needed, improving how much, and when, sensitive data may be shared with your web app.
Separate ID token and access token credentials clearly distinguish user identity from application capabilities. Individual credentials are easier to separate, manage, or store based upon their level of risk. An identity may convey only who you are and offer a lower level of risk when compared to an access token with capabilities to read/write sensitive user data.
Forward compatibility with Chromium Privacy sandbox changes.

This is a brief summary of privacy, security, and usability changes found in the new Identity Services library, additional detail is available in the migration guides.

How to get help

Visit our developer site for more information and check out the google-oauth tag on Stack Overflow for technical assistance. You can also offer your suggestions and feedback by sending an email to [email protected].

Source: Google Developers Blog

Announcing authorization support for Google Identity Services APIs

Posted by Rohey Livne, Product Manager

Google Identity Services (GIS)

At Google, keeping users safe online is our top priority, so we continuously invest in new tools and features to keep their personal information secure.

In August 2021, we launched a new family of Identity APIs called Google Identity Services (GIS), which consolidates multiple identity offerings under one web software development kit (SDK). This SDK includes the Sign in with Google button as well as One Tap, a low-friction authentication prompt. Sign in with Google and One Tap use secure tokens, rather than passwords, to sign users into sites and apps.

Today we are announcing the addition of an authorization feature, all under the same unified Google Identity Services SDK, which further increases the value of our suite of identity solutions and makes it simpler for developers to implement.

Caption: Authorization screen with individual consent options

What's new

The updated library now provides a ‘one-stop-shop’ for developers across both authentication and authorization. Authentication enables new user sign ups and returning user sign ins, while authorization allows developers to receive an access token to call Google APIs, with the user’s consent.

To provide developers with more control, the new SDK supports a clear separation between authentication and authorization moments. This enables partners to make authentication and authorization calls as two separate and distinct flows based on the needs of the site or app.

Benefits

The new SDK uses browser-based pop-up dialogues, which reduces user friction on sites and apps, streamlines authentication and authorization flows, and increases user engagement.

In addition, the removal of automatic refresh of expired access tokens enhances the overall security of the flows, requiring an end user to explicitly refresh their session, preventing long standing tokens from being used for unintended purposes.

Furthermore, the new consolidated library reduces integration complexity minimizing development time and effort. To simplify integration even further, we provide pre-scripted easy to use code snippets that can be copied and pasted directly onto partner sites.

Users who take advantage of Google’s authentication or authorization flows benefit from Google’s leading security infrastructure, offering two factor authentication, password recovery flows, and have the peace of mind that all sites and apps with authorization enabled, have been verified by Google.

We continue to improve our solutions as part of the migration to Google Identity Services (GIS), so look out for more capabilities added throughout the year.

To take advantage of the new Google Identity Services (GIS) library, head over to Google’s Developer site and click on the ‘Get Started’ button for access to technical documentation.

Source: Google Developers Blog

Updates to Chromecast integrations with Interactive Media Ads

CAF DAI SDK Released

The Interactive Media Ads team is excited to announce that we’ve teamed up with the Cast Application Framework team to bring you the CAF DAI SDK, a fully supported solution for casting DAI video streams to Chromecast devices. This project is a complete rewrite of our original IMA SDK for Cast, significantly reducing the amount of code publishers need to write and streamlining the integration between the two SDKs.

The CAF DAI SDK provides a deep integration with Chromecast Application Framework's native Ad Breaks, meaning that adding around 30 lines of code to an existing CAF receiver can enable:

DAI support for both Live and VOD streams
Media queue management
Sender and receiver UI, including ad break markers
Bidirectional communications between sender and receiver
Skippable ad support on VOD streams

With the previous SDK, all of these functions required manual implementation.

A fully-featured CAF DAI integration

IMA SDK for Cast deprecated

As of December 13, 2021, both the client-side and DAI versions of the IMA SDK for cast are now deprecated. Publishers who are currently using the IMA SDK for cast to implement client-side advertisements are encouraged to migrate to using CAF native ad breaks. Publishers who are currently using the IMA SDK for cast to implement DAI advertisements are encouraged to migrate to the new CAF DAI SDK. These new implementation options offer publishers significantly simpler integrations with better stability and tighter integration with the entire cast ecosystem.

Advertisement Type	Deprecated Solution	Recommended Solution
Client Side	IMA SDK for Cast	CAF native ad breaks
DAI	IMA SDK for Cast	CAF DAI SDK

The Client side and DAI versions of the IMA SDK for Cast will continue to function for the foreseeable future but support and new development will be focused on the CAF DAI SDK moving forward. The IMA SDK team will continue to offer best attempt support for the deprecated SDKs through December of 2022, however, some limitations of the older platform may only be resolved by migrating to the new workflows described above.

We highly recommend that publishers who are currently using the older IMA SDK for Cast begin migrating to these new workflows for improved stability, simplified integration, and a much more polished developer experience.

—

For more information about these changes, check out the developer documentation. If you have any issues migrating your integration from the IMA SDK for Cast to the CAF DAI SDK, feel free to reach out via our developer forums.

Source: Google Ads Developer Blog

Discontinuing Google Sign-In JavaScript Platform Library for web

Posted by Brian Daugherty, Product Solutions Engineer

In order to protect users' personal information across the web, Google continues to make signing into apps and services secure by default. Delivering on this promise, we recently announced Google Identity Services, our new family of Identity APIs that consolidate multiple identity offerings under one software development kit (SDK). As we move to further simplify the number of sign-in methods and user experience we are announcing the deprecation of the JavaScript based Google Platform Library for web apps and plan to fully retire it on March 31, 2023.

What does this mean for you?

Evaluate if you are affected by the deprecation.
Complete your migration before March 31, 2023, after which the Google Platform Library will no longer be available for download. If you’re making the switch, we’ve provided a Sign In With Google migration guide to help you out.

Are you affected?

The deprecation applies only to web apps using the Google Sign-in JavaScript library. If your web pages currently load the Google Platform Library (apis.google.com/js/platform.js), you are affected and need to migrate to the newer Sign In With Google client library.

Your suite of apps and platforms may be using the Google Platform Library to support authentication only flows for user sign-in, an authorization flow for data-sharing (for example, sharing a user’s calendar or photos), or both at the same time. The migration includes both authentication and authorization flows.

Your suite of apps and platforms may also be using multiple methods of authentication and authorization offered by Google. The following are NOT affected by this deprecation announcement:

Android or iOS native app SDKs,
apps or platforms directly calling Google’s OAuth2 or OpenID services.

Changes and benefits

As part of our ongoing effort to improve user sign-in we released a new JavaScript library for Sign In With Google. In addition to prior authentication and authorization functionality, it also offers a new user experience to improve user visibility, trust and decrease friction during sign-in.

Migration to our new JavaScript library offers a number of benefits, some of which are:

Low-friction user sign-in and sign-up.
Providing your users with a consistent sign-in experience across the web.
Adding a secure sign-in method to your site using either HTML or JavaScript.

Examples of what users will see:

image showing how personalized buttons and one tap prompt look

See the Google Identity Services product announcement for more.

How to get help

Visit our developer site for more information and check out the google-signin tag on Stack Overflow for technical assistance. Offer your suggestions and feedback using [email protected].

Source: Google Developers Blog

Launching our new Google Identity Services APIs

Posted by Filip Verley (Product Manager, Google Identity)

We strive to make every one of our products private by design and secure by default, with built-in protections that keep our users safe. But the most common online security vulnerability occurs beyond our own products, where users sign in to online accounts using bad passwords. Every day millions of passwords are exposed in data breaches putting users’ personal information at risk. At Google, keeping users safe online is our top priority, so we continuously invest in new tools and features to keep their personal information secure.

Today we are launching our new family of Identity APIs called Google Identity Services, which consolidates multiple identity offerings under one software development kit (SDK). This SDK includes the Sign in with Google button as well as One Tap, a new low-friction authentication prompt. Sign in with Google and One Tap use secure tokens, rather than passwords, to sign users into partner websites and apps.

We set out on this journey to deliver an identity solution without compromising privacy and security, and we’ve done just that. With the new Google Identity Services, we've combined Google's industry leading security with the ultimate convenience of easy sign in to deliver an experience that keeps users safe, while facilitating new user acquisition and seamless sign in for returning users.

What’s new for you

One Tap is a proactive and seamless sign in prompt that helps users safely and securely access their personalized content when they use your website or app. Unlike the traditional sign in button, One Tap prompts users on any page, so users do not need to be redirected to a landing page that derails the user’s navigation intent. The One Tap prompt will slide down from the top right of a website, and up from the bottom up on a mobile device. Users can sign in to or sign up using just one tap, without having to remember their credentials or to create a password. We’ve seen tremendous results from our partners as our authentication solutions dramatically decrease friction and increase the rate at which users sign in and sign up across websites and apps.

One Tap prompts on mobile device from the bottom up

Our Google Identity Services products are also engineered to protect against vulnerabilities like click-jacking, pixel tracking, and other threats, which help give users peace of mind when they navigate across your website and app. Because every Google Account leverages our robust anti-abuse and anti-fraud system, using Google Identity Services will mitigate against duplicate and fraudulent accounts, thus decreasing your support burden.

In addition, we’re rolling out an improved Sign in with Google button that displays personalized user details for returning users, and displays the user account that is being selected. The Sign in with Google button also has improved UI/UX consistency across the web, elevating user trust and security across your platform.

Personalized Sign in with Google button, displayed in a blue or white background

We recently worked with Reddit to implement both the Sign in with Google button and the One Tap prompt, which increased both new user sign up and returning user conversion by almost 2X. You can also read how Pinterest successfully implemented Google Identity Services and saw a positive impact on both sign in and sign ups.

One Tap prompt surfaces on top right of Reddit website

How to get started

We’ve worked diligently to simplify the implementation process for our developers, requiring minimal code, and we’re eager for you to take advantage of our new suite of APIs to help grow your business. To start implementing the new Google Identity Services, head to our developer site for technical documentation, and check out the google-signin tag on Stack Overflow for technical assistance.

googblogs.com

All Google blogs and Press in one site

Tag Archives: deprecation

Announcing a deprecation schedule for the Google Mobile Ads SDK

Benefits

Glossary

Timelines

How does the change apply to existing versions?

Exceptions

Next Steps

Source: Google Ads Developer Blog

Deprecation of Structured Data Files v5.2 and v5.3

Source: Google Ads Developer Blog

Deprecation of Structured Data Files v5.2 and v5.3

Source: Google Ads Developer Blog

Deprecation of Bid Manager API v1.1

Source: Google Ads Developer Blog

Updates to Chromecast integrations with Interactive Media Ads

CAF DAI SDK Released

IMA SDK for Cast deprecated

Source: Google Ads Developer Blog