How to

To access devices connected to USB via adb or fastboot on linux, you need to configure udev rules. For detailed information about udev, take a look at udev – Arch Linux from the ArchLinux wiki (note that UDEV rules are not exclusive to Arch; udev is used in numerous distributions). You can follow the method below to add rules for any user that is part of the plugdev group, or you can follow Google Android’s instructions to add rules only for your username.

Follow these steps to setup the correct rules:

1. Verify your username is included in the plugdev group. Type
   groups
   from a terminal and look for plugdev in the listed groups. If you do not see plugdev listed, you can add your username to the group with:
   sudo gpasswd -a username plugdev
   where username should be replaced with your linux username.
2. Copy the set of rules listed below these steps to a text file and save it as /etc/udev/rules.d/51-android.rules. You will need sudo/su to write to that directory. So, for instance:
   sudo nano /etc/udev/rules.d/51-android.rules
   These rules cover all vendors listed by Google. Optionally, you can add just the vendor corresponding to the device(s) you plan to connect to your computer.
3. Restart your computer and then test plugging in your device to the computer with USB debugging enabled.

#Acer
SUBSYSTEM=="usb", ATTR{idVendor}=="0502", MODE="0664", GROUP="plugdev"
#ASUS
SUBSYSTEM=="usb", ATTR{idVendor}=="0b05", MODE="0664", GROUP="plugdev"
#Dell
SUBSYSTEM=="usb", ATTR{idVendor}=="413c", MODE="0664", GROUP="plugdev"
#Foxconn
SUBSYSTEM=="usb", ATTR{idVendor}=="0489", MODE="0664", GROUP="plugdev"
#Fujitsu & Fujitsu Toshiba
SUBSYSTEM=="usb", ATTR{idVendor}=="04c5", MODE="0664", GROUP="plugdev"
#Garmin-Asus
SUBSYSTEM=="usb", ATTR{idVendor}=="091e", MODE="0664", GROUP="plugdev"
#Google
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0664", GROUP="plugdev"
#Haier
SUBSYSTEM=="usb", ATTR{idVendor}=="201e", MODE="0664", GROUP="plugdev"
#Hisense
SUBSYSTEM=="usb", ATTR{idVendor}=="109b", MODE="0664", GROUP="plugdev"
#HTC
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0664", GROUP="plugdev"
#Huawei
SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", MODE="0664", GROUP="plugdev"
#Intel
SUBSYSTEM=="usb", ATTR{idVendor}=="8087", MODE="0664", GROUP="plugdev"
#K-Touch
SUBSYSTEM=="usb", ATTR{idVendor}=="24e3", MODE="0664", GROUP="plugdev"
#KT Tech
SUBSYSTEM=="usb", ATTR{idVendor}=="2116", MODE="0664", GROUP="plugdev"
#Kyocera
SUBSYSTEM=="usb", ATTR{idVendor}=="0482", MODE="0664", GROUP="plugdev"
#Lenovo
SUBSYSTEM=="usb", ATTR{idVendor}=="17ef", MODE="0664", GROUP="plugdev"
#LG
SUBSYSTEM=="usb", ATTR{idVendor}=="1004", MODE="0664", GROUP="plugdev"
#Motorola
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", MODE="0664", GROUP="plugdev"
#MTK
SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", MODE="0664", GROUP="plugdev"
#NEC
SUBSYSTEM=="usb", ATTR{idVendor}=="0409", MODE="0664", GROUP="plugdev"
#Nook
SUBSYSTEM=="usb", ATTR{idVendor}=="2080", MODE="0664", GROUP="plugdev"
#Nvidia
SUBSYSTEM=="usb", ATTR{idVendor}=="0955", MODE="0664", GROUP="plugdev"
#OTGV
SUBSYSTEM=="usb", ATTR{idVendor}=="2257", MODE="0664", GROUP="plugdev"
#Pantech
SUBSYSTEM=="usb", ATTR{idVendor}=="10a9", MODE="0664", GROUP="plugdev"
#Pegatron
SUBSYSTEM=="usb", ATTR{idVendor}=="1d4d", MODE="0664", GROUP="plugdev"
#Philips
SUBSYSTEM=="usb", ATTR{idVendor}=="0471", MODE="0664", GROUP="plugdev"
#PMC-Sierra
SUBSYSTEM=="usb", ATTR{idVendor}=="04da", MODE="0664", GROUP="plugdev"
#Qualcomm
SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", MODE="0664", GROUP="plugdev"
#SK Telesys
SUBSYSTEM=="usb", ATTR{idVendor}=="1f53", MODE="0664", GROUP="plugdev"
#Samsung
SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", MODE="0664", GROUP="plugdev"
#Sharp
SUBSYSTEM=="usb", ATTR{idVendor}=="04dd", MODE="0664", GROUP="plugdev"
#Sony
SUBSYSTEM=="usb", ATTR{idVendor}=="054c", MODE="0664", GROUP="plugdev"
#Sony Ericsson
SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", MODE="0664", GROUP="plugdev"
#Teleepoch
SUBSYSTEM=="usb", ATTR{idVendor}=="2340", MODE="0664", GROUP="plugdev"
#Toshiba
SUBSYSTEM=="usb", ATTR{idVendor}=="0930", MODE="0664", GROUP="plugdev"
#Wileyfox
SUBSYSTEM=="usb", ATTR{idVendor}=="2970", MODE="0664", GROUP="plugdev"
#YU
SUBSYSTEM=="usb", ATTR{idVendor}=="1ebf", MODE="0664", GROUP="plugdev"
#ZTE
SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", MODE="0664", GROUP="plugdev"
#ZUK
SUBSYSTEM=="usb", ATTR{idVendor}=="2b4c", MODE="0664", GROUP="plugdev"

