Author Archives: Android Developers

Announcing Nearby Connections 2.0: fully offline, high bandwidth peer to peer device communication

Posted by Ritesh Nayak M, Product Manager

Imagine walking into a hotel room and having the temperature set just right, your favorite sub-genre of progressive-math-rock playing in the background, and the TV urging you to continue binging on your saved guilty-pleasures watchlist. What if your phone's contact book could expand to merge with your spouse's when you're together, so you're never again put in the excruciatingly compromising position of having to ask for your mother-in-law's phone number (which you ought to have had on speed dial, in your favorites, and listed as an emergency contact)? Now imagine a world where you can drive up to an empty driveway or private parking space in a city like New York or San Francisco, and negotiate with that space to rent it out until its owner returns.

The common thread among all these scenarios is being able to detect proximity to -- and being able to communicate with -- people, places, and things "near" you.

At I/O this year, we spoke about a refresh to the Nearby Connections API that can provide high bandwidth, low latency, encrypted data transfers between nearby devices in a fully-offline P2P manner. Today we're announcing the availability of this API across all Android devices running Google Play services 11.0 and up.

Nearby Connections uses WiFi, Bluetooth LE & Classic Bluetooth under the hood to discover and establish connections to nearby devices. It abstracts away the inherent complexity of these radios by leveraging the strengths of each, while circumventing their respective weaknesses. Aside from the obvious advantage of sidestepping the pain of dealing with the vagaries of these radios across different OS versions and devices, this abstraction enables seamlessly upgrading the bandwidth of a connection by switching between the radios as and when it makes sense, as well as getting invisible over-the-air updates to use new radio technology as it becomes available -- with no change whatsoever in the application code.

At the heart of this API is a connection (with Unix-socket-like semantics) that you can use to transfer bytes, files, or streams of data. There are two supported connection topologies:
  • Star: Useful for creating 1:N topologies where there's a centralized device that others are especially interested in. For example, the host of an offline game, or the teacher's device in a classroom quiz app.
  • Cluster: Useful for creating M:N topologies that allow for creating looser mesh-like networks. For example, a classroom app that supports forming ad-hoc project groups for realtime collaboration, or an offline hyper-proximity-based chat app.
As a part of the process of building this API we worked with a few partners, each with unique offline-data-transfer needs and environments. It's been great to see what they've built on top of early versions of this API, and their feedback has been invaluable in guiding us towards today's launch. Take a look at some of the cool things they're building:
  • The Weather Channel is building on-demand mesh networks in data-deficient areas to spread urgent weather warnings.
  • Hotstar enables offline media sharing in places with spotty/no internet connectivity (like on public transportation, airplanes, etc.)
  • GameInsight is using Nearby Connections to not only find nearby players, but also to run entire games offline.
  • Android TV is building a remote control app (powered by Nearby Connections) to simplify initial setup, and to enable subsequent second screen experiences.
Now that the API is publicly available, we can't wait to see how you will use Nearby Connections in your applications. To get started, visit our developer site, check our code samples, and post any questions you have on Stackoverflow (tagged with google-nearby). To stay up to date on the latest Android Nearby offerings (and our other Context-related APIs), please subscribe to our mailing list.



What’s new for shortcuts and widgets in Android O

Posted by Gloria Liou, Associate Product Manager Intern


Why use shortcuts and widgets?


One of our favorite features in Android O is the ability to pin shortcuts and widgets for your app onto the launcher through deep linking.


Shortcuts let users quickly start a specific task, while widgets give users instant access to specific actions and information from your app. Users want to get things done, and get things done fast - shortcuts and widgets are a way to help them and to increase user engagement with your content.

To pin a shortcut or widget, users long press your app's icon for options and drag and drop the selected item to a location of their choice.


Dynamic / static shortcuts
Pinned shortcuts






Adding shortcuts and widgets from within your app




 The API has a new flow for adding shortcuts and widgets from within your app. The new method uses a modal dialog, deprecating the old method of using a broadcast, which will not work on O devices.

