The latest Android and Google Play news for app and game developers.
Android Security is always developing new ways of using data to find and block potentially harmful apps (PHAs) from getting onto your devices. Earlier this year, we announced we had blocked Chrysaor targeted spyware, believed to be written by NSO Group, a cyber arms company. In the course of our Chrysaor investigation, we used similar techniques to discover a new and unrelated family of spyware called Lipizzan. Lipizzan's code contains references to a cyber arms company, Equus Technologies.
Lipizzan is a multi-stage spyware product capable of monitoring and exfiltrating a user's email, SMS messages, location, voice calls, and media. We have found 20 Lipizzan apps distributed in a targeted fashion to fewer than 100 devices in total and have blocked the developers and apps from the Android ecosystem. Google Play Protect has notified all affected devices and removed the Lipizzan apps.
We've enhanced Google Play Protect's capabilities to detect the targeted spyware used here and will continue to use this framework to block more targeted spyware. To learn more about the methods Google uses to find targeted mobile spyware like Chrysaor and Lipizzan, attend our BlackHat talk, Fighting Targeted Malware in the Mobile Ecosystem.
Getting on a target device
Lipizzan was a sophisticated two stage spyware tool. The first stage found by Google Play Protect was distributed through several channels, including Google Play, and typically impersonated an innocuous-sounding app such as a "Backup" or "Cleaner" app. Upon installation, Lipizzan would download and load a second "license verification" stage, which would survey the infected device and validate certain abort criteria. If given the all-clear, the second stage would then root the device with known exploits and begin to exfiltrate device data to a Command & Control server.
Once implanted on a target device
The Lipizzan second stage was capable of performing and exfiltrating the results of the following tasks:
The PHA had specific routines to retrieve data from each of the following apps:
We saw all of this behavior on a standalone stage 2 app, com.android.mediaserver (not related to Android MediaServer). This app shared a signing certificate with one of the stage 1 applications, com.app.instantbackup, indicating the same author wrote the two. We could use the following code snippet from the 2nd stage (com.android.mediaserver) to draw ties to the stage 1 applications.
public void uninstallParent() { android.util.Log.d("ApplicationsManager", "Removing parent application!"); com.android.mediaserver.shell.Shell$SU.run(new StringBuilder().append("").append("echo u:r:system_server:s0 > /proc/$$/attr/current; pm uninstall").append("com.app.instantbackup").toString()); com.android.mediaserver.shell.Shell$SU.run(new StringBuilder().append("").append("rm -rf /data/data/").append("com.app.instantbackup").toString()); com.android.mediaserver.shell.Shell$SU.run(new StringBuilder().append("").append("rm -Rf /data/data/").append("com.app.instantbackup").toString()); return; }
Morphing first stage
After we blocked the first set of apps on Google Play, new apps were uploaded with a similar format but had a couple of differences.
Despite changing the type of app and the method to download stage 2, we were able to catch the new implant apps soon after upload.
How many devices were affected?
There were fewer than 100 devices that checked into Google Play Protect with the apps listed below. That means the family affected only 0.000007% of Android devices. Since we identified Lipizzan, Google Play Protect removed Lipizzan from affected devices and actively blocks installs on new devices.
What can you do to protect yourself?
Older version
Newer version
We're pleased to announce the version 1.0 release of the Android Testing Support Library (ATSL).
ATSL version 1.0 is a major update to our existing testing APIs and comes with lots of new features, improved performance, stability, and bug fixes. It provides full API parity with the now deprecated Android platform testing APIs. This release also adds a number of features that we discussed in our Google I/O 2017 talk, such as native support for Multiprocess Espresso and the Android Test Orchestrator.
We are also happy to announce that, starting with version 1.0, we're distributing releases on Google's Maven repository, which makes it a lot easier to use ATSL in your builds. To learn more about using this repository, see the getting started with the Google Maven repository guide. Note that we're no longer tying future updates to the testing infrastructure with platform updates. If you have not yet upgraded your tests to ATSL, this is an excellent time.
Finally, we want to announce a big update to our Android testing documentation. We've migrated our old testing documentation from our GitHub website to developers.android.com/testing. All the testing documentation now appears in a single place, making it even easier to learn how to write and execute tests on Android.
Let's move on to the fun part of this post, an overview of new APIs and tools that we're providing in this release.
Espresso 3.0.0 comes with amazing new features and improved overall performance. Some of the highlights include: Multiprocess Espresso, Idling Registry and new Idling Resources. Let's dive in and have a more detailed look at these new features:
Multiprocess Espresso
Starting with Android O, the platform includes support for instrumenting tests outside of your app's default process. (Prior to Android O, you could only test against app components in your app's default process.) Multiprocess Espresso makes this support possible. It allows you to seamlessly test your app's UI interactions that cross process boundaries while still maintaining Espresso's synchronization guarantees.
The good news is that Espresso does all the work; you don't have to change anything for setups with UI in multiple processes. You can keep writing your Espresso tests like you would for single process apps, and Espresso automatically handles the process IPC and synchronization between processes.
The following diagram shows how multiple instances of Espresso communicate with each other:
If you want to learn more about Multiprocess Espresso and how to use it, please take a look at our documentation and our Multiprocess sample.
Some apps use build flavors in Gradle or a dependency injection framework, like Dagger, to generate test build configurations that register idling resources. Others simply expose the idling resource through their activities. The problem with all these approaches is that they add complexity to your development workflow, and some of them even break encapsulation. With the latest release of Espresso, we've made it easier to register idling resources from within your app code by introducing the new IdlingRegistry API. IdlingRegistry is a lightweight registry that doesn't bring in the entire Espresso library, so you can more easily register resources from your application code. When combining this API with Multiprocess Espresso, you can register idling resources from any process within your application code.
IdlingRegistry
Registration from the Espresso class is now deprecated.
Writing custom idling resources can be time consuming, so Espresso 3.0.0 now comes with more idling resources out of the box to synchronize your threads. The new resources include: IdlingThreadPoolExecutor and IdlingScheduledThreadPoolExecutor. There will be more to come!
IdlingThreadPoolExecutor
IdlingScheduledThreadPoolExecutor
To take advantage of the new idling resource, add these new dependencies to your build.gradle file:
androidTestCompile "com.android.support.test.espresso.idling:idling-concurrent:3.0.0"
Additionally, CountingIdlingResource, which was previously deprecated in Espresso contrib, has been removed with this release. Therefore, you need to update your tests to use the new CountingIdlingResource package that's located in Espresso idling resource. For the full migration details, refer to our release notes.
CountingIdlingResource
When you test ContentProvider objects, you can now use ProviderTestRule instead of ProviderTestCase2. ProviderTestRule offers an easier way to work with other test rules currently available for AndroidJUnit4.
ContentProvider
ProviderTestRule
ProviderTestCase2
ProviderTestRule includes APIs for initialization, as well as commands to run against a ContentProvider under test. If your ContentProvider is based off of a SQLite database, you can use the ProviderTestRule commands for setting the database file and initialization commands.
To learn more, see the ProviderTestRule documentation.
Android M (API level 23) allows apps to request permissions at runtime. However, the dialogs that request runtime permissions place tests in a state where they cannot continue, causing them to fail. By using GrantPermissionRule, you can skip the dialog popups altogether and simulate a user granting a runtime permission for your app.
GrantPermissionRule
Typically, AndroidJUnitRunner runs all tests in the same instrumentation process, which can cause a number of problems. For example, tests share their state in memory, and if one test crashes, it prevents the remainder of the test suite from running.
Although it's possible to isolate tests by issuing sequential adb commands, this process adds host-side processing load. By using the new Android Test Orchestrator instead, you can achieve test isolation entirely on the device, as shown in this diagram:
adb
Be aware that if your tests require shared state to pass, the orchestrator causes them to fail. This behavior is by design. As of this post, Android Test Orchestrator is in beta and is available for use via the command line. We have integrations planned for Firebase Test Lab and Android Studio, coming soon.
For more information, see the Android Testing Orchestrator developer guide.
AndroidJUnitRunner now includes a number of additional features:
JUnitParams
Sometimes you want to test an activity that you create and configure on the fly as part of your test workflow. Now, you can configure MonitoringInstrumentation (and by extension, AndroidJUnitRunner) using an InterceptingActivityFactory. You can create your activity under test with a test-specific configuration without having to rely on compile-time injection.
MonitoringInstrumentation
AndroidJUnitRunner
InterceptingActivityFactory
This overview highlights only some of the most significant changes that we've made to ATSL. They are many more changes that are worth exploring. For the full release details, refer to our release notes.
Last but not least, we want to thank all the developers who contributed features to this release. We also want to thank the Android testing experts on the mobile engineering teams at American Express, Slack and GDE Chiu-Ki Chan for collaborating with us and providing valuable feedback on the pre-release version of Android Testing Support Library.
Happy testing from the ATSL team!
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!
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.
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.
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.
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.
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.
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!
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!
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
adb shell setenforce 0 && adb stop && adb start
//bionic/libc/seccomp
//cts/tests/tests/security/jni/android_security_cts_SeccompTest.cpp
add_key
keyctl
openat
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.
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.
Moving HALs into their own processes better adheres to the principle of least privilege. This provides two distinct advantages:
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.
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.
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.
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.
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.
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.
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.
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!
Play Console
