Tag Archives: mobile

New look and feel for Google Meet mobile apps

Quick launch summary

We’re updating the user interface (UI) of the Google Meet mobile apps for Android and iOS. The new mobile UI will have the same look and feel as that of the meeting experience in the Gmail app.

A new look and feel for Google Meet mobile apps

In addition to the revamped design, you’ll now see a New Meeting button. When you tap on this button, you’ll see three options:
  • Get meeting joining info to share with others.
  • Start a Meet call instantly.
  • Schedule a new meeting in Google Calendar.

New options for new meetings in Google Meet mobile apps

This new UI is rolling out on iOS now; check back for an update on this post when the rollout to Android begins.

Getting started

  • Admins: There is no admin control for this feature.
  • End users: This new UI will appear by default once you’ve upgraded your Meet iOS app to version 45 or above.

Rollout pace

iOS
Android

Availability

  • Available to all G Suite customers and users with personal Google Accounts

Resources

Update your G Suite mobile and desktop apps before August 12, 2020, to ensure they continue working

Quick summary

In 2018, we began making changes to our API and service infrastructure to improve performance and security. As a result of these changes, some older versions of G Suite desktop and mobile apps may stop working on August 12, 2020. In particular, versions released prior to December 2018 may be impacted.

To ensure their workflows are not disrupted, your users should update the following Google apps to the latest versions as soon as possible:

Getting started
  • Admins: Encourage your users to upgrade their apps. If you deploy Drive File Stream to your organization, ensure you’re using the latest version.
  • End users: Upgrade the apps listed above to the latest versions as soon as possible.
Rollout pace

Availability
  • This impacts all G Suite customers and users with personal Google accounts.

Unveiling expert insights in our new podcast series: Apps, Games, & Insights

Posted by Lily Sheringham, Global Marketing, Platforms & Ecosystems

This is a cross-post from The Google Keyword blog.

Apps, Games, & Insights illustrated banner with gaming imagery.

Today we’re launching the Apps, Games, & Insights podcast series, bringing together insights, stories, and learnings from industry experts, on some of today's hottest topics surrounding mobile, apps and games businesses, and the wider industry.

Listen to the podcast here!

The series has eight episodes which aim to challenge, provoke thought, and enlighten listeners - from designers and developers, through to product managers and marketers, and those interested in the apps and games industry.

The podcast is hosted by Googlers Tamzin Taylor, who heads up Apps & Games Business Development for Google Play in Western Europe, and Dirk Primbs, who leads the Ecosystem Developer Relations team in EMEA. Together, they have many years of experience working with partners to assist with Android development, mobile, app, game, and business growth. Every week they will be joined by different guests for each of the episodes.

Sneak peek at what’s coming up

Kicking off the series are Judy Chen and Sarah Fuchs from Crowdstar, the developers of Covet Fashion and Design Home. They join us for episode 1 to discuss how to build a long-term games business by taking a holistic approach to the game, its players, and the people who create the game.

Ever wonder if it's worth selling your app or game business, and if so how to approach it? It's not all about pocketing the cash and walking away. For episode 2, game mergers and acquisitions expert Chris Petrovic from Zynga will talk about how acquisition can free developers to focus on what they love: creating great apps and games.

The popularity of subscriptions continues to grow, with developers who used subscriptions earning 4X more in 2018, than in 2016. Holly Ackerman and David Berlin, from the sports streaming platform DAZN, join us for episode 3 to provide some fascinating insights into how they have grown their subscription business in this industry.

Whether you are a startup in search of funding or an established business looking to accelerate your investment, venture capital can often be a good source of funds. In episode 4, venture capital expert Matteo Vallone from Cherry Ventures offers insights into the investment process and how to maximize your appeal to investors.

For episode 5, we have what is possibly one of the biggest topics in mobile and throughout the tech industry: privacy. Bruce Gustafson, CEO of Developers Alliance brings us up to speed on trust and safety, platform value, respecting the user, and ultimately building privacy friendly apps and games.

