Tag Archives: Google Play

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


Announcing the 20 finalists and open registration for the Indie Games Festival in San Francisco

Posted by Kacey Fahey, Developer Marketing, Google Play

With so many great mobile games launching this year, we saw a huge amount of interest from indie developers to showcase their art at the Google Play Indie Games Festival in San Francisco next month. While it was a tough selection process, we're excited to announce the 20 finalists, as well as our esteemed judging panel. Fans will be able to play the new and un-released indie games in a fun festival atmosphere where they can also meet the creators themselves. To attend and learn more about the event, register now for free at g.co/play/sfindiegamesfest2017.

So how did we choose the 20 finalists? We powered up our phones, put our game-faces on, and looked for games that not only met the festival requirements, but also stood out with their overall design, fun, and quality. These are the 20 finalists who will be joining us at the festival to demo their games.

Meet the finalists

7 Pin Pool
SPG Inc
Age of Rivals
Roboto Games
Brave Hand
Heart Shaped Games
(game not yet released)
Covens
Raincrow Studios, LLC
Crashy Cars
pixelbizarre
Dokudo
Sense of Wonder
Flipping Legend
Hiding Spot
Gladiator Rising
Happii Gamer Studio
Jigsaw Story
Happy Square Studio Inc
Loteria Latin Bingo
Gorilla Bean Games
Maruta Escape
Busan Sanai Games
(game not yet released)
NoStranger
Black Vein Productions
Slayaway Camp
Blue Wizard Digital
Space Tunnel
Spacewave Studios
Star Vikings Forever
Akupara Games
Storm Wars
Zom.bio
Tiny Bubbles
Pine Street Codeworks
(game not yet released)
Topsoil
Nico Prins

In addition to playing these games and meeting the developers who made them, fans will have a chance to vote for their favorites throughout the festival. The Top 10 will then move on to present a short pitch in pursuit of going home as one of the three overall festival winners. The winners will be chosen by this year's panel of judges representing a diverse lineup of gaming expertise.

  • Alex the Gamerette, YouTube Creator
  • Lina Chen, Co-founder & CEO of Nix Hydra
  • Emily Greer, CEO of Kongregate
  • Jamil Moledina, Games Strategic Lead, Google
  • Dean Takahashi, Lead Writer for GamesBeat
  • Sarah Thomson, BD Lead, Indie Games, Google Play

Emceeing this year's event is J.D. Witherspoon, aka runJDrun. No stranger to gaming, YouTuber/actor/comedian, J.D. plays a wide array of games and frequently uploads gaming, vlog, and comedy content to his channels.

If you want to try out these games and celebrate the indie community, learn more about the event and register at g.co/play/sfindiegamesfest2017.

How useful did you find this blogpost?

How to improve app design for Wear 2.0

Posted by Steven Tepper, App Quality Consultant, Google Play

Wear 2.0 launched back in February with added support for new hardware features in addition to adopting new Material Design themes, guidelines, and a simpler vertical UI pattern. It also introduces a complications API, making it easier for apps to provide data to watch faces, and watch faces to incorporate external data. The final big update was that, apps targeting Wear 2.0 now have the ability to operate in a standalone mode, without needing a connection to a companion app on the phone.

There are a few design considerations in relation to navigation, notifications, the complications API, and the standalone functionality to help you better optimize for Wear 2.0 devices:

Navigation

  1. Use the WearableDrawerLayout navigation drawer for simple and infrequent navigation: Simple navigation includes tasks such as accessing app settings, switching users or logging out. You can implement this on Wear 2.0 to switch between different views or sections of the app via a swipe down from the top of the screen, or an action drawer can be set up for context-specific actions when swiping up from the bottom of the screen.
  2. Present a navigation drawer as a single-page drawer to enable users to navigate views quickly: A navigation drawer can be presented as either a multi-page or single-page drawer. The single-page layout is useful for when the user is expected to navigate quickly between 7 or less views of the app. Remember that if the app is using a single-page drawer, the iconography should be clear and understandable as there will not be any sort of text labeling in this layout. If there are more than 7 views to navigate to or the views are not easily represented by icons, you should instead use the multi-page drawer layout.
  3. Use multiple app launchers if your app has two or three discrete functions: For example, if your app supports both activity tracking—with various options, actions, and views—and historical analysis and management of tracked activities, you can use multiple app launchers to handle these tasks. Alternatively, if your app has a simple home screen, these features could be placed in line, at the bottom of the screen.
  4. Use peeking at the top of the action drawer to provide quick access to the primary action: If there is no primary action associated with the view, override the default behavior and force an overflow button to peek instead, exposing all actions at the bottom of a view, when tapped.

