Tag Archives: ios

Protect corporate data on compromised iOS devices

Google Mobile Management allows G Suite admins to control access to company data on managed devices directly from the Admin console. With this launch, we’re giving admins increased power to protect their organizations’ data by preventing their users from syncing corporate data on jailbroken iOS devices.

Admins can enable this feature in the Admin console under Device Management > Advanced Settings > Security. Note that this feature is off by default and requires an organization to have Advanced Mobile Management for iOS enabled in order to turn on.


For this setting to work, users need to have the Google Device Policy app installed. Once the feature is turned on, users who don’t have the Device Policy app on their device will be prompted to install it. Once installed, the app will check if the device is jailbroken regularly, and notify the user if they pass or fail that check.


This setting should help G Suite admins and end users keep their organization’s data secure. For more details, visit the Help Center.

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 only

Action:
Admin action suggested/FYI

More Information
Help Center: Apply advanced settings


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

Loading multiple native ads in the Google Mobile Ads SDK

In the Google Mobile Ads SDK Android version 11.2.0 and iOS version 7.21.0, we added multiple native ads, a new feature for AdMob Native Ads Advanced. This feature lets you load up to five unique native ads with a single request. If you're showing native ads in a scrolling feed, this will allow you to get a batch of ads different from one another. It also means fewer network calls, which improves latency.

If you're displaying multiple native ads in a feed and loading ads one by one, converting to the new API should be fairly straightforward.

First, make a decision about how many ads you wish to fetch in one request. This is a function of how frequently you display ads in your feed. If you request five ads, AdMob will return the top five ads, ordered by eCPM value. If only three ads are available for the ad unit, only three ads will be returned.

iOS Implementation

Before initializing your ad loader, you need to create an instance of GADMultipleAdsAdLoaderOptionsand set the numberOfAdsproperty. Then include this object in the array of options when calling GADAdLoader's initializer: 

override func viewDidLoad() {
    super.viewDidLoad()

    let multipleAdsOptions = GADMultipleAdsAdLoaderOptions()
    multipleAdsOptions.numberOfAds = 5

    adLoader = GADAdLoader(adUnitID: YOUR_AD_UNIT_ID, rootViewController: self,
        adTypes: [GADAdLoaderAdType.nativeContent,
                  GADAdLoaderAdType.nativeAppInstall],
        options: [multipleAdsOptions])
    adLoader.delegate = self
    adLoader.load(GADRequest())
  }

When requesting multiple native ads, you will still get individual callbacks when each ad is loaded. For example, for an app install ad you will have a callback to -adLoader:didReceiveNativeAppInstallAd:, and for a content ad -adLoader:didReceiveNativeContentAd:. This way you don't need to change the way the ads are received and shown.

To determine when ads have finished loading, there are two new APIs available:

  1. On the GADAdLoaderobject, a new property, loading, has been added. It returns true if a request is in progress, and false otherwise. You can check this property after each ad has loaded to find out if loading ads has completed.
  2. On the GADAdLoaderDelegate, the adLoaderDidFinishLoading:method has been added. It's invoked when all ads for a request have been returned.

Android Implementation

The Android implementation is similar to iOS. There's a new method on AdLoader, loadAds() which accepts the number of ads to load. There's also a new isLoading()method that indicates whether a request is currently in progress.

For a detailed walkthrough of the implementations, see the AdMob Native Ads Advanced implementation guides (iOS| Android). If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.

 - , Mobile Ads Developer Relations

Get your ads ready for iPhone X

Cross-posted from the AdMob blog.

Every interaction a user has with your app matters. That's why we're constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.

Example of ad appearing outside of "safe area" on iPhone X

With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.

That's why we've put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated "safe areas" for this new device.

We've also updated our policiesto indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.

Please review these policy updates and our suggested implementation guide to ensure you're compliant by November 20th.

If you have any questions, visit the AdMob Help Center or contact your Google account team.

Posted by Pablo Alvarez, Product Manager, AdMob

Turning down the in-app passcode feature in Google Drive, Docs, Sheets, and Slides on iOS

In the past, we’ve heard feedback that customers want more security for the files on their iOS devices, which led us to enable an in-app passcode feature specifically for the Google Drive, Docs, Sheets, and Slides iOS apps. Over time, however, we’ve come to learn that it’s not just the content within Google Drive that’s valuable to you. Your contacts, calendars, and emails—it's important that all of this is secure as well.

As a result, we began putting particular emphasis on supporting mobile device management (MDM) on iOS. For example, recent launches give G Suite admins greater visibility and control over enterprise-deployed iOS devices. In fact, with MDM, admins can enforce a passcode on all iOS devices that access corporate data, and they can wipe account data on a device if it’s compromised.