That's not all. We've made improvements to the user interface and experience. In the old experience, there was no app icon on the shortcut, so users had no idea which app the shortcut was from. Marking shortcuts with the app icon provides better branding while protecting users from potential malware.





Old shortcut
New shortcut



There is also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.



With these new additions and improvements, users will be more likely to use your shortcuts and widgets, leading to more meaningful and impactful engagement with your app and happier, more productive users.

To learn more, head over to the shortcuts and widgets page on the Android Developers website.


Get the updated Playbook app for news and tips to help you grow your business on Google Play

Posted by Dom Elliott, Developer Marketing, Google Play

Get the latest Playbook app for developers to learn about features, best practices, and strategies to succeed on Google Play. Discover insights from Google to help you develop and launch your app, engage and grow your audience, and earn more revenue. With localized content, the Playbook app for developers is available in 14 languages (English, Bahasa Indonesia, Deutsch, español (Latinoamérica), le français, português do Brasil, ภาษาไทย, tiếng Việt, Türk, русский язы́к, 한국어, 中文 (简体), 中文 (繁體), and 日本語).

Thank you to all the beta testers who provided valuable feedback (keep it coming!). With the latest update, we have simplified the user experience, improved content discovery, and automated notifications for different types of content (which are customizable) to help you stay up to date, among other improvements. You can also add tags to the home screen based on your interests to easily see posts and videos that are relevant to you.

To get started, install the updated Playbook app for developers and then:

  • Follow the onboarding and sign in with your Google account.
  • Read the latest posts on the home screen and add tags from the settings screen which match your interests..
  • Explore in-depth best practices written by Google in our guide, and see the top articles for grouped by your objectives: develop, launch, engage, grow, and earn.
  • Discover the latest posts and videos from Google and experts across the industry and filter by interest tags.
  • Save content so you can view posts and videos on your home screen and access relevant content more quickly.
How useful did you find this blogpost?
★ ★ ★ ★ ★

From Chrysaor to Lipizzan: Blocking a new targeted spyware family

Posted by Megan Ruthven Android Security, Ken Bodzak Threat Analysis Group, Neel Mehta Threat Analysis Group

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.

How does Lipizzan work?

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:

  • Call recording
  • VOIP recording
  • Recording from the device microphone
  • Location monitoring
  • Taking screenshots
  • Taking photos with the device camera(s)
  • Fetching device information and files
  • Fetching user information (contacts, call logs, SMS, application-specific data)

The PHA had specific routines to retrieve data from each of the following apps:

  • Gmail
  • Hangouts
  • KakaoTalk
  • LinkedIn
  • Messenger
  • Skype
  • Snapchat
  • StockEmail
  • Telegram
  • Threema
  • Viber
  • Whatsapp

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.

  • The apps changed from 'backup' apps to looking like a "cleaner", "notepad", "sound recorder", and "alarm manager" app. The new apps were uploaded within a week of the takedown, showing that the authors have a method of easily changing the branding of the implant apps.
  • The app changed from downloading an unencrypted stage 2 to including stage 2 as an encrypted blob. The new stage 1 would only decrypt and load the 2nd stage if it received an intent with an AES key and IV.

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?

  • Ensure you are opted into Google Play Protect.
  • Exclusively use the Google Play store. The chance you will install a PHA is much lower on Google Play than using other install mechanisms.
  • Keep "unknown sources" disabled while not using it.
  • Keep your phone patched to the latest Android security update.

List of samples

1st stage

Older version

