Tag Archives: Android

Developer Preview 4 now available, official Android O coming soon!

Posted by Dave Burke, VP of Engineering

As we put the finishing touches on the Android O platform, today we're rolling out Developer Preview 4 to help you make sure your apps are ready.

This is the final preview before we launch the official Android O platform to consumers later this summer. Take this opportunity to wrap up your testing and publish your updates soon, to give users a smooth transition to Android O.

If you have a device that's enrolled in the Android Beta Program, you'll receive an update to Developer Preview 4 in the next few days. If you haven't enrolled your device yet, just visit the Android Beta site to enroll and get the update.

Watch for more information on the official Android O release soon!

What's in this update?

Developer Preview 4 is a release candidate build of Android O that you can use to complete your development and testing in time for the upcoming official release. It includes the final system behaviors, the latest bug fixes and optimizations, and the final APIs (API level 26) already available since Developer Preview 3.

We're releasing the Developer Preview 4 device system images today, together with the stable version of the Android 26.0.0 Support Library. Incremental updates to the SDK, tools, and Android Emulator system images are on the way over the next few days.

We're also introducing a new version of Android Testing Support Library that includes new features like Android Test Orchestrator, Multiprocess Espresso, and more. Watch for details coming soon.

Test your apps on Android O

Today's Developer Preview 4 system images give you an excellent way to test your current apps on the near-final version of Android O. By testing now, you can make sure your app offers the experience you want as users start to upgrade to the official Android O platform.

Just enroll a supported device in the Android Beta Program to get today's update over-the-air, install your current app from Google Play, and test the user flows. The app should run and look great, and should handle the Android O behavior changes properly -- in particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.

Once you've resolved any issues, publish your app updates with the current targeting level, so that they're available as users start to receive Android O.

Enhance your apps with Android O features and APIs

Users running the latest versions of Android are typically among the most active in terms of downloading apps, consuming content, and making purchases. They're also more vocal about support for the latest Android features in their favorite apps. With Android O, users are anticipating features like notification channels and dots, shortcut pinning, picture-in-picture, autofill, and others. These features could also help increase engagement with your app as more users upgrade to Android O over time.

With Android O your app can directly pin a specific app shortcut in the launcher to drive engagement.
Notification dots keep users active in your app and let them jump directly the app's core functions.

Enhancing your apps with Android O features can help you drive engagement with users, offer new interactions, give them more control and security, and improve performance. Features like adaptive icons, downloadable fonts, and autosizing TextView can simplify your development and minimize your APK size. Battery is also a top concern for users, so they'll appreciate your app being optimized for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Speed your development with Android Studio

When you're ready to build for Android O, we recommend updating to the latest version of Android Studio 3.0, available for download from the canary channel. Aside from improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Instant Apps, XML Fonts, Downloadable Fonts, and Adaptive Icons.

We also recommend updating to the stable version of the Android Support Library 26.0.0, available now from Google's Maven repository, and to the latest SDK, tools, and emulator system images, available over the next few days.

You can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to setup your environment to build with Android O.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 26. When you're ready, you can publish your APK updates in your alpha, beta, or production channels.

Make sure that your updated app runs well on Android O as well as older versions. We recommend using Google Play's beta testing feature to get early feedback from a small group of users. Then do a staged rollout. We're looking forward to seeing your app updates!

How to get Developer Preview 4

It's simple to get Developer Preview 4 if you haven't already! Just visit android.com/beta and opt-in your eligible phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, Nexus Player, and the Android Emulator. Enrolled devices will automatically update when we release the official version of Android O.

Thanks for all of your input throughout the preview. Continue to share your feedback and requests, we love it!

Seccomp filter in Android O

Posted by Paul Lawrence, Android Security Engineer
In Android-powered devices, the kernel does the heavy lifting to enforce the Android security model. As the security team has worked to harden Android's userspace and isolate and deprivilege processes, the kernel has become the focus of more security attacks. System calls are a common way for attackers to target the kernel.
All Android software communicates with the Linux kernel using system calls, or syscalls for short. The kernel provides many device- and SOC-specific syscalls that allow userspace processes, including apps, to directly interact with the kernel. All apps rely on this mechanism to access collections of behavior indexed by unique system calls, such as opening a file or sending a Binder message. However, many of these syscalls are not used or officially supported by Android.
Android O takes advantage of a Linux feature called seccomp that makes unused system calls inaccessible to application software. Because these syscalls cannot be accessed by apps, they can't be exploited by potentially harmful apps.

