Tag Archives: Google Play

Announcing the Winners from the Indie Games Festival in San Francisco

Posted by Kacey Fahey, Developer Marketing, Google Play

At the Google Play Indie Games Festival over the weekend, we welcomed hundreds of attendees to try out and enjoy a diverse range of amazing games from the indie community. The competition was very tough, and in the end, we recognized three winners:

We'd also like to congratulate the rest of the Top 10 developers and all of the finalists who shared their games to make for such a fun and exciting event. Check out the great collection of games on Google Play.

Here are the other seven games that rounded out the Top 10:

The day started with time for attendees to play the 20 finalists' games. They experienced different genres and styles of gameplay and were encouraged to talk with the developers about their work and what it's like to make mobile games for a living. The event brought together kids, adults, gaming enthusiasts and non-gamers, and was a great representation of the fun experiences mobile games create.

In the afternoon, attendees voted for their favorites and the Top 10 moved on to the presentation round. These developers had three minutes to deliver their best pitch to the panel of judges. After the judges voted, results were in and the three winners and seven runners up were named.

If you like indie games and want to keep up with our favorite indie picks, visit the Indie Corner on Google Play.

How useful did you find this blogpost?

SafetyNet Verify Apps API, Google Play Protect at your fingertips

Posted by William Luh, Software Engineer

Google Play Protect, which includes the Verify Apps security feature, helps keep users safe from harmful apps. Google Play Protect is available on all Android devices with Google Play installed and provides users with peace of mind and insights into the state of their device security.

App developers can get similar security insights into the installed apps landscape on user devices from the SafetyNet Verify Apps API. This new suite of APIs lets developers determine whether a user's device is protected by Google Play Protect, encourage users not already using Google Play Protect to enable it, and identify any known potentially harmful apps (PHAs) that are installed on the device.

These APIs are especially useful for developers of apps that may be impacted by installed PHAs on the same device as their app. Determining that Google Play Protect is enabled with isVerifyAppsEnabled() gives developers additional assurance that a device is more likely to be clean. If a device doesn't have Google Play Protect enabled, developers can request that the user enable Google Play Protect with enableVerifyApps(). With Google Play Protect enabled, developers can use the listHarmfulApps() method to determine whether there are any potentially harmful apps installed on a user's device. This easy-to-use suite of features does not require API keys and requesting quota.

Enterprise-focused apps in particular may benefit from using the Verify Apps API. Enterprise apps are designed to safeguard a company's data from the outside world. These apps often implement strict enforcements, such as ensuring the mobile device is approved by the enterprise and requiring a strong password for lockscreens. If any of the criteria are not satisfied, the enterprise may revoke credentials and remove sensitive data from the device. Having a mechanism to enforce Google Play Protect and scan for PHAs is another tool to help enterprise app developers keep enterprise data and devices safe.

For better protection, developers should use the attestation API along with the new Verify Apps API. Use the attestation API first to establish that the device has not been modified from a known state. Once the Android system can be trusted, the results from the Verify Apps API can be trusted. Existing attestation API users may find additional benefits in using the Verify Apps API as it may be able to detect on-device PHAs. In general, using multiple signals for anti-abuse detection is encouraged.

To learn how to use this API in your app, check out the developer docs.

Helping indie developers get discovered on Google Play

Posted by Adriana Puchianu, Google Play Developer Marketing

There are increasing growth opportunities for indie game developers, but being one can still feel daunting in today's crowded gaming industry. We've been working hard to help indie developers find an audience and to recognize them for their creativity and innovation. We launched the Indie Corner as a destination for exciting new games along with longstanding indie masterpieces. Since launch, more than 380 games have been featured. Earlier this year, we launched Android Excellence which showcases apps and games that deliver incredible user experiences on Android, while providing another opportunity to be discovered on Google Play.

We've also held several indie games contests across the globe, giving indies the chance to showcase their games and find new audiences. In April, we selected the winner of the second Indie Games Festival in South Korea and we recently announced the top 20 finalists of this year's San Francisco event. Come and see the finalists in person on September 23rd, it's free to attend and open to the public. Soon we'll be bringing back the second Indie Games Contest in Europe too.

Watch François Alliot, the developer of Reigns, an indie game showcased in Android Excellence and the winner of last year's Indie Games Contest in Europe, share how he built a successful games business in the video below.