Package Name Latest App SHA 256
com.safe.datasaver 5d6a8c9c335edaf0b5d010f30e9fc9cea1e7a19d8c4e888079d6a6a4bae5aaef
com.and.goldbackup 3a9f25b2ba38974b0eb8de76ad37abc77f7eb068e6880305cc1faaba4467d5cf
com.star.backupstar ed4f693ea491ab0c455499fbaeddec70652b506f778130b43101b2496669fe59
com.veramon.backupit 27971324142ae23aad3f7e95e7eb1b85a7f08b39b4a4d27aab177669e875791b
com.copanga.backupplus 726b91193469513405b95f0c20cb0ec94396ce317ac0f763e98af949186630f8
com.app.thunderbackup 99282aa2d17a341d88a6e1944149639bcc8f711cdcd134a455b0c25951111712
com.kopos.nowbackup 48305da03403990395afb159c56370d204b0e32343f3b0790b640653ee79e5c9
com.appnow.backupdroid 35896010e204b064e313204d525185586924b31a0804d0512ba5467fc95cb35e
com.apptimus.androidbackuppro b615936270d9dab3c29d7b0a3c1fc846f1f5d82570fb917849769f578cfaeb01
com.app.backupfast 9efa83579e769f73793e138d79d15aa5b96e42c58b568eab00edece6219e2322
com.app.instantbackup a5f266864b341f8558aacdee1a38fe4b95a9035bf9c0c1d7761e23de2181dcf2

Newer version

Package Name Latest App SHA 256
com.sd.sdbackup 8ebe42ce2c03e56cb97bb2dc1be47a4226899d6f648c30eecb19e32a7867657a
com.app.procleaner affc95a6db70b62b4252fe5da4016ae873b33e645147f06f12a33c9dc5305ae4
com.app.alarmmanager fe121da2a53632ba2b617eae26c72b685ed4853a6b3f9fd223af11a1042c3541
com.app.soundrecorder aa4445023df7b203e8078858b502d1082647c815b24c3335a58347bc98b79c74
com.mem.notesplus 24aa8a2f2fbbbe82b89076bf1981bdedb7ecb4baa9e036993504e8309269b373
com.app.processcleaner b2eca848730d41c2e8001ec7316352343b84327d59e193aacdcd0d01aceb79f2
com.kobm.devicecleaner 6ddad8d049fd25e06b84de013dfec7e1bb09abca78604305b9ae1df6c4145e5c
com.yonni.deviceoptimizer 2f8fab18374080ac42422e5e79a693438b81f95f76de5f2f34cd2a0c882f06ef
com.haima.ultracleaner af7f90809d4e3bf160ccf4a219012f9dac283657f57b812733022f4a966428ea

Standalone 2nd stage

Package Name Latest App SHA 256
com.android.mediaserver 1ba8d5f45e8cd545cc3b919bea80e7bd5c6c85fc822f52edc0669191536d43da

From Chrysaor to Lipizzan: Blocking a new targeted spyware family

Posted by Megan Ruthven Android Security, Ken Bodzak Threat Analysis Group, Neel Mehta Threat Analysis Group

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.

How does Lipizzan work?

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:

  • Call recording
  • VOIP recording
  • Recording from the device microphone
  • Location monitoring
  • Taking screenshots
  • Taking photos with the device camera(s)
  • Fetching device information and files
  • Fetching user information (contacts, call logs, SMS, application-specific data)

The PHA had specific routines to retrieve data from each of the following apps:

  • Gmail
  • Hangouts
  • KakaoTalk
  • LinkedIn
  • Messenger
  • Skype
  • Snapchat
  • StockEmail
  • Telegram
  • Threema
  • Viber
  • Whatsapp

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.

  • The apps changed from 'backup' apps to looking like a "cleaner", "notepad", "sound recorder", and "alarm manager" app. The new apps were uploaded within a week of the takedown, showing that the authors have a method of easily changing the branding of the implant apps.
  • The app changed from downloading an unencrypted stage 2 to including stage 2 as an encrypted blob. The new stage 1 would only decrypt and load the 2nd stage if it received an intent with an AES key and IV.

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?

  • Ensure you are opted into Google Play Protect.
  • Exclusively use the Google Play store. The chance you will install a PHA is much lower on Google Play than using other install mechanisms.
  • Keep "unknown sources" disabled while not using it.
  • Keep your phone patched to the latest Android security update.

List of samples

1st stage

Older version