Troubleshooting

1. Make sure your device is connected and accessible via usb. lsusb should show a list of connected devices. The section after ‘ID’ in the output should match one of the idVendor numbers from the udev rules. For example, a Nexus One with idVendor 18d1 should return something like:

Bus 001 Device 005: ID 17ef:480d Lenovo Integrated Webcam [R5U877]
Bus 002 Device 002: ID 0bda:0119 Realtek Semiconductor Corp. 
Bus 002 Device 009: ID 18d1:4e12 Google Inc. Nexus One (debug)
Bus 004 Device 003: ID 0a5c:2145 Broadcom Corp. Bluetooth with Enhanced Data Rate II
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

2. If the device is detected in lsusb, try running adb devices. If you get ???????????? device, try reloading the udev rules:

 sudo sh -c "(udevadm control --reload-rules && udevadm trigger --action=change)"

You can also try disconnecting and reconnecting the usb cable to your device.

3. If you cannot access your device via adb, even after adding your linux user to the plugdev group and restarting the computer, you can try starting the adb service as root. This is dangerous and not recommended:

adb kill-server
sudo $(which adb) start-server
adb devices

Similarly, if fastboot devices returns no permissions, try running fastboot as root:

sudo $(which fastboot) devices

So you want to help out…

As with the CyanogenMod project as a whole, this wiki lives or dies based on your participation and willingness to help out. If you’re not a programmer or developer per se, but you’re good with words and want to help, we could use your expertise!

Making Contributions

Everyone is welcome and invited to help with the wiki. The only caveat is to be sure whatever you contribute you have the right to contribute. That said, we invite anyone who is an authority on some material that is appropriate for this wiki to add their knowledge for the benefit of the CyanogenMod community. We appreciate it!

We use templates, templates, templates!

This wiki has many thousands of web pages including articles, contact lists, walkthroughs, and much more. To make it easier to maintain, the wiki has been designed to avoid duplicating information in many places, which would require a lot of work to keep up to date.

Instead, this wiki uses a feature called templates, which is a way of breaking a wiki page into small bite-sized chunks, each of which can be included by reference, or “transcluded” into another page.

One thing that’s neat about transclusion is that a page can include a template which is itself made of multiple pages. In fact, a template can even intelligently determine which page is transcluding it, meaning it can alter its content depending on the context.

Sound a little confusing? Do a little reading up on templates, and it may start to make more sense. But in essence, it comes down to this:

That means that if any chunk of information needs to appear in two places (such as on two separate pages), first create a template, then transclude that template into the new page(s). If something about that chunk of info should change, you only have to change it once, and the two pages that use it will automatically get the change “for free”.

Fixing Problems: The Plan

How to fix a problem:

1. If the problem is something very simple, like a typo or other minor change, feel free to fix it on your own.
2. Some problems, such as incorrect information for a device, should be changed in the device template, which is a page full of “settings” that describe that device. An example of this might be the wrong screen dimensions, or the build instructions showing the wrong branch (such as “jellybean” instead of “gingerbread”.) A simple fix to the device template settings should resolve this.
3. If the problem is more substantial than either of the above scenarios, and you understand how wiki templates work, and you are able to make the change to the Template without negatively affecting any other page that may be using that template, feel free to fix it!
4. If you are unable to resolve the issue on your own and would like someone else to look at it, report the problem on the Site Problems page, and hopefully someone will take a look.

Using the Device Template

There is one kind of template that’s very special on the CM wiki, and that’s the template for devices. Examples of devices include, say, a tablet, or a smartphone, or an android-based game console, or whatever. The Nexus 7 tablet (codename: “grouper”) is a device. So is the HTC Desire Z smartphone (codenamed “vision”). A device is a single piece of hardware that has its own development repository and therefore its own unique distribution of CyanogenMod.

The device template is a special wiki template that’s used to store ALL the information about a single device that is used to automatically generate custom build instructions, device info pages, installation walkthroughs, and more for that device. There’s only one device template per device, and it includes all the characteristics for that device that can be used to build wiki pages using the templating system.