seccomp filter

Android O includes a single seccomp filter installed into zygote, the process from which all the Android applications are derived. Because the filter is installed into zygote—and therefore all apps—the Android security team took extra caution to not break existing apps. The seccomp filter allows:
  • all the syscalls exposed via bionic (the C runtime for Android). These are defined in bionic/libc/SYSCALLS.TXT.
  • syscalls to allow Android to boot
  • syscalls used by popular Android applications, as determined by running Google's full app compatibility suite
Android O's seccomp filter blocks certain syscalls, such as swapon/swapoff, which have been implicated in some security attacks, and the key control syscalls, which are not useful to apps. In total, the filter blocks 17 of 271 syscalls in arm64 and 70 of 364 in arm.

Developers

Test your app for illegal syscalls on a device running Android O.

Detecting an illegal syscall

In Android O, the system crashes an app that uses an illegal syscall. The log printout shows the illegal syscall, for example:
03-09 16:39:32.122 15107 15107 I crash_dump32: performing dump of process 14942 (target tid = 14971)
03-09 16:39:32.127 15107 15107 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-09 16:39:32.127 15107 15107 F DEBUG   : Build fingerprint: 'google/sailfish/sailfish:O/OPP1.170223.013/3795621:userdebug/dev-keys'
03-09 16:39:32.127 15107 15107 F DEBUG   : Revision: '0'
03-09 16:39:32.127 15107 15107 F DEBUG   : ABI: 'arm'
03-09 16:39:32.127 15107 15107 F DEBUG   : pid: 14942, tid: 14971, name: WorkHandler  >>> com.redacted <<<
03-09 16:39:32.127 15107 15107 F DEBUG   : signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
03-09 16:39:32.127 15107 15107 F DEBUG   : Cause: seccomp prevented call to disallowed system call 55
03-09 16:39:32.127 15107 15107 F DEBUG   :     r0 00000091  r1 00000007  r2 ccd8c008  r3 00000001
03-09 16:39:32.127 15107 15107 F DEBUG   :     r4 00000000  r5 00000000  r6 00000000  r7 00000037
Affected developers should rework their apps to not call the illegal syscall.

Toggling seccomp filters during testing

In addition to logging errors, the seccomp installer respects setenforce on devices running userdebug and eng builds, which allows you to test whether seccomp is responsible for an issue. If you type:
adb shell setenforce 0 && adb stop && adb start
then no seccomp policy will be installed into zygote. Because you cannot remove a seccomp policy from a running process, you have to restart the shell for this option to take effect.

Device manufacturers

Because Android O includes the relevant seccomp filters at //bionic/libc/seccomp, device manufacturers don't need to do any additional implementation. However, there is a CTS test that checks for seccomp at //cts/tests/tests/security/jni/android_security_cts_SeccompTest.cpp. The test checks that add_key and keyctl syscalls are blocked and openat is allowed, along with some app-specific syscalls that must be present for compatibility.

Motion Stills — Now on Android



Last year, we launched Motion Stills, an iOS app that stabilizes your Live Photos and lets you view and share them as looping GIFs and videos. Since then, Motion Stills has been well received, being listed as one of the top apps of 2016 by The Verge and Mashable. However, from its initial release, the community has been asking us to also make Motion Stills available for Android. We listened to your feedback and today, we're excited to announce that we’re bringing this technology, and more, to devices running Android 5.1 and later!
Motion Stills on Android: Instant stabilization on your device.
With Motion Stills on Android we built a new recording experience where everything you capture is instantly transformed into delightful short clips that are easy to watch and share. You can capture a short Motion Still with a single tap like a photo, or condense a longer recording into a new feature we call Fast Forward. In addition to stabilizing your recordings, Motion Stills on Android comes with an improved trimming algorithm that guards against pocket shots and accidental camera shakes. All of this is done during capture on your Android device, no internet connection required!