Successful game developers put players front and center of everything they do. When over 270 million people have played your games, you must be doing something right. Ben Clarke, Senior Global Marketing Director at Jagex, joins us for episode 6 to discuss some of the innovative approaches to player engagement and retention taken in their RuneScape games.

Figuring out how to make your app or game accessible to all can often be a challenge, sometimes both from an organizational and technical perspective. However, many developers have made accessibility a core part of their app development process and company culture. For episode 7, we’re joined by Ceri Lindsay and Rosalind Whittam from the BBC to discover how they address accessibility.

Today, Android is not just about smartphones, Android apps and games can run on a range of devices with larger screens, such as Chromebooks. At the same time, mature mobile game franchises are looking for opportunities beyond mobile. In our final episode 8, we’ll be joined by Maximiliano Rodriguez of Gameloft to talk about the challenge of taking games to big screens and new platforms.

We hope you’ll join us over the next eight weeks to dive deeper and hear what our thought leader guests have to say on each topic.

How to stay tuned in

To listen to our first podcast and find out more about what’s coming, check out our new Apps, Games, & Insights podcast homepage.

Listen to our first episode here, or on Spotify, Apple Podcasts, Google Play Music, Google Podcasts, Deezer, iHeartRadio, and also on LibSyn. Keep an eye out on @GooglePlayDev and @AndroidDev on Twitter where we will be announcing the launch of the new episodes each week.

How useful did you find this blog post?

New Android management client for devices registered after September 16, 2019

What’s changing 

On September 16, 2019, we’ll begin gradually rolling out a new Android management system called “Android Management API.” Apps managed through the new system will also use a new on-device management client, Android Device Policy, which will replace the existing Google Apps Device Policy client.

While the new client has mostly similar features, there are some differences in management and usage that will impact G Suite admins and end users. The changes will make it easier for admins and users to set up and manage Android devices for work.

You will receive an email notification before it impacts your domain 
The rollout will be conducted in stages, and could take several months to reach all domains. We will email your organization’s primary admin around 3 weeks before it will reach your domain with more specific dates for deployment.

See below for more details about the changes.

Who’s impacted 

Admins and end users

Why you’d use it 

The new client will have closer ties to the Android infrastructure, allowing us to quickly add new features and more easily develop updates for increased security. It will also provide a more seamless experience for end users, with fewer apps to manage and more integrated functionality.

How to get started 


  • Admins: Familiarize yourself with the changes outlined in this post, including the additional details section below. Let your users know about the changes they can expect. 
  • End users: No action needed. 


Additional details 

Devices that will use the new Android management client 
Once this change has been deployed to your domain, newly registered devices that meet the following requirements will be automatically managed using the Android Management API:

  • The device is using Android M or above. 
  • The device supports a work profile and company-owned (fully managed) device mode. 
  • The user account is under advanced mobile device management. 

This will not impact previously enrolled devices; they will still be managed through the legacy Android management client.

How managing devices is different with the new client 
In the Admin console, most of the functionality will remain the same. All devices will be displayed and managed through the same interface at Admin console > Device management.

There will be some changes, however, for devices managed through the new client.

The following features will not be supported:
  • Device admin mode
  • Option to disable Work Profile setup (If you don’t want to use Work Profiles in your organization, you can instruct your users to set up devices without enabling the feature) 
  • Wipe Account for company-owned devices or devices in fully managed device (device owner) mode (Wipe Device will still be available) 


The following new features will be available:


The following features will change:
  • If you manually choose to Wipe Device, you’ll have a new option to either retain the factory reset protection settings or clear them along with the complete wipe. 
  • The Auto account wipe setting will perform Wipe Device for devices in fully managed device (device owner) mode. In addition to being applied when devices fall out of sync, Auto account wipe will be triggered when devices fall out of some policies (for instance, when a more restrictive passcode policy has been enforced by the admin). In both cases, the user will be given a grace period and notifications to correct the issue prior to the wipe taking place. 
  • Device management rules will initiate a device wipe instead of an account wipe for devices in fully managed device (device owner) mode. 