And, finally, check out our recent Q&A with Spry Fox, makers of the popular game Alphabear, to learn more about what it’s like to be an indie game developer.

How useful did you find this blogpost?

Optimize your Android apps for Chromebooks

Posted by Cheryl Lindo Jones, Mobile App Solutions Consultant, Google Play

As more Chromebooks are enabled with Google Play, now is a great time to optimize your Android app for Chromebooks to reach a larger audience. The changes made to optimize for large screens will benefit mobile devices that are able to project to desktop monitors, like the Samsung Galaxy S8. The current list of Chromebooks that can access the Play Store continues to grow.

There are several differences to consider when optimizing your Android app or game for Chromebooks:

  • Larger screen sizes and higher resolutions
  • Multi-window and resizable-window support
  • Different hardware input methods: keyboard, trackpad, mouse, stylus
  • Convertible Chromebooks enabling use in laptop and tablet modes

Chromebook users can change screen resolutions, switch between various input methods, and convert from laptop to tablet mode at any time, so Android apps and games should handle all of these situations gracefully.

Discoverability on Google Play

If Android apps or games require hardware not available in a Chromebook (like cellular capability or GPS), those titles will not show up on Google Play for Chromebook users, similar to Play on Android tablets. Developers should maximize discoverability on Google Play by doing the following:

Set requested permissions and uses-features in the manifest to ensure compatibility with Chromebooks. Not all Chromebooks will have touchscreens, GPS, or rear-facing cameras which are typical for smartphones. Update the manifest so that sensors and hardware not commonly found on Chromebooks are not required. Example:

<uses-feature android:name="android.hardware.touchscreen"
    android:required="false" />

Additionally, to educate Chromebook users on any Chrome OS-specific features that have been implemented, for example supporting additional input methods like keyboard, trackpad, and stylus, or supporting large, high-resolution screens with a responsive layout, developers should update the app description on Google Play. It would also be useful to provide screenshots showcasing how well the app or game works on the larger screen, or how the title works on a Chromebook specifically.

Optimizing functionality

While most apps and games already work fairly well on Chromebooks without any changes, it is still a good idea to explore how to provide an optimized, consistent experience for Chromebook users.

Large screens and resizable windows

Chromebook users will be more inclined to multitask, opening multiple apps and/or games at once, taking advantage of the screen size, and operating in a manner consistent with a desktop or laptop form factor. Unlike on Android phones, they can also change the screen resolution to fit more onto the screen, or enlarge the fonts, UI, and graphics, if needed. Multi-window support and fully resizable window support are key for this usage. Graphics, fonts, layout, and touch targets should be adjusted accordingly as the screen resolution and orientation changes.

It is also important to note that just because an app or game window is not in focus, it does not mean that it is not visible. For example, if a video app is open in an inactive window, it should continue to play content "in the background" because it could still be visible along side another app window. To fully support multi-window usage in this case, pause video in onStop(), and resume in onStart().

Targeting Android N (API level 24 and higher) will signal to the Chrome OS window manager that compatibility restrictions should not be used. This allows for more flexibility and control on the developer's part for supporting window resizing.

The system will handle window management best if Android N is targeted, but for pre-N API support, windows can be toggled between either a default size selected at app launch, or a full-screen mode with either the window bar visible, or with window UI hidden in immersive full-screen mode.

When handling different windowing modes, it is important to know that the window area for an app or game will be offset by the presence or absence of the window control bar. The app should not assume that the activity will always be at (0,0) in the window. Adjust the layout and touch targets accordingly. It is somewhat common to see apps or games become unresponsive after a window resize or orientation change because it did not gracefully handle the presence of the window control bar, or the higher resolution settings of a Chromebook screen.

Orientation support

Because of the laptop form-factor, Chromebook users expect landscape to be the default orientation for apps on Chromebooks. However, Android apps often assume that portrait is the default orientation to support, due to the typical way users interact with their smartphones. To offer flexibility to users, it is highly recommended to support both portrait and landscape orientations. Some Chromebooks are convertible, so users can change between laptop and tablet modes at will, switching between portrait and landscape orientation, according to what feels comfortable for a given use case.