Owing to this increased investment in security on iOS devices, we’re ending support for the in-app passcode feature in Google Drive, Docs, Sheets and Slides on iOS devices signed in with G Suite accounts. Support will end on December 4th, 2017, and we’ll remove the feature entirely no earlier than January 8th, 2018.

We highly recommend that administrators use MDM to deploy passcode requirements at the system level on all of their iOS devices by following these instructions. This will provide better security than the in-app passcode feature in two key ways:
  • These passcode policies protect all of the content on your managed devices, including photos, contacts, and other content besides Google Drive, Docs, Sheets, and Slides content.
  • These passcode policies give you more control over passcode type, strength, expiration, and failure cases. See this Help Center article for more details.

Beginning on December 4th, 2017, any user signed in with a G Suite account who has this feature will see a message asking them to either acknowledge and turn off the functionality, or to ignore the message temporarily. Beginning on January 8th, 2018, all new versions of the Google Drive, Docs, Sheets, and Slides iOS apps will no longer contain in-app passcode functionality.


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

Control mobile app settings at the organizational unit and group levels

We know that companies, especially large enterprises, are organized in complex ways, and different employees need different things. With that in mind, we’re giving G Suite Business and Enterprise admins more granular control over mobile app management, allowing them to assign different settings for different organizational units (OUs) and groups. This means that an admin can, among other things, whitelist certain apps for their executive team and others for their marketing org, or prohibit their sales team from disabling specific apps. Previously, admins could only do these things for an entire domain.


Both Android and iOS apps can be distributed at the OU and group level. For more information, check out the Help Center.

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

Editions:
Available to G Suite Business and Enterprise editions only

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

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center: Manage apps on mobile devices

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

Updates to Google Play policy promote standalone Android Wear apps

Posted by Hoi Lam, Lead Developer Advocate, Android Wear
Strava - a standalone wear app available to both Android and iOS users

Android Wear 2.0 represents the the latest evolution of the Android Wear platform. It introduced the concept of standalone apps that can connect to the network directly and work independently of a smartphone. This is critical to providing apps not only to our Android users, but also iOS users - which is increasingly important as we continue to expand our diverse ecosystem of watches and users. In addition, Wear 2.0 brought multi-APK support to Wear apps, which reduces the APK size of your phone apps, and makes it possible for iOS users to experience your Wear apps.

Today, we are announcing that multi-APKs will also work for Android Wear 1.0 watches, so you can now reach all of your users without needing to bundle your Wear app within your phone app's APK. Additionally, the Google Play Store policy will change to promote the use of multi-APKs and standalone apps. This covers all types of apps that are designed to run on the watch, including watch faces, complication data providers as well as launchable apps.

Policy change

The policy change will be effective from the 18th of January, 2018. At this time, the following apps will lose the "Enhanced for Android Wear" badge in the Google Play Store and will not be eligible to be listed in the top charts in the Play Store for Android Wear:

  • Mobile apps that support Wear notification enhancements but do not have a separate Wear app.
  • Wear apps that are bundled with mobile apps instead of using multi-APK.

Since multi-APK is now supported by devices running Wear 1.0 and 2.0, developers embedding their Wear app APKs in phone APKs should unbundle their Wear APK and upload it to the Play Store as a multi-APK. This will allow them to continue to qualify for the "Enhanced for Android Wear" badge as well as be eligible to appear in the Android Wear top charts. The two APKs can continue to share the same package name.

In addition to providing top app charts, we periodically put together curated featured collections. To be eligible for selection for these collections, developers will need to make their Wear apps function independently from the phone, as a standalone app. These apps will need to work on watches that are paired with both iOS and Android phones.

What are standalone apps?

Standalone apps are Wear apps that do not require a phone app to run. The app either does not require network access or can access the network directly without the phone app - something that is supported by Android Wear 2.0.

To mark your app as standalone, put the following meta-data tag in the AndroidManifest.xml: 

<application>
...
  <meta-data
    android:name="com.google.android.wearable.standalone"
    android:value="true" />
...
</application>

In some rare cases, the user experience may be enhanced by the syncing of data between the phone and watch. For example, a cycling app can use the watch to display the current pace, and measure the user's heart rate, while displaying a map on the phone. In this scenario, we recommend that developers ensure that their Wear apps function without a phone and treat the phone experience as optional as far as the Wear apps are concerned. In these cases, a Wear app is still considered standalone and should be marked as such in its AndroidManifest.xml file.

Wear what you want