So, using a device template, we can create a very generic set of installation instructions, and have those instructions automatically customized for each individual device. When a new device comes along, we won’t have to rewrite the installation instructions for that device. Instead, by filling out the device template, the installation instructions can “build themselves” to match the requirements for that device.

If this doesn’t make complete sense yet, keep reading. Hopefully you’ll get the gist of it.

How device templates work

A device template has the following name:

Template:Device_codename

where codename is the code name for the device. To create a new device, say, with a code name of “bambi”, you’d create a new page at Template:Device_bambi.

But what do you put in this device template page? We’ve created a nice, fresh, blank for you to use as a base. It’s located, appropriately enough at Template:Device_codename (not working right now). Start with this page, and copy its contents. Then paste it, again using our example, to the page at Template:Device_bambi. Next, modify its contents, choosing appropriate parameters and values for this device.

When you’re done, head over to the devices page. More information can be found there on how to add your device to the list and quickly create an info page, installation instructions, and more.

Wiki roles

As a new visitor, you may not be able to edit any page or template you want. But if you can prove that you are a competent editor, you may be given additional privileges to help maintain and develop the wiki.

Just as the individual devices have developers who are responsible for maintaining the source code for that device, we hope we’ll have volunteers to keep the wiki up to date for devices and device families (like tablets that are all made by the same company for example).

More info on the various roles and how to apply to get elevated editing privileges are forthcoming.

A first attempt at a style guide

If you’re going to be editing text, or even creating new pages, here’s a quick go at some style pointers. Read it carefully.

1. Make it easy to read/digest for anyone. Not just technical people.
2. Don’t dumb it down, though. The audience is your typical non-professional, non-IT end user with an interest in learning what CM is, and why they would use it. And yeah, there’s some smaller percentage of them with a bit more experience who might want to actually start hacking their devices themselves.
3. The goal is to make it EASY for visitors to learn. It’s not meant to be in any way elitist or to create artificial hurdles to learning. The wiki is here to help people.
4. Tone should be irreverent and informal. This is fun stuff. But keep it accurate and as compressed as possible without being overly dry and boring.
5. Include references and links to other sites whenever possible. Never be afraid to send someone to another site if it’s relevant to the topic– this includes other ROMS or wikis.
6. When writing step-by-step instructions, start with a bolded header that explains the goal, ending with a colon. (To do some operation, follow these instructions:) Then number each step individually using the wiki list tag. Keep each step super-clean and simple.
7. Use active, present-tense verbs in instructions. (“Double-click on the icon…”)
8. All on-screen menu items should be bolded and listed from most general to most specific. So present the information in the order that the user will encounter it. Also, use text (“Under the File menu, choose Open File…”) rather than shortcuts like File->Open File. It’s better to standardize this in as clear a manner as possible. The extra work of typing out the steps will pay off for the reader.
9. It’s also a good idea to tell the user what to expect from an action. (“If all goes well, your build should now begin.”)
10. All terminal activity should be presented in Courier using the <code> and </code> tags. Always indicate what text comes from the computer vs. what is entered by the user. Precede console inputs with a “$” to indicate user input.
11. Similarly, any reference to file names or directories within text should also be in Courier. (“Look in the /data directory for a file called README.TXT.”)
12. When accurate grammar is needed, check with Strunk and White. (But that doesn’t mean you can’t use slang and shitty grammar– as long as you’re clear. Just sayin’.)
13. Coordinate your pages with a designer. We should have an uniform, appealing layout and color scheme. Plus tons of screenshots and such are always nice to look at.

Some of the apps that come with your phone can be safely removed without causing stability issues. They take up space and use resources that could be used for other things. Removing unwanted apps will theoretically make your phone run faster and smoother, plus, you can configure your phone just the way you want it.

Below is a chart that shows what apps might come pre-installed in CyanogenMod. You can delete any app that shows ‘yes’ under ‘Remove’; However, if you delete an app, you will no longer be able to use its functionality until you reinstall it. So, for example, if you never listen to music on the device, it is perfectly safe to remove Music.apk. However, you will need to reinstall Music.apk if you ever do want to listen to music on your phone.

Backup apks

You should back up any apks that you plan to remove. That way, you can easily re-install them if you change your mind. You have two main options:

• Nandroid backup from the recovery console, or
• Manual backup with

$ adb pull /system/app/ ~/Desktop/app/

How to find applications

To find what apps are installed on the device, you will need to run the following, either in adb shell, or the device’s term:

$ ls /system/app

or

$ ls /data/app

You can also list installed packages using the package manager, either in Terminal Emulator or via adb shell:

$ pm list packages

To see a list of installed packages along with their associated files:

$ pm list packages -f

At a lower level, you can pull the packages.xml and the packages.list files using adb and examine them directly to determine what is installed and what the related .apk file is called and where it is stored. packages.xml will show you the package name and the .apk file installation path and name. In packages.list you can look up the package name and locate the data path. Both of these files will tell you a great deal more, these are the things that pertain to the present article.