Most importantly, if possible, do not require a restart if the orientation or window size changes. If a user is in the process of filling out a form, creating or editing some content, or in the middle of a level in a game and loses progress because of an window change -- intentional or not -- it would be a poor user experience.

Developers can monitor window configuration changes using onConfigurationChanged() and dynamically handle those changes by adding this line to the activity's manifest:

android:configChanges="screenSize|smallestScreenSize|orientation|screenLayout".

If it is absolutely necessary to require a restart upon changes to the window, at least restore state by using the onSaveInstanceState() method so that work or state is not lost.

Additionally, it is important to be consistent with the app's orientation as the user is navigating through activities. Currently, the system forces Android apps to follow the orientation of the root activity to help maintain consistency. However, this may result in a situation where, perhaps an app starts out in landscape orientation, and a login screen normally laid out for portrait orientation pops up, and now does not look optimized due to an unresponsive layout. Also, it is still possible to have a case where a springboard activity starts out in an orientation that is different from the primary orientation of the app. Please keep these possible scenarios in mind when designing the layout for activities.

Finally, developers should be aware of the differences in handling cameras and orientation on Chromebooks. Obviously, Android phones have front-facing and rear-facing cameras that are situated at the top of a portrait-oriented screen. The front-facing cameras on Chromebooks are situated at the top of a landscape-oriented screen. Many Chromebooks do not have rear-facing cameras. If an app requires a camera, it would be best to use android.hardware.camera.any to access the front-facing camera, if a rear-facing one is not available. Again, developers should target Android N and, if possible allow the app to be resizable so that the system can take care of properly orienting the camera previews.

Supporting multiple input methods

Chromebook users are used to interacting with webpages and apps using a keyboard and trackpad. Effectively supporting these two input methods for an Android app means:

  • Supporting hotkeys for commands that a desktop app user may be familiar with
  • Using arrow and tab keys and a trackpad to navigate an activity
  • Allowing hover and opening context menus
  • Supporting other trackpad gestures to enhance productivity in desktop/laptop mode

Something as simple as hitting return to send text in a messaging app, or allowing a user to navigate fields by hitting the tab key will make an app feel more efficient and cohesive on a Chromebook.

While there is a compatibility mode for Chrome OS to emulate touchscreen scrolling and other touch events, it would be best to optimize an Android app by declaring

<uses-feature
    android:name="android.hardware.type.pc"
    android:required="false" />

in the manifest to disable compatibility mode in order to further define custom support for keyboard and trackpad.

Similarly, the system can guess at giving focus to the right views when navigating via the tab or arrow keys on a keyboard. But for best performance, specify how keyboard navigation should be handled in the activity manifest using the android:nextFocusForward attribute for tab navigation, and android:nextFocusUp, android:nextFocusDown, android:nextFocusLeft, android:nextFocusRight attributes for arrow key navigation.

On a related note, some Chromebooks do not have touchscreens, therefore well-optimized Android apps on Chrome should not assume the user can perform typical swipe and multi-touch tap gestures to navigate through an app or game. If primary functionality cannot be performed using only a keyboard or trackpad, the user experience will be severely impacted on non-touchscreen Chromebooks. Try to "translate" existing touchscreen tap and swipe gestures into something that can be easily done on a trackpad or using the keyboard.

Newer Chromebooks are gaining stylus support, allowing for richer interactions for sketchbook and note-taking apps, photo editors, games, and more. Developers are encouraged to use available APIs to support pressure-sensitivity, tilt, and eraser inputs. To enable users to comfortably rest their hands on the screen while writing, drawing, or playing games with the stylus, support palm rejection. The system will attempt to ignore input from a user's resting palm, but in case such erroneous touch events are registered, Android apps should gracefully handle ACTION_CANCEL events to erase the erroneous inputs.

By supporting all of these additional input methods, users will be able to take full advantage of the laptop mode for Chromebooks to work more efficiently, or to be more creative.

Learn more

While a lot was covered in this article, we have additional resources for you to learn more about optimizing their apps and games for Chromebooks. Read our Medium post with tips to get your app running great on Chromebooks and watch our session at Google I/O 2017, Android Apps for Chromebooks and Large Screen Devices. There is also training material on the Android developers website for building apps for Chrome OS. If you have any questions, reach out to the Android developer community and post with the hashtag #AndroidAppsOnChromeOS.