Ensure that for devices using Wear 2.0, your app takes advantage of these new UI patterns to provide a consistent user experience. Check out more training resources for Wear Navigation and Actions and the Material Design specifications for Navigation and Action Drawers.

Notifications

Wear 2.0 uses a simpler vertical navigation pattern, removing the horizontal swiping gesture to present actions for a notification. Notification actions are now presented as a single primary action (if applicable) at the bottom of a notification. If there is no primary action, expanding the notification will present options in a single, vertically scrollable view.

Notifications will work without needing many changes on both 1.x and 2.0 devices, but appear quite different:

When creating apps for Wear 2.0 devices, improve the user experience with notifications by applying the following best practices:

  1. Support expandable notifications: Use BigTextStyle so that users can see more content on their watch.
  2. Use the collapsed view of the notification (if applicable): Add the primary action for your notification to the collapsed view of the notification using setContentIntent(), where appropriate.
  3. For messaging apps, use the MessagingStyle: Provide a rich chat app-like experience in the expanded notification using this style.
  4. Update user directions which are specific to Wear 1.0: Remove any text guiding users to act on a card by swiping horizontally (the Wear 1.x pattern).
  5. Enhancing notifications to use inline actions: This allows users to do things without needing tap to see the expanded notification details. Actions for messaging notifications can use several different input methods including Smart Reply presets, voice, and keyboard input. Take advantage of these features to provide added functionality and delight users.

To learn more about adding wearable features to notifications.

Complications

The complications API in Wear 2.0 makes it much easier for watch face developers and third-party data providers to surface important information users want, at a glance. Watch faces that support the API can be configured to use any of the data providers that have been installed on the watch while maintaining complete control over their appearance. Apps supporting the complication API allow the app's data to be accessible on any watch faces that support complications. These complications can be displayed in a variety of forms (short text, icon, ranged value, long text, small image, and large image) depending on what the data provider has configured and how much space has been allocated on the watch face.

To ensure that complications fit the overall design of the watch face and properly handle their data type, when adding complication support we recommend watch face makers should:

  1. Use the TextRenderer class found in the Wear 2.0 SDK: This allows the text within complications to be adjusted to their bounds by shrinking the text, dynamically supporting line breaks or ellipsizing strings when they exceed the bounds of a text-based complication.
  2. Use the ComplicationDrawable class to set the background color, shape, border, and font options for the complications: This gives complete control of how the complication is rendered to the watch face.
  3. Design the watch face to provide a way for users to configure or adjust complications on the watch face through a settings menu: To learn how to construct these settings see the watch face sample on GitHub.
  4. Use the data provider test suite app to feed dummy data to the watch face complications: This will enable you to verify that all of the complications render properly and have fonts formatted for their bounds.
  5. As a complication data provider, expose relevant data by using the ComplicationProviderService: Simply define and configure what types of ComplicationData the app can provide for complications.

Standalone functionality on Wear devices

  1. Make sure your app is able to handle itself if there is no companion app installed when using the android.hardware.type.watch hardware feature flag: Using this feature enables your app to become searchable and installable directly on Wear devices without needing to install a companion phone app, so ensure your app can handle itself to avoid a confusing or broken user experience.
  2. Ensure your wearable app doesn't rely on the phone app for sign-in/authentication or primary functionality: When requiring complicated input for authentication (for example, password entry) your wearable app can point to the companion phone, but should rely on web UI for account/password entry rather than an app.
  3. Where a companion app must be present on a phone to support your app in some other way, the app should use the CapabilityApi: This should be used to properly direct users to the Play Store listing on their companion device to install the missing app. Otherwise, the app should function on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.
  4. Include wording about any companion app requirements or briefly mention how your Wear app should function within the Play Store listing description: This will help set expectations and guide users to install the correct apps for the best possible experience.
  5. Incorporate the com.google.android.wearable.standalone flag in the manifest if your Wearable app can function without any phone companion interaction: This flag indicates that the wearable app can be installed and will fully function when not paired to an Android or iOS companion phone.

Though a lot was covered here, there are additional resources you can use to ensure that your apps or games are optimized and use the latest patterns and functionality on Wear. Be sure to review the quality guidelines and check out the developer training documentation to learn more best practices for wearable app development and wearable app design in order to build quality apps for Wear.

How useful did you find this blogpost?