From the beginning, Android Wear has been about wear what you want -- the styles, watches, and apps you want to wear. This latest policy change lets you highlight your Android Wear apps, giving users even more choice about what apps they want on their watches.

Anti-phishing security checks in the Gmail app for iOS

In May of this year, we introduced anti-phishing security checks in the Gmail Android app. We’re now bringing similar checks to the Gmail app on your iOS device. Going forward, when you click on a suspicious link in a Gmail message on your iPhone or iPad, we’ll show the warning below. We recommend that you use caution before proceeding, because the link is likely unsafe. Only proceed if you’re confident there’s no risk.
If you click on a link we know to be dangerous, we’ll show you a page like the one below and warn you against visiting the original URL.


These warnings are intended to prevent harmful phishing attacks and help you keep your account safe.

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: Avoid and report phishing emails


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

Set automated rules for mobile devices to protect your data

Protecting your organization’s data should be easy, regardless of what device your employees use. This is especially true if many of them use mobile devices at work. Today, we’re introducing new device rules for Mobile Management that provide better proactive management of mobile devices within your domain.

G Suite admins can now define custom rules that trigger on device events, and have associated actions. When an event specified in a rule occurs on a device within your organization with a G Suite Enterprise license, the corresponding action you have set will automatically be executed by Mobile Management.





Some examples of event/action-based rules you can set include:

  • Approve select mobile devices at the time of device enrollment.
  • Block access to corporate data if user installs a specific app.
  • Block access to/Account wipe the device if user has more than five failed screen unlock attempts.
  • Block access to/Account wipe the device if there is suspicious activity found on the device.
If you’re looking for a device rule that isn’t covered in an existing template, you can customize your own rule. Previously, you would have needed to create a custom script and leverage our APIs to automate any mobile device actions.



Our goal with this launch is to automate the manual, repetitive tasks you often execute as mobile administrators while also keeping your organization’s data protected. Get started today with the instructions in this Help Center article.

Launch Details

Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to G Suite Enterprise editions only

Rollout pace:
Gradual rollout (up to 15 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center: Automate Mobile Management tasks with rules

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

Simpler mediation with AdMob and DFP

Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.

Open Source Mediation Adapters on GitHub

In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android:

In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app.

Import Mediation Adapters with CocoaPods and Gradle

In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this: 


    pod 'GoogleMobileAdsMediationMoPub'

...or their build.gradle file with a line like this: 


    compile 'com.google.ads.mediation:mopub:11.10.1.0'

With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section.

Network-specific guides

Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry.

To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter.

For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android).

Questions?

If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.

 - , Mobile Ads Developer Relations

New iOS enterprise security features now available, including corporate contacts

A recent Gartner surveyfound that more than two thirds of employees are using personal devices at work, and we're seeing similar stats with our customers: enterprises are embracing Bring Your Own Device (BYOD) devices. That's why we're giving more control to G Suite admins with enhancements to Google Mobile Management, adding several new iOS featuresfor enterprise security, including the popular feature request for managed corporate contacts.



Manage iOS Settings in Google Mobile Management
About Managed Corporate Contacts
G Suite admins will now be able to sync managed corporate contacts to their users' devices. This will improve iOS device compliance in the following ways:
  • Easy setup of contacts during MDM setup. The user’s corporate contacts are synced automatically when an iOS device is compliant, and no longer available when device goes out of compliance.
  • Searching and calling contacts from the global address list (GAL) is possible from the native iOS phone app. Additionally, native email, calendar, contacts iOS apps can look up your GAL contacts.
  • Caller ID is supported when receiving a call from a user's corporate contact.
  • If your organization requires your users to use 2-step verification or you use a 3rd-party SSO provider, your users will no longer need to use an App password when accessing their corporate contacts on the iOS device
  • If the admin blocks or wipes the account, the user's corporate contacts are no longer available and they no longer have access to the GAL.
In addition to these changes, we're also adding or updating the following device restriction policies:
  • Managed apps: Manage app author, settings and storage
  • Account configuration: Automatically configure Google account on iOS to sync contacts, calendar
  • Safari: Manage Safari browser settings
  • Photos: Manage photo sharing on iOS
  • Advanced security: Allow screenshots and screen recording, Siri, Apple Watch, and more



We hope this makes it easier for G Suite admins to manage iOS users in their domain. Look out for more exciting MDM updates in the future.
Launch Details
Release track:
Launching to both Rapid release and Scheduled release

Available to all G Suite editions

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

Impact:
Availability: All iOS devices managed using advanced management are applicable to have the new features applied

Action:
Admin action suggested/FYI
More Information
Help Center: Apply settings for iOS mobile devices