How useful did you find this blogpost?

Enroll for app signing in the Google Play Console & secure your app using Google’s robust security infrastructure

Posted by Kobi Glick, Product Manager, Google Play

Every app on Android is signed with a key. This key is used to ensure the app's integrity by checking that updates are signed with the same signature. In the past, the burden of securely holding the signing key has always been with the developer. We're now offering an app signing service on Google Play that can help you if you lose or compromise your key.

Until recently, losing your key would make it impossible to update your app with a new version. A compromised key would be a serious issue too: a third-party could maliciously replace an authentic app or corrupt it. Unfortunately in such cases, the only solution was to publish a new app, with a new package name and key, and ask all of your users to install it.

App signing in the Play Console allows us to offer help in such circumstances. For existing apps, it requires transferring your app signing key to Google Play. For new apps, we can generate your app signing key. Once enrolled in app signing, you sign your APK with an upload key, which we use to authenticate your identity. We'll then strip that signature and re-sign your app with the app signing key.

The app signing key is now securely managed by Google Play meaning that you are only responsible for managing your upload key. If your upload key is compromised or lost, our developer operations team can assist by verifying your identity and resetting your upload key. We'll still re-sign with the same app signing key, allowing the app to update as usual.

Rest assured, your key will be fully protected by Google's robust cloud security infrastructure and will benefit from the ongoing investment we're making to our security systems. In the future, we plan to offer developers who sign with Google Play automatic optimizations to enhance their app distribution. Stay tuned for more news in this area!

Learn more about how app signing works in the help center or watch the session about app signing from Google I/O 2017. Get started on securing your app in the release management section of the Play Console.

How useful did you find this blogpost?

Android Developer Story: Zalando increases installs and revenue by focusing on app quality

Posted by Adriana Puchianu

Based in Berlin, Zalando is Europe's leading online fashion platform. With more than 70% of its traffic now coming from mobile, the company has invested a lot in improving the quality of its app to provide a good user experience. Investing in bridging the online and the offline worlds, as well as providing a seamless cross-platform experience, has had positive results on their user engagement and revenue. Using features like A/B testing, the pre-launch report and the new release dashboard from the Google Play Console, Zalando saw a 6% increase in installs and a 15% increase in the users' lifetime value.

Watch Rushil Dave, Senior Product Specialist and Meritxell Rivera, Android Developer discuss how the company has improved user experience and key revenue and engagement metrics by investing in app quality for their Zalando app.

How useful did you find this blogpost?

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.

Automatic protections in Android: Q&A with a security expert

Editor's note: The Android security team works to keep more than two billion users safe, and with the release of Android Oreo, they’ve rolled out some new security protections. We sat down with Adrian Ludwig, Director of Android Security to learn about his team, their approach to security, and what Oreo’s new protections mean for people who use and love Android.

Keyword: Talk to us a bit about what your team does.

Adrian: We build security features for Android that help keep the whole ecosystem safe. Our software engineers write code that encrypts user data, helps find security bugs faster, prevents bugs from becoming security exploits, and finds applications that are trying to harm users or their information.  

How do you build these protections?

It starts with research. Because security is constantly evolving, our teams have to understand today’s issues, in Android and elsewhere, so we can provide better security now and in the future. Researchers in and out of Google are like detectives: they find new stuff, work to understand it deeply, and share it with the broader security community.

We then use those findings to make our protections stronger. We’re focused on tools like Google Play Protect and efforts like “platform hardening,” incremental protections to the Android platform itself. We’re also starting to apply machine learning to security threats, an early stage effort that we’re really excited about.

The final step is enabling all Android users to benefit from the protections. I’m really proud of the work our team has done with Google Play Protect, for example. Every day, it monitors more than 50 billion apps in Play, other app marketplaces, and across the web for potentially unsafe apps. If it finds any, we’ll prevent people from installing them and sometimes remove them from users’ phones directly. Users don’t need to do anything—this just works, automatically.

What are the challenges to protecting Android?

In security, we often talk about the trade-off between usability and protection. Sometimes, you can protect a device more effectively if there are certain things users can’t do on your device. And security is always much easier when things are predictable: for instance when all of the devices you are protecting are built the same way and can basically do the same thing.