Package Name Latest App SHA 256
com.safe.datasaver 5d6a8c9c335edaf0b5d010f30e9fc9cea1e7a19d8c4e888079d6a6a4bae5aaef
com.and.goldbackup 3a9f25b2ba38974b0eb8de76ad37abc77f7eb068e6880305cc1faaba4467d5cf
com.star.backupstar ed4f693ea491ab0c455499fbaeddec70652b506f778130b43101b2496669fe59
com.veramon.backupit 27971324142ae23aad3f7e95e7eb1b85a7f08b39b4a4d27aab177669e875791b
com.copanga.backupplus 726b91193469513405b95f0c20cb0ec94396ce317ac0f763e98af949186630f8
com.app.thunderbackup 99282aa2d17a341d88a6e1944149639bcc8f711cdcd134a455b0c25951111712
com.kopos.nowbackup 48305da03403990395afb159c56370d204b0e32343f3b0790b640653ee79e5c9
com.appnow.backupdroid 35896010e204b064e313204d525185586924b31a0804d0512ba5467fc95cb35e
com.apptimus.androidbackuppro b615936270d9dab3c29d7b0a3c1fc846f1f5d82570fb917849769f578cfaeb01
com.app.backupfast 9efa83579e769f73793e138d79d15aa5b96e42c58b568eab00edece6219e2322
com.app.instantbackup a5f266864b341f8558aacdee1a38fe4b95a9035bf9c0c1d7761e23de2181dcf2

Newer version

Package Name Latest App SHA 256
com.sd.sdbackup 8ebe42ce2c03e56cb97bb2dc1be47a4226899d6f648c30eecb19e32a7867657a
com.app.procleaner affc95a6db70b62b4252fe5da4016ae873b33e645147f06f12a33c9dc5305ae4
com.app.alarmmanager fe121da2a53632ba2b617eae26c72b685ed4853a6b3f9fd223af11a1042c3541
com.app.soundrecorder aa4445023df7b203e8078858b502d1082647c815b24c3335a58347bc98b79c74
com.mem.notesplus 24aa8a2f2fbbbe82b89076bf1981bdedb7ecb4baa9e036993504e8309269b373
com.app.processcleaner b2eca848730d41c2e8001ec7316352343b84327d59e193aacdcd0d01aceb79f2
com.kobm.devicecleaner 6ddad8d049fd25e06b84de013dfec7e1bb09abca78604305b9ae1df6c4145e5c
com.yonni.deviceoptimizer 2f8fab18374080ac42422e5e79a693438b81f95f76de5f2f34cd2a0c882f06ef
com.haima.ultracleaner af7f90809d4e3bf160ccf4a219012f9dac283657f57b812733022f4a966428ea

Standalone 2nd stage

Package Name Latest App SHA 256
com.android.mediaserver 1ba8d5f45e8cd545cc3b919bea80e7bd5c6c85fc822f52edc0669191536d43da

From Chrysaor to Lipizzan: Blocking a new targeted spyware family

Posted by Megan Ruthven Android Security, Ken Bodzak Threat Analysis Group, Neel Mehta Threat Analysis Group

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.

How does Lipizzan work?

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:

  • Call recording
  • VOIP recording
  • Recording from the device microphone
  • Location monitoring
  • Taking screenshots
  • Taking photos with the device camera(s)
  • Fetching device information and files
  • Fetching user information (contacts, call logs, SMS, application-specific data)

The PHA had specific routines to retrieve data from each of the following apps:

  • Gmail
  • Hangouts
  • KakaoTalk
  • LinkedIn
  • Messenger
  • Skype
  • Snapchat
  • StockEmail
  • Telegram
  • Threema
  • Viber
  • Whatsapp

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.

  • The apps changed from 'backup' apps to looking like a "cleaner", "notepad", "sound recorder", and "alarm manager" app. The new apps were uploaded within a week of the takedown, showing that the authors have a method of easily changing the branding of the implant apps.
  • The app changed from downloading an unencrypted stage 2 to including stage 2 as an encrypted blob. The new stage 1 would only decrypt and load the 2nd stage if it received an intent with an AES key and IV.

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?

  • Ensure you are opted into Google Play Protect.
  • Exclusively use the Google Play store. The chance you will install a PHA is much lower on Google Play than using other install mechanisms.
  • Keep "unknown sources" disabled while not using it.
  • Keep your phone patched to the latest Android security update.

