Maintaining Android in the enterprise

Risk Management

Sniffing, Logging, Hardening

With apps such as Network Log [7], smartphones can sniff network traffic caused by the device over longer periods of time. With this information filtered or packaged in easily understandable charts (Figure 1), admins and users can track which app causes how much data traffic.

Figure 1: Only one monitoring app among many: Network Log sniffing network traffic on a rooted Android (here a Nexus 7) and creating useful stats.

A Flashlight app, for example, that transmits data on a regular basis would at least cause an attentive user some thought. Malware or break-in tools that want to transfer large amounts of data unnoticed would have to be prepared for this or change the TCP stack to remain undetected. Again, you can monitor individual applications, set filters, and much more. Surprisingly, excessive battery consumption is not an issue during logging.

Such useful tools are a dime a dozen in the Google Play store or alternative app stores. Apparently, many websites offer top 10, top 20, or even top 30 lists of the best root apps. We gained a positive impression of tools such as Android Tuner, Cron Tasker, Adblock Plus, zAnti, or the WiFi inspection tool and PCAP sniffer WiFinspect. The AFWall [8] firewall application (Figure 2), which allows application-specific Internet access, seems similarly successful. It gives smartphone owners an easy option for preventing individual apps connecting on GSM networks and explicitly restricting access to WiFi.

Figure 2: The firewall app AFWall+ configures who is allowed to open connections, when, and using what media.

An equally large collection of backup and restore tools lets users back up apps and their data in the Android GUI – for example, the popular Titanium Backup [9]. Other apps for admins are described in an article in Linux Magazine [10]. Many admins and owners of smartphones, however, do not know that the Linux or Android console also offers many tools.

ADB: Android Debug Bridge

The Android SDK [3], includes the Android Debug Bridge (ADB). This small tool, together with a daemon using the same name, sets up a terminal connection to a USB-connected smartphone (Listing 1). Both the adb tool and the Android shell itself offer a variety of useful commands for monitoring, backing up, and restoring devices to a predefined state.

Listing 1

Using ADB

01 [mfeilner@pc]# adb devices
02 List of devices attached
04 [mfeilner@pc]# su
05 Password:
06 [root@pc]# killall adb
07 [...]
08 [root@pc]# adb devices
09 * daemon not running. starting it now on port 5037 *
10 * daemon started successfully *
11 List of devices attached
12 015d8bed0d3c0814        device

If you use the commands from the SDK regularly, it makes sense to add its path, preferably like this:

PATH= $PATH:/home/mfeilner/bin/adt-bundle-linux-x86_64 \

to your Linux path, and ideally via the start files for the shell. If you want to provide the SDK to multiple users, the best idea is to unpack it in /opt.

Listing 1 shows that sometimes root privileges are needed to detect Androids connected to USB. For this to work, root may need to kill the ADB daemon started by the user; after doing this, the smartphone appears. (For this reason, the command only works in line 8 of Listing 1.) After confirmation on the Android display, the status changes in line 12 from unauthorized to device. Listing 2 shows some initial information from the Nexus 7.

Listing 2

The ADB Shell

01 [root@pc]# adb shell
02 shell@android:/ $ uname -a
03 Linux localhost 3.1.10-gd08812a #1 SMP PREEMPT Wed Sep 4 19:55:23 PDT \
   2013 armv7l GNU/Linux
04 shell@android:/ $ cat /proc/version
05 Linux version 3.1.10-gd08812a (build03@cyanogenmod) (gcc version \
   4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Sep 4 \
   19:55:23 PDT 2013
06 shell@android:/ $ free
07       total   used    free    shared   buffers
08 Mem:  997720  880472  117248  0        12320
09 -/+ buffers:  868152  129568
10 Swap:   0  0  0
11 shell@android:/ $ cat /proc/cpuinfo
12 Processor       : ARMv7 Processor rev 9 (v7l)
13 processor       : 0
14 BogoMIPS        : 1993.93
15 processor       : 1
16 BogoMIPS        : 1993.93
17 processor       : 2
18 BogoMIPS        : 1993.93
19 processor       : 3
20 BogoMIPS        : 1993.93
21 Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls
22 CPU implementer : 0x41
23 CPU architecture: 7
24 CPU variant     : 0x2
25 CPU part        : 0xc09
26 CPU revision    : 9
27 Hardware        : grouper
28 Revision        : 0000
29 Serial          : 0f410a0001440200

USB Debugging

The whole process only works if USB debugging is enabled on the Android, and the Android user taps the OK button in the confirmation dialog for the PC – a radio button lets you optionally connect individual machines immediately and without prompting.

Incidentally, you can enable USB debugging on newer versions of Android by tapping the Settings | About Phone/Tablet | Build Number entry seven times. On the fourth tap, you see a pop-up; then a new entry appears in the settings where you can enable USB debugging. After doing this, the tweaks described below with ADB, Fastboot, and flashing the device's ROM become possible.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.