But, Android security is different because the ecosystem is so diverse. The variety of use cases, form factors, and users forces us to be open-minded about how we should secure without limiting Android’s flexibility. We can’t possibly protect Android users with a single safeguard—our diversity of protections reflects the diversity in the Android ecosystem.

What are some of the new ways you’re protecting users in Android Oreo (not in robo- speak, please)?

Hang on, I gotta turn on Google Translate.

There are a … 0101100110 … sorry … a bunch! We’ve invested significantly in making it easier to update devices with security “patches,” fixes for potential safety problems, more commonly known as vulnerabilities. As a sidenote, you may have heard about “exploits.” If a vulnerability is a window, an exploit is a way to climb through it. The vast majority of the time, we’ll patch a vulnerability before anyone can exploit it. We have a project called Treble that makes it easier for us to work with partners and deliver updates to users. We want to close the window (and add some shutters) as quickly as possible.

We’ve also worked to improve verified boot, which confirms the device is in a known good state when it starts up, further hardened the Android kernel, which makes sure that hackers can’t change the way that code executes on a device, and evolved Seccomp which limits the amount of code that is visible to hackers.  Basically, we’re moving all the windows higher so any open ones are harder to climb through.

You announced Google Play Protect earlier this year. Tell us a bit about that and why it’s important for Android users?

For several years, we’ve been building “security services” which periodically check devices for potential security issues, allow Google and/or the user to review the status, and then use that information to protect the device. These services interact with Google Play in real-time to help secure it, hence the name “Google Play Protect.”

Our goal with Google Play Protect is to make sure that every user and every device has constant access to the best protections that Google can provide. Those protections are easy to use (ironically, for many people, Google Play Protect is so easy to use that they didn’t even know it was turned on!) and they benefit from everything Google knows about the security of Android devices.

Google Play Protect isn’t available just for users with Oreo -- it guards any device with Google Play Services, running Android Gingerbread, or later.

Updates are a challenge with Android, especially in regard to security. Why is that so hard? What are you doing to improve it?

What makes Android so cool and unique—its flexibility and openness—also presents a really big security challenge. There is a broad and diverse range of devices running Android, operated by a complex collection of partners and device manufacturers around the world. It’s our responsibility to make it easy for the entire ecosystem to receive and deploy updates, but the ecosystem has to work together in order to make it happen. One approach to the problem is to make updates easier through technical changes, such as Project Treble. Another is to work with partners to better understand how updates are produced, tested, and delivered to users.  

What’s the toughest part of your job?

Prioritization. Often we need to balance researching super cool, extremely rare issues with more incremental maintenance of our existing systems. It’s really important that we are laser-focused on both; it’s the only way we can protect the entire ecosystem now and longer-term.

What’s your favorite part?

I’m amazed and humbled by how many people use Android as their primary (or only) way to connect to the internet and to the broader world. We’ve still got a ton of work to do, but I’m incredibly proud of the role my team has played in making those connections safe and secure.  

Ok, last question: How do you eat your Oreos?

In one bite. (But I can’t handle the Double Stufs).

Source: Android


Automatic protections in Android: Q&A with a security expert

Editor's note: The Android security team works to keep more than two billion users safe, and with the release of Android Oreo, they’ve rolled out some new security protections. We sat down with Adrian Ludwig, Director of Android Security to learn about his team, their approach to security, and what Oreo’s new protections mean for people who use and love Android.

Keyword: Talk to us a bit about what your team does.

Adrian: We build security features for Android that help keep the whole ecosystem safe. Our software engineers write code that encrypts user data, helps find security bugs faster, prevents bugs from becoming security exploits, and finds applications that are trying to harm users or their information.  

How do you build these protections?

It starts with research. Because security is constantly evolving, our teams have to understand today’s issues, in Android and elsewhere, so we can provide better security now and in the future. Researchers in and out of Google are like detectives: they find new stuff, work to understand it deeply, and share it with the broader security community.

We then use those findings to make our protections stronger. We’re focused on tools like Google Play Protect and efforts like “platform hardening,” incremental protections to the Android platform itself. We’re also starting to apply machine learning to security threats, an early stage effort that we’re really excited about.

