Skip to main content

Developing for Android on Fedora 14 using the T-Mobile myTouch 4G - Step 1L, Setup

Back in mid-February I wrote about setting up the Android SDK to support Android development with the myTouch 4G. The Android SDK was installed on Windows XP SP3+ on my Dell Latitude D630. Since that first post, I've picked up a new Latitude E6510 with Windows 7 Enterprise 64-bit installed and the D630 has been provisioned with Fedora 14 64-bit.

When I moved up to Windows 7 I moved my Android development environment up to Windows 7. I had no problems moving from a 32-bit Windows environment to a 64-bit Windows environment that was two generations more evolved. Everything installed just fine, including the USB driver for the myTouch 4G.

With Fedora 14 installed and working to my satisfaction, I decided to see how much trouble it would be to duplicate the Android SDK work environment on Fedora, and then make some simple comparisons between the two. I also wanted to finally expel the ghost of Maemo. The development environment for Maemo was, in a word, horrible. The Android SDK (as well as Android) is light years ahead of Meamo, and it's not due to just the time between the two.

The first step is to realize that the Android SDK is 32-bit only. To run successfully on a 64-bit Fedora 14 installation I had to install these additional support packages:
  • glibc.i686 
  • glibc-devel.i686 
  • libstdc++.i686 
  • zlib-devel.i686 
  • ncurses-devel.i686 
  • libX11-devel.i686 
  • libXrender.i686 
  • libXrandr.i686
I used 'yum install ' in the grubby old command line (i.e. the terminal) to do the dirty deed.

The next step is to download the Linux version of the Android SDK and unpack it somewhere in your home directory. For the purposes of this discussion I have a top-level directory in my home named Android, under which I unpacked the SDK and placed other Android tools. So on my Fedora system I have $HOME/Android. When the Android SDK is unpacked, I have $HOME/Android/android_sdk_linux_x86.

Before you run any SDK tools, you should add the following to your environment. Since I'm a basher, all of this will be in my .bashrc:
export ANDROID_HOME=$HOME/Android/android-sdk-linux_x86
Kill the current shell and start a new one to pick up the changes to .bashrc, then run 'android' to load all the bits you'll need for development. Once that's complete, you can start ddms and start to work with your attached Android phone (or other device).

So far everything has been fairly fast and painless. Running ddms is where the slow pain starts. I noticed that when I first installed everything and started ddms that the device showed up in device pane as unknown.

When I selected the device I got a nice dump, with the cryptic message "insufficient permissions for device." A bit of search via Google, and I came across what I thought was the solution in an Ubuntu forum.

According to the forum thread I needed to create a file called 51-android.rules in /etc/udev/rules.d. I ran lsusb to get the following information (with my Android phone plugged in):

Bus 002 Device 004: ID 0bb4:0c96 High Tech Computer Corp.

I then created this one and only line in 51-android.rules:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0c96", MODE="0666"

Then, as root, I ran 'udevadm control --reload-list'

And none of that worked. I kept getting the exception. So I went back to Google and refined my search a bit and discovered this kludge in a forum devoted to Fedora. As root, I changed to the directory where adb is located (.../android-sdk-linux_x86/platform-tools) and I typed:

./adb kill-server
./adb start-server

I have a working solution for udev rules problem here. Read this later post and ignore the strike-through text above and at the end of this post.

Then as a regular user I re-ran ddms and voilà, it all worked as it should and I was able to see my Android smartphone.

Even screenshots.

I don't know what the exact problem is with USB device permissions, but the fact that, as root, I can coerce adb to handle it properly by restarting adb in this manner is A Clue. Once adb is restarted I can plug and unplug the smartphone until I shut down the notebook. And the Android smartphone doesn't have to be plugged in for this kludge to work.

In the mean time I have other fish to fry. I will eventually discover a more elegant and complete solution (or maybe I'll get lucky and somebody will tell me). In the mean time I have a 90% solution with a simple kludge that allows me to do a bit of Android development on Fedora.


Popular posts from this blog

cat-in-a-box channels greta garbo

So I'm sitting at my computer, when I start to notice a racket in back. I ignore it for a while until I hear a load "thump!", as if something had been dropped on the floor, followed by a lot of loud rattling. I turn around and see Lucy in the box just having a grand old time, rolling around and rattling that box a good one. I grab the GX1 and snap a few shots before she notices me and the camera, then leaps out and back into her chair (which used to be my chair before she decided it was her chair).

Just like caring for Katie my black Lab taught me about dogs, caring for Lucy is teaching me about cats. She finds me fascinating, as I do her. And she expresses great affection and love toward me without coaxing. I try to return the affection and love, but she is a cat, and she takes a bat at me on occasion, although I think that's just her being playful. She always has her claws in when she does that.

She sits next to me during the evening in her chair while I sit in mi…

vm networking problem fixed

Over the weekend I upgraded to Windows 8.1, then discovered that networking for the virtual machines wouldn't work. Then I tried something incredibly simple and fixed the problem.

Checking the system I noticed that three VMware Windows services weren't running; VMnetDHCP, VMUSBArbService, and VMwareNatService. VMware Player allows you to install, remove, or fix an existing installation. I chose to try fixing the installation, and that fixed the problem. The services were re-installed/restarted, and the virtual machines had networking again.

Once network connectivity was established there was exactly one updated file for Ubuntu 13.10, a data file. This underscores how solid and finished the release was this time. Every other version of every other Linux installation I've ever dealt with has always been succeeded by boatloads of updates after the initial installation. But not this time.

Everything is working properly on my notebook. All's right with the world.

sony's pivotal mirrorless move

I'm a died-in-the-wool technologist, even when it comes to photography. I have always been fascinated with the technology that goes into manufacturing any camera, from the lenses (optics) through the mechanical construction, the electronics involved, and especially the chemistry of the film and the sophistication of the digital sensor. It's amazing that the camera can do all it's asked of it, regardless of manufacturer.

Of all the types of cameras that I've really taken an interest in, contemporary mirrorless (again, regardless of manufacturer) are the most interesting because of the challenging problems the scientists and engineers have had to solve in order to build a compact but highly functional camera. In particular I've followed the sensor advances over the years and watched image quality climb (especially with μ4:3rds) to exceed film and rival one another such that there's very little difference any more as you move from the smaller sensors such as 4:3r…