You can see which client is managing a device in the Admin console at Security details > User agent. Devices using the legacy client will have a version of Google Apps Device Policy, while devices using the new client will have a version of Android Device Policy. Use our Help Center to learn how to view mobile device details.

How using a device is different with the new client 
The main end-user visible changes include the following:

  • Users will have an updated enrollment experience. 
  • After the new version is deployed, users will no longer see a Device Policy app in their app drawer. The new management system and Android Device Policy app will be integrated with Android for a more seamless experience. 
  • Users won’t be able to use My Devices to manage their device (for the time being, they can use Find My Device). 
  • If your organization enforces a strong password, the password will require a symbol in addition to the letter and number previously required. 


Users will experience a slightly different setup flow when registering new devices. 


Migrating from the legacy system to the Android Management API 
Once this change has been deployed to your domain, you can manually migrate users and devices to the new Android Management API in the following ways:

  • Factory reset and re-register any eligible device. 
  • Provide a new device and register it. 

In the future, we’ll add options and tools to help you migrate existing devices to use the Android Management API. Check out the G Suite Updates blog for the latest changes and migration updates. 

Availability 

Rollout details 
  • All domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on September 16, 2019. The rollout will be conducted in stages, and could take several months to reach all domains. 
  • Primary admins will be notified by email around 3 weeks before it will reach your domain. 

G Suite editions 
  • Available to all G Suite editions 

On/off by default? 
  • This feature will be ON by default for new devices that meet the requirements above.


Stay up to date with G Suite launches

Mobile-First Indexing by default for new domains

Over the years since announcing mobile-first indexing - Google's crawling of the web using a smartphone Googlebot - our analysis has shown that new websites are generally ready for this method of crawling. Accordingly, we're happy to announce that mobile-first indexing will be enabled by default for all new, previously unknown to Google Search, websites starting July 1, 2019. It's fantastic to see that new websites are now generally showing users - and search engines - the same content on both mobile and desktop devices!

You can continue to check for mobile-first indexing of your website by using the URL Inspection Tool in Search Console. By looking at a URL on your website there, you'll quickly see how it was last crawled and indexed. For older websites, we'll continue monitoring and evaluating pages for their readiness for mobile first indexing, and will notify them through Search Console once they're seen as being ready. Since the default state for new websites will be mobile-first indexing, there's no need to send a notification.


Using the URL Inspection Tool to check the mobile-first indexing status

Our guidance on making all websites work well for mobile-first indexing continues to be relevant, for new and existing sites. For existing websites we determine their readiness for mobile-first indexing based on parity of content (including text, images, videos, links), structured data, and other meta-data (for example, titles and descriptions, robots meta tags). We recommend double-checking these factors when a website is launched or significantly redesigned.

While we continue to support responsive web design, dynamic serving, and separate mobile URLs for mobile websites, we recommend responsive web design for new websites. Because of issues and confusion we've seen from separate mobile URLs over the years, both from search engines and users, we recommend using a single URL for both desktop and mobile websites.

Mobile-first indexing has come a long way. We're happy to see how the web has evolved from being focused on desktop, to becoming mobile-friendly, and now to being mostly crawlable and indexable with mobile user-agents! We realize it has taken a lot of work from your side to get there, and on behalf of our mostly-mobile users, we appreciate that. We’ll continue to monitor and evaluate this change carefully. If you have any questions, please drop by our Webmaster forums or our public events.

Instant-loading AMP pages from your own domain

Today we are rolling out support in Google Search’s AMP web results (also known as “blue links”) to link to signed exchanges, an emerging new feature of the web enabled by the IETF web packaging specification. Signed exchanges enable displaying the publisher’s domain when content is instantly loaded via Google Search. This is available in browsers that support the necessary web platform feature—as of the time of writing, Google Chrome—and availability will expand to include other browsers as they gain support (e.g. the upcoming version of Microsoft Edge).