The final step is enabling all Android users to benefit from the protections. I’m really proud of the work our team has done with Google Play Protect, for example. Every day, it monitors more than 50 billion apps in Play, other app marketplaces, and across the web for potentially unsafe apps. If it finds any, we’ll prevent people from installing them and sometimes remove them from users’ phones directly. Users don’t need to do anything—this just works, automatically.

What are the challenges to protecting Android?

In security, we often talk about the trade-off between usability and protection. Sometimes, you can protect a device more effectively if there are certain things users can’t do on your device. And security is always much easier when things are predictable: for instance when all of the devices you are protecting are built the same way and can basically do the same thing.

But, Android security is different because the ecosystem is so diverse. The variety of use cases, form factors, and users forces us to be open-minded about how we should secure without limiting Android’s flexibility. We can’t possibly protect Android users with a single safeguard—our diversity of protections reflects the diversity in the Android ecosystem.

What are some of the new ways you’re protecting users in Android Oreo (not in robo- speak, please)?

Hang on, I gotta turn on Google Translate.

There are a … 0101100110 … sorry … a bunch! We’ve invested significantly in making it easier to update devices with security “patches,” fixes for potential safety problems, more commonly known as vulnerabilities. As a sidenote, you may have heard about “exploits.” If a vulnerability is a window, an exploit is a way to climb through it. The vast majority of the time, we’ll patch a vulnerability before anyone can exploit it. We have a project called Treble that makes it easier for us to work with partners and deliver updates to users. We want to close the window (and add some shutters) as quickly as possible.

We’ve also worked to improve verified boot, which confirms the device is in a known good state when it starts up, further hardened the Android kernel, which makes sure that hackers can’t change the way that code executes on a device, and evolved Seccomp which limits the amount of code that is visible to hackers.  Basically, we’re moving all the windows higher so any open ones are harder to climb through.

You announced Google Play Protect earlier this year. Tell us a bit about that and why it’s important for Android users?

For several years, we’ve been building “security services” which periodically check devices for potential security issues, allow Google and/or the user to review the status, and then use that information to protect the device. These services interact with Google Play in real-time to help secure it, hence the name “Google Play Protect.”

Our goal with Google Play Protect is to make sure that every user and every device has constant access to the best protections that Google can provide. Those protections are easy to use (ironically, for many people, Google Play Protect is so easy to use that they didn’t even know it was turned on!) and they benefit from everything Google knows about the security of Android devices.

Google Play Protect isn’t available just for users with Oreo -- it guards any device with Google Play Services, running Android Gingerbread, or later.

Updates are a challenge with Android, especially in regard to security. Why is that so hard? What are you doing to improve it?

What makes Android so cool and unique—its flexibility and openness—also presents a really big security challenge. There is a broad and diverse range of devices running Android, operated by a complex collection of partners and device manufacturers around the world. It’s our responsibility to make it easy for the entire ecosystem to receive and deploy updates, but the ecosystem has to work together in order to make it happen. One approach to the problem is to make updates easier through technical changes, such as Project Treble. Another is to work with partners to better understand how updates are produced, tested, and delivered to users.  

What’s the toughest part of your job?

Prioritization. Often we need to balance researching super cool, extremely rare issues with more incremental maintenance of our existing systems. It’s really important that we are laser-focused on both; it’s the only way we can protect the entire ecosystem now and longer-term.

What’s your favorite part?

I’m amazed and humbled by how many people use Android as their primary (or only) way to connect to the internet and to the broader world. We’ve still got a ton of work to do, but I’m incredibly proud of the role my team has played in making those connections safe and secure.  

Ok, last question: How do you eat your Oreos?

In one bite. (But I can’t handle the Double Stufs).

Source: Android


Automatic protections in Android: Q&A with a security expert

Editor's note: The Android security team works to keep more than two billion users safe, and with the release of Android Oreo, they’ve rolled out some new security protections. We sat down with Adrian Ludwig, Director of Android Security to learn about his team, their approach to security, and what Oreo’s new protections mean for people who use and love Android.

Keyword: Talk to us a bit about what your team does.

Adrian: We build security features for Android that help keep the whole ecosystem safe. Our software engineers write code that encrypts user data, helps find security bugs faster, prevents bugs from becoming security exploits, and finds applications that are trying to harm users or their information.  