New streaming pipeline
For this release, we redesigned our existing iOS video processing pipeline to use a streaming approach that processes each frame of a video as it is being recorded. By computing intermediate motion metadata, we are able to immediately stabilize the recording while still performing loop optimization over the full sequence. All this leads to instant results after recording — no waiting required to share your new GIF.
Capture using our streaming pipeline gives you instant results.
In order to display your Motion Stills stream immediately, our algorithm computes and stores the necessary stabilizing transformation as a low resolution texture map. We leverage this texture to apply the stabilization transform using the GPU in real-time during playback, instead of writing a new, stabilized video that would tax your mobile hardware and battery.

Fast Forward
Fast Forward allows you to speed up and condense a longer recording into a short, easy to share clip. The same pipeline described above allows Fast Forward to process up to a full minute of video, right on your phone. You can even change the speed of playback (from 1x to 8x) after recording. To make this possible, we encode videos with a denser I-frame spacing to enable efficient seeking and playback. We also employ additional optimizations in the Fast Forward mode. For instance, we apply adaptive temporal downsampling in the linear solver and long-range stabilization for smooth results over the whole sequence.
Fast Forward condenses your recordings into easy to share clips.
Try out Motion Stills
Motion Stills is an app for us to experiment and iterate quickly with short-form video technology, gathering valuable feedback along the way. The tools our users find most fun and useful may be integrated later on into existing products like Google Photos. Download Motion Stills for Android from the Google Play store—available for mobile phones running Android 5.1 and later—and share your favorite clips on social media with hashtag #motionstills.

Acknowledgements
Motion Stills would not have been possible without the help of many Googlers. We want to especially acknowledge the work of Matthias Grundmann in advancing our stabilization technology, as well as our UX and interaction designers Jacob Zukerman, Ashley Ma and Mark Bowers.

Shut the HAL Up

Posted by Jeff Vander Stoep, Senior Software Engineer, Android Security

Updates are essential for security, but they can be difficult and expensive for device manufacturers. Project Treble is making updates easier by separating the underlying vendor implementation from the core Android framework. This modularization allows platform and vendor-provided components to be updated independently of each other. While easier and faster updates are awesome, Treble's increased modularity is also designed to improve security.

Isolating HALs

A Hardware Abstraction Layer (HAL) provides an interface between device-agnostic code and device-specific hardware implementations. HALs are commonly packaged as shared libraries loaded directly into the process that requires hardware interaction. Security boundaries are enforced at the process level. Therefore, loading the HAL into a process means that the HAL is running in the same security context as the process it's loaded into.

The traditional method of running HALs in-process means that the process needs all the permissions required by each in-process HAL, including direct access to kernel drivers. Likewise, all HALs in a process have access to the same set of permissions as the rest of the process, including permissions required by other in-process HALs. This results in over-privileged processes and HALs that have access to permissions and hardware that they shouldn't.

Figure 1. Traditional method of multiple HALs in one process.

Moving HALs into their own processes better adheres to the principle of least privilege. This provides two distinct advantages:

  1. Each HAL runs in its own sandbox and is permitted access to only the hardware driver it controls and the permissions granted to the process are limited to the permissions required to do its job.
  2. Similarly, the process loses access to hardware drivers and other permissions and capabilities needed by the HALs.
Figure 2. Each HAL runs in its own process.

Moving HALs into their own processes is great for security, but it comes at the cost of increased IPC overhead between the client process and the HAL. Improvements to the binder driver made IPC between HALs and clients practical. Introducing scatter-gather into binder improves the performance of each transaction by removing the need for the serialization/deserialization steps and reducing the number of copy operations performed on data from three down to one. Android O also introduces binder domains to provide separate communication streams for vendor and platform components. Apps and the Android frameworks continue to use /dev/binder, but vendor-provided components now use /dev/vndbinder. Communication between the platform and vendor components must use /dev/hwbinder. Other means of IPC between platform and vendor are disallowed.

Case study: System Server