Background on AMP’s instant loading

One of AMP's biggest user benefits has been the unique ability to instantly load AMP web pages that users click on in Google Search. Near-instant loading works by requesting content ahead of time, balancing the likelihood of a user clicking on a result with device and network constraints–and doing it in a privacy-sensitive way.

We believe that privacy-preserving instant loading web content is a transformative user experience, but in order to accomplish this, we had to make trade-offs; namely, the URLs displayed in browser address bars begin with google.com/amp, as a consequence of being shown in the Google AMP Viewer, rather than display the domain of the publisher. We heard both user and publisher feedback over this, and last year we identified a web platform innovation that provides a solution that shows the content’s original URL while still retaining AMP's instant loading.

Introducing signed exchanges

A signed exchange is a file format, defined in the web packaging specification, that allows the browser to trust a document as if it belongs to your origin. This allows you to use first-party cookies and storage to customize content and simplify analytics integration. Your page appears under your URL instead of the google.com/amp URL.

Google Search links to signed exchanges when the publisher, browser, and the Search experience context all support it. As a publisher, you will need to publish both the signed exchange version of the content in addition to the non-signed exchange version. Learn more about how Google Search supports signed exchange.

Getting started with signed exchanges

Many publishers have already begun to publish signed exchanges since the developer preview opened up last fall. To implement signed exchanges in your own serving infrastructure, follow the guide “Serve AMP using Signed Exchanges” available at amp.dev.

If you use a CDN provider, ask them if they can provide AMP signed exchanges. Cloudflare has recently announced that it is offering signed exchanges to all of its customers free of charge.

Check out our resources like the webmaster community or get in touch with members of the AMP Project with any questions. You can also provide feedback on the signed exchange specification.


User experience improvements with page speed in mobile search

To help users find the answers to their questions faster, we included page speed as a ranking factor for mobile searches in 2018. Since then, we've observed improvements on many pages across the web. We want to recognize the performance improvements webmasters have made over the past year. A few highlights:

  • For the slowest one-third of traffic, we saw user-centric performance metrics improve by 15% to 20% in 2018. As a comparison, no improvement was seen in 2017.
  • We observed improvements across the whole web ecosystem. On a per country basis, more than 95% of countries had improved speeds.
  • When a page is slow to load, users are more likely to abandon the navigation. Thanks to these speed improvements, we've observed a 20% reduction in abandonment rate for navigations initiated from Search, a metric that site owners can now also measure via the Network Error Logging API available in Chrome.
  • In 2018, developers ran over a billion PageSpeed Insights audits to identify performance optimization opportunities for over 200 million unique urls.

Great work and thank you! We encourage all webmasters to optimize their sites’ user experience. If you're unsure how your pages are performing, the following tools and documents can be useful:

  1. PageSpeed Insights provides page analysis and optimization recommendations.
  2. Google Chrome User Experience Report provides the user experience metrics for how real-world Chrome users experience popular destinations on the web.
  3. Documentation on performance on Web Fundamentals.

For any questions, feel free to drop by our help forums (like the webmaster community) to chat with other experts.


Consolidating your website traffic on canonical URLs

In Search Console, the Performance report currently credits all page metrics to the exact URL that the user is referred to by Google Search. Although this provides very specific data, it makes property management more difficult; for example: if your site has mobile and desktop versions on different properties, you must open multiple properties to see all your Search data for the same piece of content.

To help unify your data, Search Console will soon begin assigning search metrics to the (Google-selected) canonical URL, rather than the URL referred to by Google Search. This change has several benefits:

  • It unifies all search metrics for a single piece of content into a single URL: the canonical URL. This shows you the full picture about a specific piece of content in one property.
  • For users with separate mobile or AMP pages, it unifies all (or most, since some mobile URLs may end up as canonical) of your data to a single property (the "canonical" property).
  • It improves the usability of the AMP and Mobile-Friendly reports. These reports currently show issues in the canonical page property, but show the impression in the property that owns the actual URL referred to by Google Search. After this change, the impressions and issues will be shown in the same property.