List of samples

1st stage

Older version

Package Name Latest App SHA 256
com.safe.datasaver 5d6a8c9c335edaf0b5d010f30e9fc9cea1e7a19d8c4e888079d6a6a4bae5aaef
com.and.goldbackup 3a9f25b2ba38974b0eb8de76ad37abc77f7eb068e6880305cc1faaba4467d5cf
com.star.backupstar ed4f693ea491ab0c455499fbaeddec70652b506f778130b43101b2496669fe59
com.veramon.backupit 27971324142ae23aad3f7e95e7eb1b85a7f08b39b4a4d27aab177669e875791b
com.copanga.backupplus 726b91193469513405b95f0c20cb0ec94396ce317ac0f763e98af949186630f8
com.app.thunderbackup 99282aa2d17a341d88a6e1944149639bcc8f711cdcd134a455b0c25951111712
com.kopos.nowbackup 48305da03403990395afb159c56370d204b0e32343f3b0790b640653ee79e5c9
com.appnow.backupdroid 35896010e204b064e313204d525185586924b31a0804d0512ba5467fc95cb35e
com.apptimus.androidbackuppro b615936270d9dab3c29d7b0a3c1fc846f1f5d82570fb917849769f578cfaeb01
com.app.backupfast 9efa83579e769f73793e138d79d15aa5b96e42c58b568eab00edece6219e2322
com.app.instantbackup a5f266864b341f8558aacdee1a38fe4b95a9035bf9c0c1d7761e23de2181dcf2

Newer version

Package Name Latest App SHA 256
com.sd.sdbackup 8ebe42ce2c03e56cb97bb2dc1be47a4226899d6f648c30eecb19e32a7867657a
com.app.procleaner affc95a6db70b62b4252fe5da4016ae873b33e645147f06f12a33c9dc5305ae4
com.app.alarmmanager fe121da2a53632ba2b617eae26c72b685ed4853a6b3f9fd223af11a1042c3541
com.app.soundrecorder aa4445023df7b203e8078858b502d1082647c815b24c3335a58347bc98b79c74
com.mem.notesplus 24aa8a2f2fbbbe82b89076bf1981bdedb7ecb4baa9e036993504e8309269b373
com.app.processcleaner b2eca848730d41c2e8001ec7316352343b84327d59e193aacdcd0d01aceb79f2
com.kobm.devicecleaner 6ddad8d049fd25e06b84de013dfec7e1bb09abca78604305b9ae1df6c4145e5c
com.yonni.deviceoptimizer 2f8fab18374080ac42422e5e79a693438b81f95f76de5f2f34cd2a0c882f06ef
com.haima.ultracleaner af7f90809d4e3bf160ccf4a219012f9dac283657f57b812733022f4a966428ea

Standalone 2nd stage

Package Name Latest App SHA 256
com.android.mediaserver 1ba8d5f45e8cd545cc3b919bea80e7bd5c6c85fc822f52edc0669191536d43da

From Chrysaor to Lipizzan: Blocking a new targeted spyware family

Posted by Megan Ruthven Android Security, Ken Bodzak Threat Analysis Group, Neel Mehta Threat Analysis Group

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.

How does Lipizzan work?

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:

  • Call recording
  • VOIP recording
  • Recording from the device microphone
  • Location monitoring
  • Taking screenshots
  • Taking photos with the device camera(s)
  • Fetching device information and files
  • Fetching user information (contacts, call logs, SMS, application-specific data)