Many of the services offered to apps by the core Android OS are provided by the system server. As Android has grown, so has system server's responsibilities and permissions, making it an attractive target for an attacker. As part of project Treble, approximately 20 HALs were moved out of system server, including the HALs for sensors, GPS, fingerprint, Wi-Fi, and more. Previously, a compromise in any of those HALs would gain privileged system permissions, but in Android O, permissions are restricted to the subset needed by the specific HAL.

Case study: media frameworks

Efforts to harden the media stack in Android Nougat continued in Android O. In Nougat, mediaserver was split into multiple components to better adhere to the principle of least privilege, with audio hardware access restricted to audioserver, camera hardware access restricted to cameraserver, and so on. In Android O, most direct hardware access has been entirely removed from the media frameworks. For example HALs for audio, camera, and DRM have been moved out of audioserver, cameraserver, and drmserver respectively.

Reducing and isolating the attack surface of the kernel

The Linux kernel is the primary enforcer of the security model on Android. Attempts to escape sandboxing mechanisms often involve attacking the kernel. An analysis of kernel vulnerabilities on Android showed that they overwhelmingly occurred in and were reached through hardware drivers.

De-privileging system server and the media frameworks is important because they interact directly with installed apps. Removing direct access to hardware drivers makes bugs difficult to reach and adds another layer of defense to Android's security model.

Since U Been Blob

Editor’s note: On World Emoji Day, we’re taking the time to bid farewell to our old Android emoji, known fondly by fans as “blobs.” We’re rolling out a new set of emoji as part of Android O. They’re squishy and lovable—and designed for more consistent communication. Breaking up is hard to do, but we’ll find love in a blobless place.

Dear Blob,

I see it all now that you're gone.

We were both young when I first saw you… I said “it’s a love story, Blobby just say yes.”

HeartEyes_200px_.gif

Now, you lost that blobbin’ feeling. Blobversation has run dry—that’s what’s going on. Oh Blobbie, I couldn't have tried anymore. Blame it on the blob.

Once upon a time I was falling in blob, and now you’re just someblobby that I used to know.

It’s time we had the talk. Blob, bye.

Crying_200px.gif

Although we’ve come to the end of the blob, I want you to know you couldn't have loved me blobber. I’ve had the blob of my life… you’ll always be my Blobby.

KissFace_200px.gif

Don’t you forget ablob me,

Google

P.S. Nevermind, I’ll find someblob like you… You can blob your own way with new stickers in Google Allo.
Blush_200px.gif

#BlobVoyage!

Identifying Intrusive Mobile Apps using Peer Group Analysis

Posted by Martin Pelikan, Giles Hogben, and Ulfar Erlingsson of Google's Security and Privacy team

Mobile apps entertain and assist us, make it easy to communicate with friends and family, and provide tools ranging from maps to electronic wallets. But these apps could also seek more device information than they need to do their job, such as personal data and sensor data from components, like cameras and GPS trackers.

To protect our users and help developers navigate this complex environment, Google analyzes privacy and security signals for each app in Google Play. We then compare that app to other apps with similar features, known as functional peers. Creating peer groups allows us to calibrate our estimates of users' expectations and set adequate boundaries of behaviors that may be considered unsafe or intrusive. This process helps detect apps that collect or send sensitive data without a clear need, and makes it easier for users to find apps that provide the right functionality and respect their privacy. For example, most coloring book apps don't need to know a user's precise location to function and this can be established by analyzing other coloring book apps. By contrast, mapping and navigation apps need to know a user's location, and often require GPS sensor access.

One way to create app peer groups is to create a fixed set of categories and then assign each app into one or more categories, such as tools, productivity, and games. However, fixed categories are too coarse and inflexible to capture and track the many distinctions in the rapidly changing set of mobile apps. Manual curation and maintenance of such categories is also a tedious and error-prone task.

To address this, Google developed a machine-learning algorithm for clustering mobile apps with similar capabilities. Our approach uses deep learning of vector embeddings to identify peer groups of apps with similar functionality, using app metadata, such as text descriptions, and user metrics, such as installs. Then peer groups are used to identify anomalous, potentially harmful signals related to privacy and security, from each app's requested permissions and its observed behaviors. The correlation between different peer groups and their security signals helps different teams at Google decide which apps to promote and determine which apps deserve a more careful look by our security and privacy experts. We also use the result to help app developers improve the privacy and security of their apps.