When will this happen?

We plan to transition all performance data on April 10, 2019. In order to provide continuity to your data, we will pre-populate your unified data beginning from January 2018. We will also enable you to view both old and new versions for a few weeks during the transition to see the impact and understand the differences.

API and Data Studio users: The Search Console API will change to canonical data on April 10, 2019.

How will this affect my data?

  • At an individual URL level, you will see traffic shift from any non-canonical (duplicate) URLs to the canonical URL.
  • At the property level, you will see data from your alternate property (for example, your mobile site) shifted to your "canonical property". Your alternate property traffic probably won't drop to zero in Search Console because canonicalization is at the page, not the property level, and your mobile property might have some canonical pages. However, for most users, most property-level data will shift to one property. AMP property traffic will drop to zero in most cases (except for self-canonical pages).
  • You will still be able to filter data by device, search appearance (such as AMP), country, and other dimensions without losing important information about your traffic.

You can see some examples of these traffic changes below.

Preparing for the change

  • Consider whether you need to change user access to your various properties; for example: do you need to add new users to your canonical property, or do existing users continue to need access to the non-canonical properties.
  • Modify any custom traffic reports you might have created in order to adapt for this traffic shift.
  • If you need to learn the canonical URL for a given URL, you can use the URL Inspection tool.
  • If you want to save your traffic data calculated using the current system, you should download your data using either the Performance report's Export Data button, or using the Search Console API.

Examples

Here are a few examples showing how data might change on your site. In these examples, you can see how your traffic numbers would change between a canonical site (called example.com) and alternate site (called m.example.com).

Important: In these examples, the desktop site contains all the canonical pages and the mobile contains all the alternate pages. In the real world, your desktop site might contain some alternate pages and your mobile site might contain some canonical pages. You can determine the canonical for a given URL using the URL Inspection tool.

Total traffic

In the current version, some of your traffic is attributed to the canonical property and some to the alternate property. The new version should attribute all of your traffic to the canonical property.


