Tag Archives: ios

iOS Accessibility Scanner Framework

At Google, we are committed to accessibility and are constantly looking for ways to improve our development process to discover, debug and fix accessibility issues. Today we are excited to announce a new open source project: Accessibility Scanner for iOS (or GSCXScanner as we lovingly call it). This is a developer tool that can assist in locating and fixing accessibility issues while an app is being developed.

App development can be a time consuming process, especially when it involves human testers. Sometimes, as in the case with accessibility testing, they are necessary. A developer can write automated tests to perform some accessibility checks, but GSCXScanner takes this one step further. When a new feature is being developed, often there are several iterations of code changes, building, launching and trying out the new feature. It is faster and easier to fix accessibility issues with the feature if they can be detected during this phase when the developer is working with the new feature.

GSCXScanner lives in your app process and can perform accessibility checks on the UI currently on the screen simply with the touch of a button. The scanner’s UI which is overlaid on the app can be moved around so you can use your app normally and trigger a scan only when you need it. Also, it uses GTXiLib, a library of iOS accessibility checks to scan your app, and you can author your own GTX checks and have them run along with scanner’s default checks.

Using the scanner does not eliminate the need for manual testing or automated tests, these are must haves for delivering quality products. But GCSXScanner can speed up the development process by showing issues in app during development.

Help us improve GSCXScanner by suggesting a feature or better yet, writing one.

By Sid Janga, Central Accessibility Team

Google Drive is getting a new look on iOS and Android

What’s changing  

Google Drive is getting a new look and feel on iOS and Android, making it easier to communicate and collaborate across files in Drive on mobile devices.



This Material redesign is part of a larger effort to bring the look and feel of our G Suite apps together as a whole, with ease-of-use in mind.

