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.
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)
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.
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.
Posted by John Mueller, Developer Advocate, Google Zurich
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.
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:
PageSpeed Insights provides page analysis and optimization recommendations.
Google Chrome User Experience Report provides the user experience metrics for how real-world Chrome users experience popular destinations on the web.
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.
Posted by John Mueller, Developer Advocate, Zurich
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.
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.
Posted by John Mueller, wearer of many socks, Google Switzerland
Posted by Tim Sneath, Group Product Manager for Flutter
Today, at Flutter Live, we're announcing Flutter 1.0, the first stable release of Google's UI toolkit for creating beautiful, native experiences for iOS and Android from a single codebase.
Cross-platform mobile development today is full of compromise. Developers are forced to choose between either building the same app multiple times for multiple operating systems, or to accept a lowest common denominator solution that trades native speed and accuracy for portability. With Flutter, we believe we have a solution that gives you the best of both worlds: hardware-accelerated graphics and UI, powered by native ARM code, targeting both popular mobile operating systems.
Introducing Flutter
Flutter doesn't replace the traditional Apple and Android app models for building mobile apps; instead, it's an app engine that you can either embed into an existing app or use for an entirely new app.
We think of the characteristics of Flutter along four dimensions:
Flutter enables you to build beautiful apps. We want to enable designers to deliver their full creative vision without being forced to water it down due to limitations of the underlying framework. Flutter lets you control every pixel on the screen, and its powerful compositing capabilities let you overlay and animate graphics, video, text and controls without limitation. Flutter includes a full set of widgets that deliver pixel-perfect experiences on both iOS and Android. And it enables the ultimate realization of Material Design, Google's open design system for digital experiences.
Flutter is fast. It's powered by the same hardware-accelerated Skia 2D graphics engine that underpins Chrome and Android. We architected Flutter to be able to support glitch-free, jank-free graphics at the native speed of your device. Flutter code is powered by the world-class Dart platform, which enables compilation to native 32-bit and 64-bit ARM code for iOS and Android.
Flutter is productive. Flutter introduces stateful hot reload, a revolutionary new capability for mobile developers and designers to iterate on their apps in real time. With stateful hot reload, you can make changes to the code of your app and see the results instantly without restarting your app or losing its state. Stateful hot reload transforms the way developers build an app -- and in user surveys, developers say it makes their development cycle three times more productive.
Lastly, Flutter is open. Flutter is an open source project with a BSD-style license, and includes the contributions of hundreds of developers from around the world. In addition, there's a vibrant ecosystem of thousands of plug-ins. And because every Flutter app is a native app that uses the standard Android and iOS build tools, you can access everything from the underlying operating system, including code and UI written in Kotlin or Java on Android, and Swift or Objective-C on iOS.
Put this all together, combine it with best-in-class tooling for Visual Studio Code, Android Studio, IntelliJ or the programmer's editor of your choice, and you have Flutter -- a development environment for building beautiful native experiences for iOS or Android from a single codebase.
Flutter Growth and Momentum
We announced the first beta of Flutter at Mobile World Congress ten months ago, and we've been excited to see how quickly it has been adopted by the broader community, as evidenced by the thousands of Flutter apps that are already published to the Apple and Google Play stores even before our 1.0 release. It's clear that developers are ready for a new approach to UI development.
Internally, Flutter is being used at Google for a wide array of products, with Google Ads already having switched to Flutter for their iOS and Android app. And even before 1.0, a wide range of global customers including Abbey Road Studios, Alibaba, Capital One, Groupon, Hamilton, JD.com, Philips Hue, Reflectly, and Tencent are developing or shipping apps with Flutter.
Michael Jones, Senior Director of Engineering from the Capital One team, says the following about their experiences with Flutter:
"We are excited by Flutter's unique take on high-performing cross-platform development. Our engineers have appreciated the rapid development promise and hot reload capabilities, and over the past year we have seen tremendous progress in the framework and especially the native integration story.
"Flutter can allow Capital One to think of features not in an 'iOS or Android-first' fashion, but rather in a true mobile-first model. We are excited to see Flutter 1.0 and continue to be impressed with the pace of advancement and the excitement in the engineering community."
At the Flutter Live event today, the popular payment service Square announced two new Flutter SDKs that make it easy to accept payments for goods and services with Flutter, whether in-person using a Square payment reader or by taking payments inside a mobile app. Square demonstrated an example of using their payments SDK using an app from Collins Family Orchards, a family farm that grows and sells fruit in farmers markets around the Pacific Northwest.
The developer of the Collins Family Orchards app, Dean Papastrat, had this to say about his experience:
"I was blown away by the speed of all the animations and transitions in production builds. As a web developer, it was super easy to make the transition to Flutter, and I can't believe I was able to build a fully working app that can take payments in just a week."
Also at Flutter Live, 2Dimensions announced the immediate availability of Flare, a remarkable new tool for designers to create vector animations that can be embedded directly into a Flutter app and manipulated with code. Flare eliminates the need to design in one app, animate in another, then convert all of that to device-specific assets and code.
Animations built with Flare can be embedded into an existing Flutter app as a widget, allowing them to participate in the full compositor and be overlaid with other text, graphical layers or even UI widgets. Integrating in this way frees animations from the 'black box' limitations of other architectures, and allows ongoing collaboration between designers and developers right up to the completion of the app. Such tight integration between Flutter and Flare provides a uniquely compelling offering for digital designers and animators who want to create highly-polished mobile experiences.
Another partner who has bet on Flutter is Nevercode, a fast-growing provider of continuous integration and delivery (CI/CD) tooling for mobile apps. At Flutter Live, they announced Codemagic, a new tool designed specifically for Flutter to make it easy to automate the process of building and packaging Flutter apps for both Android and iOS from a single automation. Available today in beta, Codemagic allows you to select a GitHub repo containing a Flutter project, and with just a few clicks, create continuous build flows that run tests, and generate binary app bundles that you can upload to the Apple and Google Play stores.
We put together a short video to highlight the range and variety of the apps developers have been building with Flutter since the beta:
New Features in Flutter 1.0
Since the first beta, we've been working to add features and polish to Flutter. In particular, we rounded out our support for pixel-perfect iOS apps with new widgets; added support for nearly twenty different Firebase services; and worked on improving performance and reducing the size of Flutter apps. We've also closed out thousands of issues based on feedback from the community.
Flutter also includes the latest version of the Dart platform, 2.1, an update to Dart 2 that offers smaller code size, faster type checks, and better usability for type errors. Dart 2.1 also has new language features to improve productivity when building user experiences. Developers who have already adopted Dart 2.1 tell us they're seeing significant speed improvements just by switching to the latest engine:
While the primary focus of the 1.0 release is bug fixes and stabilization, we're also introducing previews of two major new features for developers to try out in preview mode that we anticipate will ship in our next quarterly release in February 2019: Add to App and platform views.
Add to App
When we first built Flutter, we focused on productivity for the scenario where someone is building a new application from scratch. But of course, not everyone has the luxury of being able to start with a clean slate. Talking to some of our larger customers, it was clear that they wanted to use Flutter for new user journeys or features within an existing application, or to convert their existing application to Flutter in stages.
The architecture of Flutter supports this model well: after all, every Flutter app includes a host Android and iOS container. But we've been working to make it easier to incrementally adopt Flutter by updating our templates, tooling and guidance for existing apps. We've made it easier to share assets between Flutter and host code. And we've also reworked the tooling to make it easy to attach to an existing Flutter process without launching the debugger with the application.
We will continue to work to make this experience even better. Even though a number of customers are already using our guidance on Add to App successfully, we're continuing to add samples and expand support for complex scenarios. In the meantime, our instructions for adding Flutter to existing apps are on our wiki, and you can track the remaining work on the GitHub project board.
Platform Views
While Add To App is useful as a way to gradually introduce Flutter to an existing application, sometimes it's useful to go the other way round and embed an Android or iPhone platform control in a Flutter app.
So we've introduced platform view widgets (AndroidView and UiKitView) that let you embed this kind of content on each platform. We've been previewing Android support for a couple of months, but now we're expanding support to iOS, and starting to add plug-ins like Google Maps and WebView that take advantage of this.
Like other components, our platform view widgets participate in the composition model, which means that you can integrate it with other Flutter content. For example, in the screenshot above, the floating action button in the bottom right corner is a Flutter widget that has background color with 50% alpha. This demonstrates the unique architectural advantages of Flutter well.
While this work is ready for developers to try out, we're continuing to work on improving performance and device compatibility, so we recommend caution if deploying apps that depend on PlatformViews. We're continuing to actively optimize platform views and expect them to be ready for production in time for our next quarterly update.
Flutter Beyond Mobile
The primary target for Flutter has so far been iOS and Android. Yet our ambitions for Flutter extend beyond mobile to a broader set of platforms. Indeed, from the outset Flutter was architected as a portable UI toolkit that is flexible enough to go wherever pixels are painted.
Some of this work has already been taking place in the open. Flutter Desktop Embedding is an early-stage project that brings Flutter to desktop operating systems including Windows, MacOS, and Linux. We also recently published informal details of using Flutter on Raspberry Pi, as a way to demonstrate Flutter embedding support to smaller-scale devices that may not include a full desktop environment.
This week, at Flutter Live, we gave the first sneak peek of an experimental project we're working on in the labs that significantly expands where Flutter can run.
Hummingbird is a web-based implementation of the Flutter runtime that takes advantage of the capability of the Dart platform to compile not just to native ARM code but also to JavaScript. This enables Flutter code to run on the standards-based web without change.
We have a separate blog article on Medium that describes the technical implementation details of Hummingbird. And we'll have a lot more to share on Hummingbird at Google I/O in 2019: hope to see you there!
Of course, mobile remains our immediate priority, and you can expect to see the bulk of our investment in these core mobile scenarios over the coming months.
Conclusion
With the release of Flutter 1.0, we've established a new 'stable' channel, in addition to the existing beta, dev, and master channels. The stable channel updates less often than other channels, but we have a higher confidence in its quality since builds have already been vetted through the other channels. We anticipate that we'll update our stable channel on a quarterly basis with our most battle-tested builds.
We owe a particular debt to the early adopters who have joined us on the journey so far, providing feedback, identifying issues, creating content, and generally shaping the product. The Flutter community is one of our greatest assets as a project: a welcoming, diverse, helpful group of individuals who volunteer selflessly because they also care about this open source project. Thank you!
Every month, millions of Chrome users encounter pages with insufficient mobile subscription information. Surprising charges that come from unclear communication are a poor user experience. That’s why starting from Chrome 71 (December 2018), Chrome will show a warning before these pages, so that users can make informed decisions when signing up to mobile based subscription services. Users will be offered the choice to proceed to the page or go back if they were unaware that they were entering a billing page.
Unclear mobile subscriptions
Picture this: Andrea is browsing the web on a mobile connection to access a gaming page and they’re presented with a page that asks them for their mobile phone details.
They fill in the blanks with their mobile number and press Continue, and get access to the content.
The next month, the phone bill arrives and they see a charge they were not expecting. Was the subscription to the online gaming service really that expensive? Did they really agree to pay that specific price for the service? How much did they agree to be charged to access the content?
Clearer billing information for Chrome users
We want to make sure Chrome users understand when they are going through a billing flow and trust that they’ll be able to make informed decisions while browsing the web.
To adequately inform users, it’s important to provide a sufficient level of details within the billing page as outlined by our new mobile billing charges best practices. Pages that answer positively to the following questions generally provide sufficient information for users:
Is the billing information visible and obvious to users? For example, adding no subscription information on the subscription page or hiding the information is a bad start because users should have access to the information when agreeing to subscribe.
Can customers easily see the costs they’re going to incur before accepting the terms? For example, displaying the billing information in grey characters over a grey background, therefore making it less readable, is not considered a good user practice.
Is the fee structure easily understandable? For example, the formula presented to explain how the cost of the service will be determined should be as simple and straightforward as possible.
If Chrome detects pages that don’t provide sufficient billing information to users, the following warning will be displayed to the user on Chrome mobile, Chrome desktop and Android’s WebView:
The warning will be shown to users entering unclear billing pages.
When we identify such pages, we will notify the webmaster through Search Console where there will be an option to let us know about the changes they’ve made to clarify the billing process. For websites that aren’t verified on Search Console, we will do our best to get in touch with the webmasters affected and will be available to answer questions in our public support forum available in 15 languages. Once an appeal has been sent via Search Console, we will review the changes and remove the warning accordingly.
If your billing service takes users through a clearly visible and understandable billing process as described in our best practices, you don't need to make any changes. Also, the new warning in Chrome doesn’t impact your website’s ranking in Google Search.
If you have any questions, please come and have a chat with us in the Webmaster Help Forum.
Posted by Emily Schechter, Chrome Security, Giacomo Gnecchi Ruscone & Badr Salmi El Idrissi, Trust & Safety
You can view email from multiple accounts, be it your work or personal, G Suite or non-G Suite (even third-party IMAP accounts), in the Gmail iOS app. But you’ve traditionally needed to toggle between different inboxes to do so. To save you time, we’re now making it possible to view emails from multiple accounts in a single inbox on an iOS device—the same way you can with the Gmail Android app.
To see emails from different accounts at one time, simply select the “All Inboxes” view from the left-hand side drawer. This will show all your emails in a single list, but don’t worry—no emails will be shared between your accounts.
Launch Details Release track: Launching to both Rapid Release and Scheduled Release
Editions: Available to all G Suite editions
Rollout pace: Gradual rollout (up to 15 days for feature visibility)