Canonical property
(http://example.com)
Alternate property
(http://m.example.com)
Current

New, based on canonical URLs

Change +0.7K     |        +3K -0.7K        |          -3K

Individual page traffic

You can see traffic changes between the duplicate and canonical URLs for individual pages in the Pages view. The next example shows how traffic that used to be split between the canonical and alternate pages are now all attributed to the canonical URL:


Canonical property
(http://example.com)
Alternate property
(http://m.example.com)

Old

New

Change

+150     |        +800

-150     |        -800

Mobile traffic

In the current version, all of your mobile traffic was attributed to your m. property. The new version attributes all traffic to your canonical property when you apply the "Device: Mobile" filter as shown here:


Canonical property
(http://example.com)
Alternate property
(http://m.example.com)

Old

New

Change

+0.7K      | +3K

-0.7K      | -3K

In conclusion

We know that this change might seem a little confusing at first, but we're confident that it will simplify your job of tracking traffic data for your site. If you have any questions or concerns, please reach out on the Webmaster Help Forum.


Manage and distribute Android apps when using basic mobile management

What’s changing 

You can now manage Android apps for your users when using basic mobile management. Previously, you could only do this if you used advanced mobile management.

Who’s impacted 

Admins only

Why you’d use it 

With basic mobile management you can now:
  • Organize apps in the managed Google Play store 
  • Automatically install apps on users' devices 
  • Create web apps 
  • Create private apps 

See below for more info.

How to get started 

  • Admins: Go to Admin console > Device management > App Management > Manage apps for Android devices, to start to whitelist and manage Android apps
  • End users: No action needed. Users in basic mobile management domains will now see a “Work apps” section in the managed Google Play store. The section contains the default G Suite apps and other apps that are whitelisted from the Admin console

Additional details 


Organize apps in the managed Google Play store: 
To help your users find the apps they need, you can organize apps into collections. These collections appear on devices in the “Work apps” section in the managed Google Play store.

Automatically install apps: 
With basic mobile management you can now automatically install apps on your users’ devices. Use our Help Center to find out how to manage app preferences. Note that preventing users from uninstalling apps, and some other advanced features, require advanced mobile management.

Create web apps 
You can now create and manage web apps in the Admin console. Web apps look like native apps and can make web pages easier to find and simpler to use on mobile devices. You can also distribute web apps the same way you distribute native apps–by adding them to collections in a managed Google Play store or automatically installing them on users’ devices.

Create private apps 
You can now create private Android apps directly from the Admin console. Simply upload the APK and give the app a title. The app will appear in the managed Google Play store within minutes. You can also install the app directly on your users’ devices (see above). Previously, it took several hours to create and publish an app, and you had to create a Play Console account, provide a credit card, and fill in many other fields before the app would be available to your users.


The ‘Work Apps’ tab in the managed Google Play store has the G Suite apps and other apps whitelisted by admins. 

Helpful links 


Availability 

Rollout details 

G Suite editions:
Available to all G Suite editions.

On/off by default? 
This feature will be OFF by default until app management is set up, and can be enabled at the domain, OU, or group level.

Stay up to date with G Suite launches
  • Get G Suite product update alerts by email
  • See the G Suite launch release calendar
  • Subscribe to the RSS feed of these updates
  • Mobile-First indexing, structured data, images, and your site

    It's been two years since we started working on "mobile-first indexing" - crawling the web with smartphone Googlebot, similar to how most users access it. We've seen websites across the world embrace the mobile web, making fantastic websites that work on all kinds of devices. There's still a lot to do, but today, we're happy to announce that we now use mobile-first indexing for over half of the pages shown in search results globally.

    Checking for mobile-first indexing

    In general, we move sites to mobile-first indexing when our tests assure us that they're ready. When we move sites over, we notify the site owner through a message in Search Console. It's possible to confirm this by checking the server logs, where a majority of the requests should be from Googlebot Smartphone. Even easier, the URL inspection tool allows a site owner to check how a URL from the site (it's usually enough to check the homepage) was last crawled and indexed.

    If your site uses responsive design techniques, you should be all set! For sites that aren't using responsive web design, we've seen two kinds of issues come up more frequently in our evaluations:

    Missing structured data on mobile pages

    Structured data is very helpful to better understand the content on your pages, and allows us to highlight your pages in fancy ways in the search results. If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages. This is important because with mobile-first indexing, we'll only use the mobile version of your page for indexing, and will otherwise miss the structured data.

    Testing your pages in this regard can be tricky. We suggest testing for structured data in general, and then comparing that to the mobile version of the page. For the mobile version, check the source code when you simulate a mobile device, or use the HTML generated with the mobile-friendly testing tool. Note that a page does not need to be mobile-friendly in order to be considered for mobile-first indexing.

    Missing alt-text for images on mobile pages

    The value of alt-attributes on images ("alt-text") is a great way to describe images to users with screen-readers (which are used on mobile too!), and to search engine crawlers. Without alt-text for images, it's a lot harder for Google Images to understand the context of images that you use on your pages.

    Check "img" tags in the source code of the mobile version for representative pages of your website. As above, the source of the mobile version can be seen by either using the browser to simulate a mobile device, or by using the Mobile-Friendly test to check the Googlebot rendered version. Search the source code for "img" tags, and double-check that your page is providing appropriate alt-attributes for any that you want to have findable in Google Images.

    For example, that might look like this:

    With alt-text (good!):
    <img src="cute-puppies.png" alt="A photo of cute puppies on a blanket">

    Without alt-text:
    <img src="sad-puppies.png">

    It's fantastic to see so many great websites that work well on mobile! We're looking forward to being able to index more and more of the web using mobile-first indexing, helping more users to search the web in the same way that they access it: with a smartphone. We’ll continue to monitor and evaluate this change carefully. If you have any questions, please drop by our Webmaster forums or our public events.