Some improvements you’ll see include:
  • New Home tab and bottom navigation 
    • Similar to Drive on the web, the Home tab will surface the files that are most important to you, based on things like: 
      • The last time you accessed or edited a file 
      • Who specific files are frequently shared with 
      • What files are used at specific times of day.
  • A more intuitive bottom navigation bar that features options to switch between Home, Starred, files shared with you (Shared), and all files (Files), allowing for quicker access to your most important items.

  • Expanded search bar 
    • The search bar is now more accessible across the application, including from the Team Drives page.
  •  My Drive, Team Drives and Computers in Files view 
    • Team Drives will be now be displayed as a tab next to My Drive in the Files view. Users will also see a Computers tab if they have backed up content from a local machine to their account. 

    •  New account switching experience 
      • The feature to switch accounts is moving from the left navigation menu to an icon in the top right.


      •  Revised actions menu 
        • A revised actions menu attached to every file and folder emphasizes the most frequently used actions at the top. Toggles for starred and offline are now changed to buttons.

        Who’s impacted 

        End users

        Why you’d use it 

        We know that mobile devices are critical to getting work done, whether it’s at our desk, in a meeting, sending an email, or collaborating. Drive is not just a way to backup files to the cloud, but a critical way to easily share work, make last minute changes to content, or review important content on the go. The Drive Mobile redesign aims to make these workflows easier.

        How to get started 

        • Admins: No action required. 
        • End users: You’ll see the new look coming your way soon. 

        Additional details

        iOS users will begin seeing the redesign starting on March 12, 2019. Android users will see the redesign starting on March 18, 2019.

        To help your users navigate this redesign, see this change management guide or download this PDF.

        Helpful links 

        View the change management guide for this update. Also available as a PDF.
        Using Google Drive on Android
        Using Google Drive on iOS 

        Availability 

        Rollout details 
        • iOS: Gradual rollout (up to 15 days for feature visibility) rollout starting March 12, 2019.
        • Android: Gradual rollout (up to 15 days for feature visibility) rollout starting March 18, 2019. 
        G Suite editions 
        Available to all G Suite Editions.

        On/off by default? 
        This feature will be ON by default.

        Stay up to date with G Suite launches

        Getting screen brightness right for every user

        Posted by Ben Murdoch, Software Engineer and Michael Wright, Android Framework Engineer

        The screen on a mobile device is critical to the user experience. The improved Adaptive Brightness feature in Android P automatically manages the display to match your preferences for brightness level so you get the best experience, whatever the current lighting environment.

        Screen brightness in Android is managed via Quick Settings or via the settings app

        (Settings → Display → Brightness Level).

        In Android Pie, Adaptive Brightness is enabled by default (Settings → Display → Adaptive Brightness).

        While enabled, Android automatically selects a screen brightness that's suitable for the user's current ambient light conditions. Prior to Android Pie, the brightness slider didn't represent an absolute screen brightness level, but a global adjustment factor for boosting or reducing the device manufacturer's preset screen brightness curve across all ambient light levels:

        * Setting the slider to center resulted in the device using the preset.

        * Setting the slider to the left of center applied a negative scale factor, making the screen dimmer than the preset.

        * Setting the slider to the right of center applied a positive scale factor, making the screen brighter than the preset.

        So, under low ambient light conditions, you might prefer a brighter screen than the preset level and move the brightness slider up accordingly. But, because that adjustment would boost the brightness at all ambient light levels, you might find yourself needing to move the brightness slider back down in brighter ambient light. And so on, back and forth.

        To improve this experience, we've introduced two important changes to screen brightness in Android Pie:

        1. Better slider control
        2. Personalization of the brightness level

        Better slider control

        The slider control now represents absolute screen brightness rather than the global adjustment factor. That means that you may see it move on its own while Adaptive Brightness is on. This is expected behavior!

        Humans perceive brightness on a logarithmic rather than linear scale1. That means changes in screen brightness are much more noticeable when the screen is dark versus bright. To match this difference in perception, we updated the brightness slider UI in the notification shade and System Settings app to work on a more human-like scale. This means you may need to move the slider farther to the right than you did on previous versions of Android for the same absolute screen brightness, and that when setting a dark screen brightness you have more precise control over exactly which brightness to set.

        Personalization of screen brightness

        Prior to Android P, when developing a new Android device the device manufacturer would determine a baseline mapping from ambient brightness to screen brightness based on the display manufacturer's recommendation and a bit of experimentation. All users of that device would receive the same baseline mapping and, while using the device, move the brightness slider around to set their global adjustment factor. To determine the final screen brightness, the system would first look at the room brightness and the baseline mapping to find the default screen brightness for that situation, and then apply the global adjustment factor.

        What we found is that in many cases this global adjustment factor didn't adequately capture personal preferences - that is, users tended to change the slider often for new lighting environments.

        For Android Pie we worked with researchers from DeepMind to build a machine learning model that will observe the interactions that a user makes with the screen brightness slider, and train on-device to personalise the mapping of ambient light level to screen brightness.

        This means that Android will learn what screen brightness is comfortable for a user in a given lighting environment. The user teaches it by manually adjusting the slider, and, as the software trains over time, the user should need to make fewer manual adjustments. In testing the feature, we've observed that after a week almost half our test users are making fewer manual adjustments while the total number of slider interactions across all internal test users was reduced by over 10%. The model that we've developed is updatable and will be tuned based on real world usage now that Android Pie has been released. This means that the model will continue to get better over time.

        We believe that screen brightness is one of those things that should just work, and these changes in Android Pie are a step towards realizing that. For the best performance no matter where you are models run directly on the device rather than the cloud, and train overnight while the device charges.

        The improved Adaptive Brightness feature is now available on Pixel devices and we are working with our OEM partners now to incorporate Adaptive Brightness into Android Pie builds for their devices.

        Notes

        View emails from multiple accounts at once in the Gmail iOS app

        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)

        Impact:
        All end users

        Action:
        Change management suggested/FYI

        More Information
        Help Center: Check emails from other accounts


        Launch release calendar
        Launch detail categories
        Get these product update alerts by email
        Subscribe to the RSS feed of these updates

        Google Device Policy app ending support for iOS 8.0 soon

        The next release of the Google Device Policy app (version 3.04) won’t support mobile devices running iOS version 8.0 or lower. If your organization has advanced mobile device management (MDM) enabled, your users must upgrade to iOS version 9.0 or higher to access new MDM features or if they need to download the Device Policy app for the first time.

        We’re planning to release version 3.04 of the Device Policy app as early as next week. Please encourage your users to upgrade their iOS devices as soon as possible to avoid any disruption to their work.

        More Information
        Help Center: Minimum device requirements 

        Launch release calendar
        Launch detail categories
        Get these product update alerts by email
        Subscribe to the RSS feed of these updates

        Secure corporate data on employee iOS devices with managed apps

        To better protect the G Suite data stored on your employees’ personal iOS devices, you can now specify that certain iOS apps be “managed” if your domain has advanced mobile device management enabled.

        If an app is managed, you can:
        • Prevent the app’s data from being backed up to iCloud.
        • Block unmanaged apps from opening managed app files.


        Note that these actions will impact both personal and corporate data on managed apps. Visit the Help Center for more information on how to manage apps on iOS devices.

        Designate an app as managed
        When you whitelist a new app for iOS devices, you can now choose to “Make this a managed app.” Once you make the app managed, you can also select to have it automatically removed from a device if that device’s MDM profile is removed.

        When you whitelist a new app for iOS devices, you can now make it “managed.”


        If you previously whitelisted an app, you can make it managed by changing that app’s settings in the Admin console.
        You can make an app you’ve already whitelisted managed by editing the app’s configuration in the Admin console.


        User notifications and required actions
        If you designate an app as managed, any users with that app downloaded will be prompted to update it in their Google Device Policy app.

        Users will be prompted to update apps that are marked as managed by their admins. 

        Users need to accept management of their apps or they’ll lose access to all corporate data on their phone.


        If a user doesn’t take action within 12 hours of receiving the notification, they’ll receive another notification prompting them to make the required apps managed.


        If a user doesn’t take action within 24 hours of receiving the notification, they’ll no longer be able to access corporate data anywhere on their device.


        Note that if you make a previously managed app “unmanaged,” users will need to remove the Google Apps Device Policy Payload Profile before the app becomes unmanaged.

        Launch Details
        Release track:
        Launching to both Rapid Release and Scheduled Release

        Editions:
        Available to all G Suite editions

        Rollout pace:
        Extended rollout (potentially longer than 15 days for feature visibility)

        Impact:
        Admins and end users

        Action:
        Admin action suggested/FYI

        More Information
        Help Center: Recommend and manage iOS apps


        Launch release calendar
        Launch detail categories
        Get these product update alerts by email
        Subscribe to the RSS feed of these updates

        Announcing the Mediation Test Suite Beta

        Today we're announcing the release of Mediation Test Suite Beta. Mediation Test Suite is a lightweight SDK that enables Google AdMob publishers to easily test mediation ad network integrations without having to make changes in the AdMob UI, saving you and your developers time. It is available on Android, iOS, and Unity.

        Mediation Test Suite allows you to:

        • View a full list of mediation ad source configurations for your app
        • Automatically check your project for missing SDKs, adapters, and manifest changes required by partner ad sources
        • Load a banner, interstitial, rewarded, or native ad for any ad source using a certified Google Mobile Ads SDK implementation
        • Batch test multiple ad sources for the same ad unit
        • Test both open source mediation adapters and custom event adapters

        Integrating Mediation Test Suite is easy -- once you have the SDK imported, it can be launched with just a single line of code. All you need is your AdMob app ID.

        On Android, the launch code looks like this:

        import com.google.android.ads.mediationtestsuite.MediationTestSuite;
        ...
        String appId = "YOUR-ADMOB-APP-ID";
        MediationTestSuite.launch(MainActivity.this, appId);

        On iOS, all that's required is importing the correct header and launching the Test Suite:

        #import "GoogleMobileAdsMediationTestSuite.h"
        ...
        NSString* appId = @"YOUR-ADMOB-APP-ID"
        [GoogleMobileAdsMediationTestSuite presentWithAppID:appId
        onViewController:self delegate:nil];

        Unity is just as simple, but please note that you need to use the appropriate app ID for your platform:

        using GoogleMobileAdsMediationTestSuite.Api;
        ...
        #if UNITY_ANDROID
        string appId = "YOUR-ANDROID-ADMOB-APP-ID";
        #elif UNITY_IPHONE
        string appId = "YOUR-iOS-ADMOB-APP-ID";
        #else
        string appId = "";
        #endif
        MediationTestSuite.Show(appId);

        Including Mediation Test Suite in production builds is optional

        You are not required to keep the Mediation Test Suite library in the production release of your app; however, you may choose to leave it in and hide it behind a debug gesture. Doing so enables you to launch Mediation Test Suite within your production build.

        You can find more information about how to use Mediation Test Suite in the developer guide (Android | iOS | Unity). Remember that Mediation Test Suite is a beta product, so if you have any questions or feedback, please contact us on the developer forum.

        Consent SDK removes limit of 12 ad technology providers

        To support publishers in meeting their duties under the Google EU User Consent Policy, Google offers a Consent SDK. The Consent SDK is an open-source library that provides utility functions for collecting consent from your users. The full source code is available on GitHub.

        With the latest release of the Consent SDK (v1.0.5 for Android or v1.0.2 for iOS), the Google-rendered consent form is now compatible with any number of ad technology partners, including the full list of commonly used partners. Apps that update to the latest version of the Consent SDK can start taking advantage of this additional flexibility immediately.

        You can find additional documentation for the Consent SDK on the Google Mobile Ads Android and iOS developer docs. If you have any questions about implementing the Consent SDKs, you can reach us on our forum.

        [Video] Hamilton app built in 3 months with Flutter reaches 1M+ installs

        Originally posted on Flutter's Medium by Martin Aguinis

        Hamilton and Posse, a design and development agency in New York, had three short months to develop and launch mobile apps for the hit Broadway show. How did they accomplish that? Using Flutter, Google's new mobile UI framework.

        Reaching millions of users — with an outstanding half a million monthly active users and featured on both the App Store and Google Play— the apps let fans enter the ticket lottery, buy merchandise, play trivia, take selfies with a #HamCam, read frequently updated news and interviews, and more.

        Watch this video case study to see how Flutter continues to help apps like Hamilton succeed on iOS and Android. You can read more details about the development of this app on Posse's blog post.

        Flutter is free and open source. Get started today at flutter.io. We can't wait to see what you build!

        Open sourcing GTXiLib, an accessibility test automation framework for iOS

        Google believes everyone should be able to access and enjoy the web. We share guidance on building accessible tech over at Google Accessibility and we recently launched a dedicated disability support team. Today, we’re excited to announce that we’ve open sourced GTXiLib, an accessibility test automation framework for iOS, under the Apache license.

        We want our products to be accessible and automation, with frameworks like GTXiLib, is one of the ways we scale our accessibility testing. GTXiLib can automate the process of checking for some kinds of issues such as missing labels, hints, or low contrast text.

        GTXiLib is written in Objective-C and will integrate with your existing XCTests to perform all the registered accessibility checks before the test tearDown. When the checks fail, the existing test fails as well. Fixing your tests will thus lead to better accessibility and your tests can catch new accessibility issues as well.
        • Reuse your tests: GTXiLib integrates into your existing functional tests, enhancing the value of any tests that you have or any that you write.
        • Incremental accessibility testing: GTXiLib can be installed onto a single test case, test class or a specific subset of tests giving you the freedom to add accessibility testing incrementally. This helped drive GTXiLib adoption in large projects at Google.
        • Author your own checks: GTXiLib has a simple API to create custom checks based on the specific needs of your app. For example, you can ensure every button in your app has an accessibilityHint using a custom check.
        Do you also care about accessibility? Help us sharpen GTXiLib by suggesting a check or better yet, writing one. You can add GTXiLib to your project using CocoaPods or by using its Xcode project file.

        We hope you find this useful and look forward to feedback and contributions from the community! Please check out the README for more information.

        By Siddartha Janga, Google Central Accessibility Team