The PHA had specific routines to retrieve data from each of the following apps:

  • Gmail
  • Hangouts
  • KakaoTalk
  • LinkedIn
  • Messenger
  • Skype
  • Snapchat
  • StockEmail
  • Telegram
  • Threema
  • Viber
  • Whatsapp

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.

  • The apps changed from 'backup' apps to looking like a "cleaner", "notepad", "sound recorder", and "alarm manager" app. The new apps were uploaded within a week of the takedown, showing that the authors have a method of easily changing the branding of the implant apps.
  • The app changed from downloading an unencrypted stage 2 to including stage 2 as an encrypted blob. The new stage 1 would only decrypt and load the 2nd stage if it received an intent with an AES key and IV.

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?

  • Ensure you are opted into Google Play Protect.
  • Exclusively use the Google Play store. The chance you will install a PHA is much lower on Google Play than using other install mechanisms.
  • Keep "unknown sources" disabled while not using it.
  • Keep your phone patched to the latest Android security update.

List of samples

1st stage

Older version

Package Name Latest App SHA 256
com.safe.datasaver 5d6a8c9c335edaf0b5d010f30e9fc9cea1e7a19d8c4e888079d6a6a4bae5aaef
com.and.goldbackup 3a9f25b2ba38974b0eb8de76ad37abc77f7eb068e6880305cc1faaba4467d5cf
com.star.backupstar ed4f693ea491ab0c455499fbaeddec70652b506f778130b43101b2496669fe59
com.veramon.backupit 27971324142ae23aad3f7e95e7eb1b85a7f08b39b4a4d27aab177669e875791b
com.copanga.backupplus 726b91193469513405b95f0c20cb0ec94396ce317ac0f763e98af949186630f8
com.app.thunderbackup 99282aa2d17a341d88a6e1944149639bcc8f711cdcd134a455b0c25951111712
com.kopos.nowbackup 48305da03403990395afb159c56370d204b0e32343f3b0790b640653ee79e5c9
com.appnow.backupdroid 35896010e204b064e313204d525185586924b31a0804d0512ba5467fc95cb35e
com.apptimus.androidbackuppro b615936270d9dab3c29d7b0a3c1fc846f1f5d82570fb917849769f578cfaeb01
com.app.backupfast 9efa83579e769f73793e138d79d15aa5b96e42c58b568eab00edece6219e2322
com.app.instantbackup a5f266864b341f8558aacdee1a38fe4b95a9035bf9c0c1d7761e23de2181dcf2

Newer version

Package Name Latest App SHA 256
com.sd.sdbackup 8ebe42ce2c03e56cb97bb2dc1be47a4226899d6f648c30eecb19e32a7867657a
com.app.procleaner affc95a6db70b62b4252fe5da4016ae873b33e645147f06f12a33c9dc5305ae4
com.app.alarmmanager fe121da2a53632ba2b617eae26c72b685ed4853a6b3f9fd223af11a1042c3541
com.app.soundrecorder aa4445023df7b203e8078858b502d1082647c815b24c3335a58347bc98b79c74
com.mem.notesplus 24aa8a2f2fbbbe82b89076bf1981bdedb7ecb4baa9e036993504e8309269b373
com.app.processcleaner b2eca848730d41c2e8001ec7316352343b84327d59e193aacdcd0d01aceb79f2
com.kobm.devicecleaner 6ddad8d049fd25e06b84de013dfec7e1bb09abca78604305b9ae1df6c4145e5c
com.yonni.deviceoptimizer 2f8fab18374080ac42422e5e79a693438b81f95f76de5f2f34cd2a0c882f06ef
com.haima.ultracleaner af7f90809d4e3bf160ccf4a219012f9dac283657f57b812733022f4a966428ea

Standalone 2nd stage

Package Name Latest App SHA 256
com.android.mediaserver 1ba8d5f45e8cd545cc3b919bea80e7bd5c6c85fc822f52edc0669191536d43da

Android Testing Support Library 1.0 is here!

Posted by Michael Amygdalidis, Stephan Linzner and Nick Korostelev from the Mobile-Ninjas team at Google

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 Improvements

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.

Idling Registry

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.

Registration from the Espresso class is now deprecated.

Idling Resources

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!

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.

ProviderTestRule

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.

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.

Grant Permission Rule

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.

Android Test Orchestrator

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:

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

AndroidJUnitRunner now includes a number of additional features:

  • You can use JUnitParams.
  • You can configure class loaders and custom JUnit test filters using the runner arguments

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.

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!

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.