$ adb pull /data/system/packages.xml
$ adb pull /data/system/packages.list

Generally, any apps you install from the market or otherwise manually install will be in /data/app, while any apps that come pre-installed will be in /system/app.

How to remove applications

Remember to watch the case of all files, directories, apk names, and package names!

Case matters. Example.apk and example.apk are two different things.

To remove applications you can use aps on the market Titanium Backup, ROM Toolbox Pro, ES File Explorer or do it through ADB
First of all you restart adbd as root

$ adb root

ADB

$ adb remount
$ adb shell rm -f /system/app/<apk name>.apk

$ adb uninstall <package name>

Term (on device)

$ su
$ mount -o rw,remount /system
$ rm -f /system/app/<apk name>.apk

$ su
$ mount -o rw,remount /data
$ rm -f /data/app/<apk name>.apk
$ pm uninstall <package name>

How to reinstall applications

Change your mind? No problem! You have two options, depending on how you backed up your files:

• Restore your Nandroid backup from the recovery console, or
• Manually restore your app with

$ adb install ~/Desktop/app/<apk name>.apk

List of Default Apps for each version of CyanogenMod

The Profile Manager (available on CM10 via Settings/Profiles) is a feature that is implemented specifically for CyanogenMod. You will not find documentation of this feature in other Android platforms as a result.

The basic idea is to allow you to group “sets” of settings together and then apply them all at once, either manually or automatically.

For example, perhaps at night you want your ringer turned off and during work you want it at a low volume and in the afternoon (when you might be at your son’s game) you want it to be loud.

Below you can see a list of all the options that can be set in a profile.

While looking at the list of profiles (unless you’ve changed them they are “Default”, “Home”, “Night”, “Silent”, and “Work” — Any of these can be renamed or deleted except “Default) you have several options. If you click on the name of the profile (for instance, “Home”) then you will change to that profile — all the settings under that profile will now be active. If you click on the slider icon to the right it will take you into the settings for that particular profile. Or you can click on the “Application Groups” tab (opposite “Profiles” at the top).

Changing Profiles

Once you have decided exactly how you would like your settings to be during each of your contexts, then it is a question of how to choose the correct profile at the right time. In general you can choose a profile manually or automatically.

Choosing Profiles Manually

If you long-press your power button you will get a menu which includes the current profile. If you click on that then you will be presented with a menu of available profiles. Clicking on the desired profile chooses that profile and all setting changes are made to to your phone/tablet.

There are also widgets available which can be placed on your home screen which allow you to choose a given profile. See here for more details and the download.

Choosing Profiles Automatically

Choosing a profile automatically can be done at a certain time (e.g. at 11:00 every night I want my “Night” profile to be activated) or by means of a location (e.g. when I get in my car I see the availability of a bluetooth device and the profile “Car” can be activated automatically or when I get home I see my own AP wirelessly and so I want the profile “Home” activated automatically.) Here are some options, from simplest to complicated, from least capability to greatest capability:

1. The alarm clock that comes with CM7 or CM10 can automatically activate a profile whenever an alarm goes off. Each alarm entry has a Profile field, to which you assign a profile that will start when the alarm triggers. This is a good enough option for automatic switching based on time events and it comes with CyanogenMod by default.
2. There is a free application available on xda-developers.com called Profile Switcher. It is somewhat basic, but it does allow a simple scheduled on/off of any given profile. It also allows for switching on a certain profile for a given period of time (e.g. activate “Meeting” profile for the next 45 minutes). This would suffice nicely for many uses as long as they are time-related.
3. Locale is another option, giving more capabilities for activating profiles automatically.
4. There is a paid application called Tasker which lets you teach your phone to sit up and beg. It’s not *quite* like programming your phone, but it definitely takes a bit of learning. But when you combine it with Profile 4 Tasker +Widget you can activate any profile based on any of what Tasker calls “Contexts”. I won’t go into great detail here (there are lots of tutorials over at the Tasker web-site) but you can choose wireless availability, GPS location, cell tower proximity, bluetooth availability, timed schedules — just about anything you can imagine. Then whenever that context is true, Tasker can activate the profile you choose (or it can do any of hundreds of others of tasks as well — meshing with CyanogenMod Profiles is just a tiny portion of what it can do).
5. Another paid app can come in handy if you want to automatically switch profiles for day and night time: “Good Night, Android!” It also offers the ability to create launcher shortcuts for profiles.

All Options

Here are some of the options that can be set in a profile

• Mobile Data (on/off)
• Bluetooth (on/off)
• GPS (on/off)
• Wi-fi (on/off)
• Data-Sync (on/off)
• Portable Wi-fi Hotspot (on/off)

Then for your volumes you can adjust:

• Alarm (0-7)
• Media (0-15)
• Ringtone (0-7)
• Notification (0-7)

For Vibrator you can adjust:

• for calls (on/off)
• for notifications (on/off)

For system settings you can adjust:

• the lock screen mode (turning off the pattern or the lock screen entirely, like if you use a 3rd party lock screen)
• Airplane Mode (on/off)

Application Groups

Application Groups allow you to group your applications together so that you can establish certain settings for that group of applications.

You could, for instance, group all your social media under a single application group. Then you would be able to change the notification style/volume/tone of all of them at once.

This is a bit confusing, but just think it through. You have the possibility of many profiles. You also have the possibility of many Application Groups. You have the same set of Application Groups across all Profiles and each Application Group has the same apps across all profiles. Each profile can define the settings for any of the Application Groups in any way that seems appropriate. Then activating that profile also changes all those settings on each Application Group where something is set. Make sense?

You define each “Application Group” in terms of what the name of that group is and which applications are included in it. You do this in the tab next to the “Profiles” tab on the main screen in profile setting. Then when you have these already defined you can choose settings for all those applications together when you are defining your “Profile” (after having clicked on the slider-icon next to the name of the profile you want to modify). Here are the settings you can change for a given set of applications:

• Notification mode (on/off/no override)
• Notification tone (choose your ringtone)
• Ring mode (on/off/no override)
• Phone ringtone (choose your ringtone)
• Vibrate mode (on/off/no override)
• Lights mode (on/off/no override)

Future of Profiles

There was some talk back in February/March of 2012 that the Profiles feature in CyanogenMod was going to be developed into a full-blown application allowing the various possibilities for automatic switching. However, it appears that the decision was made to leave that functionality in the hands of the 3rd party apps like Locale and Tasker.

Perhaps at some point the “hooks” for Tasker/Locale will become built-in.

These instructions are for those who have already installed CyanogenMod.

Use the CM Updater (CM10 and newer)

If you use the Google Apps addon (gapps) and are updating between versions where your old gapps is not compatible (e.g. upgrading CM 10.1 to 10.2), it is recommended you apply the update manually in recovery, because you need to flash an updated gapps package. If you do not use gapps or are upgrading a more minor version release, automatic upgrading is recommended.

To update CyanogenMod automatically:

1. Ensure you’ve saved everything important, as doing an update requires the system be restarted.
2. Go to the Settings, and then under About this [device], you should see a menu for checking for and installing updates.
3. Follow the on-screen instructions to perform the update.

If your recovery does not support automatic update installing, you may have to install downloaded zip archive manually. In such case follow instructions in the section below, starting from step 2. You will find downloaded zip under /sdcard/cmupdater directory.

Updating Manually

To update CyanogenMod manually:

1. Download the new version of CyanogenMod for your device. Also download other packages such as Google Apps. The file should typically have a name ending in .zip
2. Boot device into recovery mode
3. If you are doing a major upgrade like CyanogenMod 7 to CyanogenMod 10, you would want to do a Factory Reset from your recovery

   • Note: Different recovery images provide slightly different menu systems, so these instructions will have to be generic. If you have installed CM previously, the options in the recovery menu should already be familiar.

Click here to continue instructions using ADB Push (Preferred Method)

Click here to continue instructions using ADB Sideload

External Links

• How To Update Cyanogenmod? – CyanogenMod Forum

Bypass Gerrit

Say you have a bunch of changes and want to skip gerrit’s interface entirely, pushing directly to the repository. For this you will need special privileges.

This is a summary of the user-upload feature, described in detail here.

To bypass Gerrit:

1. repo sync
2. branch the repository to anything.
3. In the new branch, add your commits (or merge from another branch, git pull from AOSP, or whatever gets your changes in).
4. Next, enter cmremote. This command will add the remote (use git remote -v to see it).
5. To bypass gerrit, type git push cmremote HEAD:refs/heads/cm-13.0 (assuming cm-13.0 is the branch to which you are pushing).

To mass-push commits to Gerrit for review

1. Repeat steps 1-4 above.
2. Then, to mass-push TO Gerrit, use refs/for/branch instead of refs/heads/branch.

To create a new remote branch (on github)

1. Repeat steps 1-4 above.
2. Then, to create a new (remote) branch, type git push -u cmremote HEAD:refs/heads/new-branch-name.

This short article explains how to connect to your Android device from another computer using the SSH protocol. This allows you to use a big screen and real keyboard to work on the device. This article focuses mainly on connecting with a Linux based computer. We will be using Dropbear on the Android device as an SSH server. Dropbear is already installed in CyanogenMod. [EDIT: Cyanogenmod 9.0 RC2 no longer includes Dropbear.]

The Android terminal is a fine app, but I prefer a big screen and real keyboard any time.

Prerequisites

• CyanogenMod ≥ 5.0.6 (for dropbear & dropbear-keygen)
• An SSH client such as OpenSSH or PuTTY
• Android debug bridge tool. Please see SDK documentation for information on how to do this.
• After the SDK is installed, ensure the device is connected to the computer through USB with ADB Debugging enabled in settings.

Create a SSH key for logging in