How do you build these protections?

It starts with research. Because security is constantly evolving, our teams have to understand today’s issues, in Android and elsewhere, so we can provide better security now and in the future. Researchers in and out of Google are like detectives: they find new stuff, work to understand it deeply, and share it with the broader security community.

We then use those findings to make our protections stronger. We’re focused on tools like Google Play Protect and efforts like “platform hardening,” incremental protections to the Android platform itself. We’re also starting to apply machine learning to security threats, an early stage effort that we’re really excited about.

The final step is enabling all Android users to benefit from the protections. I’m really proud of the work our team has done with Google Play Protect, for example. Every day, it monitors more than 50 billion apps in Play, other app marketplaces, and across the web for potentially unsafe apps. If it finds any, we’ll prevent people from installing them and sometimes remove them from users’ phones directly. Users don’t need to do anything—this just works, automatically.

What are the challenges to protecting Android?

In security, we often talk about the trade-off between usability and protection. Sometimes, you can protect a device more effectively if there are certain things users can’t do on your device. And security is always much easier when things are predictable: for instance when all of the devices you are protecting are built the same way and can basically do the same thing.

But, Android security is different because the ecosystem is so diverse. The variety of use cases, form factors, and users forces us to be open-minded about how we should secure without limiting Android’s flexibility. We can’t possibly protect Android users with a single safeguard—our diversity of protections reflects the diversity in the Android ecosystem.

What are some of the new ways you’re protecting users in Android Oreo (not in robo- speak, please)?

Hang on, I gotta turn on Google Translate.

There are a … 0101100110 … sorry … a bunch! We’ve invested significantly in making it easier to update devices with security “patches,” fixes for potential safety problems, more commonly known as vulnerabilities. As a sidenote, you may have heard about “exploits.” If a vulnerability is a window, an exploit is a way to climb through it. The vast majority of the time, we’ll patch a vulnerability before anyone can exploit it. We have a project called Treble that makes it easier for us to work with partners and deliver updates to users. We want to close the window (and add some shutters) as quickly as possible.

We’ve also worked to improve verified boot, which confirms the device is in a known good state when it starts up, further hardened the Android kernel, which makes sure that hackers can’t change the way that code executes on a device, and evolved Seccomp which limits the amount of code that is visible to hackers.  Basically, we’re moving all the windows higher so any open ones are harder to climb through.

You announced Google Play Protect earlier this year. Tell us a bit about that and why it’s important for Android users?

For several years, we’ve been building “security services” which periodically check devices for potential security issues, allow Google and/or the user to review the status, and then use that information to protect the device. These services interact with Google Play in real-time to help secure it, hence the name “Google Play Protect.”

Our goal with Google Play Protect is to make sure that every user and every device has constant access to the best protections that Google can provide. Those protections are easy to use (ironically, for many people, Google Play Protect is so easy to use that they didn’t even know it was turned on!) and they benefit from everything Google knows about the security of Android devices.

Google Play Protect isn’t available just for users with Oreo -- it guards any device with Google Play Services, running Android Gingerbread, or later.

Updates are a challenge with Android, especially in regard to security. Why is that so hard? What are you doing to improve it?

What makes Android so cool and unique—its flexibility and openness—also presents a really big security challenge. There is a broad and diverse range of devices running Android, operated by a complex collection of partners and device manufacturers around the world. It’s our responsibility to make it easy for the entire ecosystem to receive and deploy updates, but the ecosystem has to work together in order to make it happen. One approach to the problem is to make updates easier through technical changes, such as Project Treble. Another is to work with partners to better understand how updates are produced, tested, and delivered to users.  

What’s the toughest part of your job?

Prioritization. Often we need to balance researching super cool, extremely rare issues with more incremental maintenance of our existing systems. It’s really important that we are laser-focused on both; it’s the only way we can protect the entire ecosystem now and longer-term.

What’s your favorite part?

I’m amazed and humbled by how many people use Android as their primary (or only) way to connect to the internet and to the broader world. We’ve still got a ton of work to do, but I’m incredibly proud of the role my team has played in making those connections safe and secure.  

Ok, last question: How do you eat your Oreos?

In one bite. (But I can’t handle the Double Stufs).

Source: Android