CyanogenMod 7.0—Gingerbread in the House
The first step to installing a custom ROM like CyanogenMod is to “root” your phone. Rooting doesn't change the way your phone behaves; instead it gives you superuser (sudo-like) access to the system. Once your phone is rooted, you can do things like install a custom ROM, overclock your CPU, set up wireless tethering (which may violate your cell-phone contract) and even do simple things that shouldn't require root, like take screenshots.
Rooting an Android phone is usually extremely simple. Typically, all it takes is a simple search on Google for the model of Android phone you have along with the word “root”. For instructions on how to root several different model phones, sites like www.droid-life.com can be helpful as well.
Remember, “rooting” your phone doesn't change very much on its own. It just gives you the ability to change things. With great power comes great responsibility, however, so be careful with your rooted phone. Just like with a desktop version of Linux, the power of root can get you into trouble!
While I explored CyanogenMod version 7, I got really excited about how quickly development in the Android world was progressing. I decided to contact Steve Kondik, CyanogenMod's creator, and ask him a few questions. (Thanks to my programmer friend Russ Ryba for helping me come up with some of the more programming-centric questions.)
SP: CyanogenMod is one of, if not the, most popular custom ROMs for Android phones. What motivated you to start the project?
SK: I've always tried to customize desktop Linux, trying to make things smoother and faster. When I learned about how the G1 worked, and that I was able to change anything I wanted, I started off with rebuilding the kernel with different tweaks. Then I realized that I could rebuild the whole system from source and flash it to the phone with everything working perfectly—that's when the doors opened up.
SP: Installing a custom ROM requires a rooted phone. Rooting your phone is something that cell-phone companies generally frown upon. Have you gotten any unfriendly correspondence from either a cell-phone provider or Google?
SK: Yeah, and it's still a gray area with regard to firmware and proprietary drivers. When CM started to get big, Google made me very aware of the line between the open-source code and the closed portions (like the Google apps, such as Gmail), so I had to stop including those. CM doesn't ship with those parts now, so we leave it in the users' hands on how to get that functionality back.
It seems like carriers and manufacturers are starting to realize that these are more than just phones, and some even are embracing the community by releasing their own code as open source. T-Mobile recently open-sourced its theme engine, which we are using in CM7. Qualcomm and TI release code for their reference boards. Now we are finally starting to see more devices that are unlockable out of the box.
SP: You support a huge number of devices; I'm curious to know how much of CyanogenMod needs to be ported specifically to an individual handset, and how much is generic across the board. Does the wide variety of devices make releases difficult?
SK: A lot of devices are similar, but there always are subtle differences. Usually it has to do with the secondary processors on these devices and offloading media encoding/decoding, or special hardware like cameras and GPS. In some cases, we've had to reverse-engineer various parts, but the major manufacturers have been providing open-source code that we can learn from or use outright, like Qualcomm's CodeAurora Project.
With CM, each device has a “maintainer”, which is one or more people who work with that specific device and handle the issues.
SP: Once a handset is rooted, is installing custom ROMs simple, or do manufacturers try to prevent you from running custom code in other ways?
SK: It depends on the device. Some are wide open, and some are “rooted” but only in userspace—nothing can be changed in the boot process so things like custom kernels can't be used easily.
SP: How does the development process work with so many different developers and different handsets? Are there any unique frustrations with working on a project like yours?
SK: Keeping device-specific changes from breaking things on other devices is the tricky part. Most of this is handled by device “overlays” that customize the build for the hardware. Android has done a good job with making most of this relatively easy with its abstraction layers, but it also evolves rapidly. The extensible parts are where vendors often add their proprietary code and Android doesn't do anything for backward compatibility. In CM, we've actually had to re-add support for some of these older drivers in order to move to newer versions of Android.
There's also the issue of the way Google does development internally. It releases the source code for new versions after doing all the development behind the doors, so when it gets into our hands, it takes a lot of time to figure out what's changed and how to re-integrate our custom features back into it.
SP: Would any of what you do be possible without the GPL requiring Google to release its source code?
SK: Android isn't GPL; it's Apache-licensed. The only code Google's required to release is the Linux kernel. But no, without the source code, the kind of things we are doing wouldn't be possible.
SP: What are your most favorite and least favorite hardware devices to work with? What makes them awesome or horrible?
SK: The Motorola devices have been the most difficult because of the huge amount of proprietary code they include, not to mention the signed bootloader. The Samsung phones also have been a challenge because they've done a lot of things differently. HTC devices are what we have the best support for, partially because they are all similar to devices that Google has worked on directly (G1, Nexus One). The HTC Evo has been my personal favorite to work on, because the hardware is unique and it was the first to include things nothing else had like dual cameras and HDMI video.
SP: How much and what kind of experience do people need to begin creating their own custom ROM?
SK: If you want to build CM yourself for a device, we provide detailed documentation. You just check out the source code and with a few simple commands, you'll have a flashable ROM. That was the goal—to ease the barrier to entry. If you have an idea for a feature, it's very easy to dive in and start coding.
SP: I'm not a programmer at all, but I love CyanogenMod, and I would like to help. How can someone like me contribute?
SK: Helping out on our forums, writing documentation and tutorials on our wiki, and telling everyone you know about it.
SP: What makes CyanogenMod different from the other custom ROMs?
SK: I can't even call it a “custom ROM” anymore; it's become more like an Android distribution. We have a whole infrastructure for submitting code and a great support network. I want it to be as easy as possible for people to get involved and add their own ideas. CM is really about the community. Although we do have a core team of developers, many of the best parts in CM just came from out of nowhere because somebody thought it would be a neat idea, and we've made it easy to run the code on your own device.
SP: Do you plan to expand CyanogenMod to tablet computers as they become more common?
SK: We're already supporting a few tablets like the Nook and Viewsonic G-Tablet. As more become available and Android 3.0 is released, you can be sure that we will be trying to make them better.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- The Secret Password Is...
- New Products
3 hours 32 min ago
- Keeping track of IP address
5 hours 23 min ago
- Roll your own dynamic dns
10 hours 37 min ago
- Please correct the URL for Salt Stack's web site
13 hours 48 min ago
- Android is Linux -- why no better inter-operation
16 hours 4 min ago
- Connecting Android device to desktop Linux via USB
16 hours 32 min ago
- Find new cell phone and tablet pc
17 hours 30 min ago
18 hours 59 min ago
- Automatically updating Guest Additions
20 hours 8 min ago
- I like your topic on android
20 hours 54 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?