Apps are split into groups of similar functionality, and in each cluster of similar apps the established baseline is used to find anomalous privacy and security signals.

These techniques build upon earlier ideas, such as using peer groups to analyze privacy-related signals, deep learning for language models to make those peer groups better, and automated data analysis to draw conclusions.

Many teams across Google collaborated to create this algorithm and the surrounding process. Thanks to several, essential team members including Andrew Ahn, Vikas Arora, Hongji Bao, Jun Hong, Nwokedi Idika, Iulia Ion, Suman Jana, Daehwan Kim, Kenny Lim, Jiahui Liu, Sai Teja Peddinti, Sebastian Porst, Gowdy Rajappan, Aaron Rothman, Monir Sharif, Sooel Son, Michael Vrable, and Qiang Yan.

For more information on Google's efforts to detect and fight potentially harmful apps (PHAs) on Android, see Google Android Security Team's Classifications for Potentially Harmful Applications.

References

S. Jana, Ú. Erlingsson, I. Ion (2015). Apples and Oranges: Detecting Least-Privilege Violators with Peer Group Analysis. arXiv:1510.07308 [cs.CR].

T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, J. Dean (2013). Distributed Representations of Words and Phrases and their Compositionality. Advances in Neural Information Processing Systems 26 (NIPS 2013).

Ú. Erlingsson (2016). Data-driven software security: Models and methods. Proceedings of the 29th IEEE Computer Security Foundations Symposium (CSF'16), Lisboa, Portugal.

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

Calling all indie developers in the US & Canada: sign up for the Google Play Indie Games Festival in San Francisco

Posted by Jamil Moledina, Games Strategic Lead, Google Play

Calling all indie developers with fun and creative mobile games: we want to see your latest work! We'll be back with the second Google Play Indie Games Festival taking place in San Francisco on September 23rd.

If you're an indie developer based in the US or Canada and want to submit your game, visit the submission form and enter now through August 6th at 11:59PM PST.

If chosen as one of the 20 Finalists, you could have a chance to demo your game at the event and compete for prizes and bragging rights, to go home as one of the three festival winners!

How useful did you find this blogpost?

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.

Android vitals: Increase engagement and installs through improved app performance

Posted by Fergus Hurley, Product Manager, Google Play

Poor app performance is something that many users have experienced. Think about that last time you experienced an app crashing, failing to respond, or rendering slowly. Consider your reaction when checking the battery usage on your own device, and seeing an app using excessive battery. When an app performs badly, users notice. In fact, in an internal analysis of app reviews on Google Play, we noticed that half of the 1-star reviews mentioned app stability.

Conversely, people consistently reward the best performing apps with better ratings and reviews. This leads to better rankings on Google Play, which helps increase installs. Not only that, but users stay more engaged, and are willing to spend more time and money.

At Google I/O 2017, we announced the new Android vitals dashboard in the Google Play Console. Android vitals is designed to help you understand and analyze bad app behaviors, so you can improve your app's performance and reap the benefits of better performance.

Android vitals in the Google Play Console

Android vitals helps identify opportunities to improve your app's performance. The dashboards are useful for engineers and business owners alike, offering quick reference performance metrics to monitor your app so you can analyze the data and dedicate the right resources to make improvements.

You'll see the following data collected from Android devices whose users have opted in to automatically share usage and diagnostics data:

  • Stability: ANR rate & crash rate
  • Render time: slow rendering (16ms) and frozen UI frames (700ms)
  • Battery usage: stuck wake locks and excessive wakeups

See how Busuu increased their rating from 4.1☆ to 4.5☆ by focusing on app performance

Busuu is one of the world's largest language learning apps. Hear from Antoine Sakho, Head of Product about how Busuu increased user ratings.

Learn more about engineering for high performance with tools from Android and Google Play

Read our best practice article on Android vitals to understand the data shown in the dashboards, and how you can improve your app's performance and stability. Watch the I/O session to learn about more tools from Android and Google Play that you can use to identify and fix bad behaviors:

Learn more about other Play Console features, and stay up to date with news and tips to succeed on Google Play, with the Playbook app. Join the beta and install it today.

How useful did you find this blogpost?