Create an SSH key on the computer that you wish to connect to your Android device with either `ssh-keygen` or `puttygen`. The public key will copied to the Android device and the private key remains on the computer. Only computers with the private key correctly installed can login to the Android device.

In linux:

ssh-keygen -t rsa

The output should look something like this:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in <Filename>.
Your public key has been saved in <Filename>.

adb push <Filename> /sdcard/authorized_keys

In Windows:
If using puttygen, paste the string from the puttygen window (looks like “ssh-rsa AAAAB3…hclQ==rsa-key-20100227”) in authorized_keys.

(Do not try to rename the file created by puttygen – it’s format is incompatible with dropbear)

A password can be used to connect to the device, in this case you can skip the steps above.

Prepare the Android Device

On the computer, open terminal and run the following commands:

adb shell

mkdir /data/dropbear

chmod 755 /data/dropbear

mkdir /data/dropbear/.ssh

chmod 700 /data/dropbear/.ssh

mv /sdcard/authorized_keys /data/dropbear/.ssh/

chown root: /data/dropbear/.ssh/authorized_keys

chmod 600 /data/dropbear/.ssh/authorized_keys

dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key

dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

The end result should look something like this:

# ls -la /data/dropbear
drwxr-xr-x    1 root     root          2048 Sep  5 14:55 .
drwxrwx--x    1 system   system        2048 Sep  5 14:08 ..
drwx------    1 root     root          2048 Sep  5 14:51 .ssh
-rw-------    1 root     root           458 Sep  5 14:09 dropbear_dss_host_key
-rw-------    1 root     root           427 Sep  5 14:09 dropbear_rsa_host_key
# ls -la /data/dropbear/.ssh
drwx------    1 root     root          2048 Sep  5 14:51 .
drwxr-xr-x    1 root     root          2048 Sep  5 14:55 ..
-rw-------    1 root     root           406 Sep  5 14:01 authorized_keys

• Creating directories and generating rsa/dsa keys is required even if you plan to use password login.

Finding the IP address of your Android device

Now to test Dropbear, first the IP address of the Android device must be determined, so as to communicate with it. On the Android device, through either adb shell or terminal emulator, do the following.

If connected through a WiFi network, use the following:

ifconfig eth0

The result should look something like this:

eth0: ip 192.168.1.64 mask 255.255.255.0 flags [up broadcast running multicast]

If connected through a mobile network, use the following:

ifconfig rmnet0

The result should look something like this:

rmnet0: ip 200.200.200.200 mask 255.255.255.252 flags [up broadcast multicast]

You can also list all interfaces using

ip addr

NOTE: It may not be possible host services such as SSH via your mobile network.

If that doesn’t work run cat /proc/net/dev to see the possible interfaces and use ifconfig with the appropriate interface.

Testing Dropbear

We’ll run dropbear in the foreground for testing with debugging information on the Android device. The “-s” option disables password logins (SSH public key authentication is still allowed though which is what we’re using). Use either adb shell or terminal emulator to do the following.

dropbear -s -v -F

(You can use the -Y option to specify a master password for login into any account, if not using key based authentication)

The output should look something like this:

...
TRACE (3220): listening on ':22'
TRACE (3220): enter dropbear_listen
TRACE (3220): dropbear_listen: all interfaces
TRACE (3220): bind(22) failed
TRACE (3220): leave dropbear_listen: success, 1 socks bound
[3220] Sep 05 15:16:43 Not backgrounding

NOTE: For more information about dropbear, run dropbear -h.

Now, on the computer, we will try to login to the Android device. Replace the path to your SSH private key and IP address as appropriate. On the computer’s terminal, do the following.

ssh -i ./The previously selected name for this key -l root 192.168.1.64

The output should look something like this:

Enter passphrase for key '/home/user/<Filename>':
TRACE (3229): entering fake-getpwnam
TRACE (3229): leaving fake-getpwnam
TRACE (3229): enter sign_key_free
TRACE (3229): enter dsa_key_free
TRACE (3229): leave dsa_key_free
TRACE (3229): enter rsa_key_free
TRACE (3229): leave rsa_key_free
TRACE (3229): leave sign_key_free

If it didn’t run ssh with the -v option to get verbose debugging output to try and see what went wrong.

If you get authentication errors, run this to show the device’s public rsa key

dropbearkey -y -f /data/dropbear/dropbear_rsa_host_key

• the key is formatted like ‘ssh-rsa Som3Rand0mStr1n6 root@localhost’
• copy and paste it to your PCs known_hosts file, ~/.ssh/known_hosts
• and try connecting from your PC again

Assuming everything worked, dropbear can be turned off by running:

killall dropbear

NOTE: For Windows (PuTTY with SSH keyfile) you need to configure putty as follows:

• Connection » Data » Auto-login Username = root
• Connection » SSH » Auth » Private key file = Previously selected key file

Running dropbear normally

To run dropbear, from the Android device, run:

su

dropbear -s

The shell (whether or adb or terminal emulator) can now be exited safely and dropbear will continue to run.

Dropbear can be turned off by running:

killall dropbear

Automatic startup of the sshd-server on your device

To modify the file in /system/etc/ you need to remount the partition to read/write mode using

mount -o remount,rw /system

To run Dropbear on start up, edit the /etc/init.local.rc file (Your preferred editor can be used, as long as it doesn’t introduce Windows/DOS line breaks), and add the following snippet to the end of the file

# start Dropbear (ssh server) service on boot
service sshd /system/xbin/dropbear -s
   user  root
   group root
   oneshot

The `oneshot` option instructs Android that the service should not be restarted if it is killed. For a full understanding of the Android Init system see here.

Prepare the Android device (using a root password) for OLD BUILDS of CyanogenMod

NOTE: The native dropbear binary included in CyanogenMod 4.0.4 and later seems not to support correctly password protected logins in the sense that you can login even when providing a wrong password. To make it work correctly you need to compile your own dropbear binary statically linked with uClibc.

1. Compile dropbear (statically linked with uClibc)
2. Compile busybox (statically linked with uClibc) and enable
   1. Support for shadow passwords
   2. Use internal password and group functions rather than system func
   3. Use internal shadow password functions
   4. Use internal crypt functions
   5. passwd
   6. Check new passwords for weakness
3. Copy the new dropbear and busybox binaries to the device:

   adb push busybox /sdcard/busybox

   adb push dropbear /sdcard/dropbear

   adb push dropbearkey /sdcard/dropbearkey

4. Open the terminal and become superuser/root
5. Create /data/local/bin directory
6. Copy dropbear, dropbearkey and busybox to /data/local/bin and setup file permissions, ownership and links
7. Remount /system read-write
8. Create the needed passwd files
9. Change the root password
10. Create /etc/profile with a usable path
11. Create /etc/shells
12. Remount /system read-only
13. Create the dropbear directory
14. Generate rsa and dsa keys
15. Link /data/dropbear directory to /system/etc/dropbear

    su

    mkdir /data/local/bin

    cp /sdcard/busybox /data/local/bin/busybox

    cp /sdcard/dropbear /data/local/bin/dropbear

    cp /sdcard/dropbear /data/local/bin/dropbearkey

    chown root.root /data/local/bin/dropbear

    chown root.root /data/local/bin/dropbearkey

    chown root.root /data/local/bin/busybox

    chmod 4755 /data/local/bin/busybox

    chmod 755 /data/local/bin/dropbear

    chmod 755 /data/local/bin/dropbearkey

    ln -s /data/local/bin/busybox /data/local/bin/passwd

    busybox mount -o remount,rw /dev/block/mtdblock3 /system

    echo "root:x:0:0::/data/dropbear:/system/bin/sh" > /etc/passwd

    echo "root::14531:0:99999:7:::" > /etc/shadow

    echo "root:x:0:" > /etc/group

    echo "root:!::" > /etc/gshadow

    echo "/system/bin/sh" > /etc/shells

    echo "PATH=\"/usr/bin:/usr/sbin:/bin:/sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin\"" > /etc/profile

    echo "export PATH" >> /etc/profile

    /data/local/bin/passwd

    Changing password for root

    New password:

    Retype password:

    Password for root changed by root

    mkdir /data/dropbear

    /data/local/bin/dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key

    /data/local/bin/dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

    ln -s /data/dropbear /system/etc/dropbear

    busybox mount -o remount,ro /dev/block/mtdblock3 /system

16. Then as root to run the compiled version, call it with the full path:

    /data/local/bin/dropbear

See also

Link to alternative explanation: dropbear login

mkdir -p /data/ssh/empty
chmod 700 /data/ssh
chmod 700 /data/ssh/empty

cat /system/etc/ssh/sshd_config | \
sed 's/#PermitRootLogin yes$/PermitRootLogin no/' | \
sed 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/' | \
sed 's/#PasswordAuthentication yes/PasswordAuthentication no/' | \
sed 's/#PermitEmptyPasswords no/PermitEmptyPasswords no/' | \
sed 's/#ChallengeResponseAuthentication yes/ChallengeResponseAuthentication no/' | \
sed 's;/usr/libexec/sftp-server;internal-sftp;' > \
/data/ssh/sshd_config
chmod 600 /data/ssh/sshd_config

mkdir -p /data/.ssh
chmod 700 /data/.ssh
chown shell:shell /data/.ssh

adb push your_public_key /data/.ssh/authorized_keys

chmod 600 /data/.ssh/authorized_keys
chown shell:shell /data/.ssh/authorized_keys

mkdir -p /data/local/userinit.d
cat /system/bin/start-ssh | \
sed 's;/system/etc/ssh/sshd_config;/data/ssh/sshd_config;' > \
/data/local/userinit.d/99sshd
chmod 755 /data/local/userinit.d/99sshd

mkdir /data/home
chmod 755 /data/home
chown shell:shell /data/home

scp .inputrc .bash_profile .bashrc .vimrc .screenrc shell@hostname:/data/home

#!/system/xbin/bash

HOME='/data/home'
cd
exec bash --login

chmod 755 /data/home/login

W/sshd type=1400 audit(0.0:16): avc: denied { open } for name="sshd_config"

supolicy --live "allow sysinit self:capability setgid;allow sysinit system_data_file:file open;"

/system/bin/logwrapper /system/bin/sshd -f /data/ssh/sshd_config

AuthorizedKeysFile      /data/.ssh/authorized_keys.%u
PermitRootLogin yes

Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.

What is CTS

From the official documentation:

The Android compatibility program works for the benefit of the entire Android community, including users, developers, and device manufacturers.

Each group depends on the others. Users want a wide selection of devices and great apps; great apps come from developers motivated by a large market for their apps with many devices in users’ hands; device manufacturers rely on a wide variety of great apps to increase their products’ value for consumers.

The CTS is an automated testing harness that includes two major software components:

1. The CTS test harness runs on your desktop machine and manages test execution.
2. Individual test cases are executed on attached mobile devices or on an emulator. The test cases are written in Java as JUnit tests and packaged as Android .apk files to run on the actual device target.

Setup CTS

Downloads

Download and unzip the latest CTS package from Google. You will want the following:

1. Compatibility Test Suite zip
2. CTS Verifier APK
3. Media 1.0

APK Install

From extracted zip go to android-cts/repository/testcases:

adb install CtsDeviceAdmin.apk

Device Preparation

In Developer Options:

1. Enable Stay Awake
2. Enable Android Debugging
3. Enable Allow Mock Locations
4. Enable Allow Mock SMS

In Security:

1. Set Screen Lock to None
2. Tap Device Administrators – check the two check boxes for CTS (requires CtsDeviceAdmin.apk from above):

android.deviceadmin.cts.CtsDeviceAdminReceiver

android.deviceadmin.cts.CtsDeviceAdminReceiver2

• Do NOT check the 3rd box for android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver

Media Files:

In Android Media 1.0 zip run the following:

$ bash ./copy_media.sh all

• This will push all media files to the device

Additional tasks:

1. Device should have SIM card with data
2. Device should be connected to Wi-Fi
3. Install GMS packages (gapps)
4. For tests, Default the browser to Chrome (do an activity to launch the chooser, select Chrome and press Always)
   1. Go through Chrome’s brief setup
5. Do not log in to any accounts (Google, CM Account, etc)

Run CTS

In the extracted CTS zip, go to android-cts/tools and run the following command:

$ ./cts-tradefed

This opens the CTS command window. Here are useful commands:

• This runs a full CTS test pass

cts-tf> run cts --plan CTS

• To view all sessions in your /repository/results directory and number them:

cts-tf> l r

Re-run failures:

To re-run failures, create a plan based on results of a previous session:

cts-tf> add derivedplan --plan name_of_plan -s # -r fail

• the -s # is for session. Enter the number that corresponds with the session based on ‘l r’
• name_of_plan is a unique name for the plan you create – example n1_fails0411

Run a derived plan:

cts-tf> run cts --plan name_of_plan

Congratulations!

You’ve got the device, you spent weeks (months?) getting it to work. Now you want to submit your device and kernel tree back upstream to be recognized by CyanogenMod as an “official” device.

Here’s how to do it…

Prerequisites

You can save everyone a lot of time by making sure that you have met these requirements:

• Full hardware support — Everything– every peripheral, every wireless feature– that is supported by stock *must* be supported by CyanogenMod. Any exceptions will be per device (case-by-case) and must be detailed in full.
• Stability — Nothing should crash. Ever. CyanogenMod has a reputation for stability and your port must be rock-solid. This means no “sleep of deaths” either.
• No overclock by default — While overclocking options in the Performance menu is well and good, leave the default speeds at stock.
• Do not over-volt either — Do not go outside of the spec for power consumption. If you want to provide sysfs methods for upping the voltage, that’s up to you. But it must not be a default setting.
• You have designated at least one device maintainer and at least one person to be responsible for the device’s wiki information. The former will evaluate submissions to the device’s repositories. The latter will ensure that the information/documentation about the device on the wiki is always up-to-date and correct. These people must be identified when applying for official recognition.

Optional (but awesome if you have it)

• Passed the CTS — The Android Compatibility Test Suite will ensure that your port is functional.

Submitting your device

• Send an email to [email protected]
  • This email must contain links to your github repositories for your device
  • This email must contain gtalk and email addresses for contacting you
  • If a team worked on your device, all team members must be listed in the email

Once you have sent your email, expect a good amount of time to pass before a reply. This can take a couple of weeks. Your device will be reviewed. If things need to be changed, a conversation will start with you to help guide you through the process of being accepted. If your device is rejected, you will get a detailed response as to why. Not all devices will be accepted. Keep this in mind.