I go out for beer and supper with my pal, Jim Flanagan, and use what I've learned to explain why his attempt to put a random Java app onto his girlfriend's Android phone failed.
Teaching someone else what I know is a good way to review and uncover what I don't really understand well enough to explain.
"You thought I wanted to put a Java app onto Marcia's phone?" Jim has no idea what I'm talking about.
He has, he explains, read that he can use SL4A and JRuby to run Ruby programs on Android devices. Marcia has an Android phone, and he knows Ruby. A natural match.
He doesn't understand what SL4A is or why it would need JRuby, or, for that matter, even what Sinatra is, which is also required, "... But maybe you do."
Well, no, but at least this time I've paid close enough attention to know what the question is. I've heard of JRuby and Sinatra. SL4A? Nope, but it's "Scripting Layer For Android."
Jim says that the place he found this information has an example -- only a few lines of code -- that turn an Android phone into a spy camera. He could install it on Marcia's camera and spy on her from his laptop. Of course, he could just go over and see her whenever he wants, but okay, we're guys, so spy camera is enough to make this compelling.
After supper, we head back over to Caffe Sole, where they now have a band playing live, bad, jazz.
He shows me the code and yes, just a handful of lines of Ruby, running on the phone, are claimed to tell the camera to take a picture, and then serve the picture up over the internet, on Webrick's port 4567. (Webrick is Ruby's built-in, light-weight web server).
Browsing to that port at the phone's IP address, from any browser, should show the picture. Somehow, the code also lets the laptop instruct the phone when to take pictures.
Only one way to find out.
I google for SL4A from my phone, and install it from Google Code. SL4A, in turn, lets me install JRuby. The code samples that come with that installation work indifferently. The "Hello, World" app works okay, the app to toggle airplane mode seems to work once, but we can't repeat that.
But who cares about airplane mode if we can have a Spy Camera?
I connect the phone to his Mac with a USB cable, and the phone asks me if I want to allow him to "Download files via USB."
Well, sure.
After some trial and error, we download the spy-camera app and and associated directory, uh, folder, I poke around, turn on the phone's WiFi, and figure out the phone's IP address: 192.168.1.8. Jim browses to it to 192.168.1.8:4567. The phone's camera makes a loud shutter click.
Actually, that's just Android generating a "shutter-click sound" electronically, since the camera shutter is also entirely electronic, but we'll take it. Houston, we have ignition.
After a couple second or two, a picture appears on Jim's browser. It's almost black. The coffee shop is dark and the pictures are darker. We try a few more. I finally realize I'm trying to take a picture with the phone's rear-facing camera, but it doesn't have one.
I turn the phone around.
I try to take a picture of the woman sitting next to Jim. She says, "Why do you want to take my picture?" turns her head away, and puts up her hand. I bet real spies never have this sort of problem.
I go over to the counter, where the light's better, and take a picture of Katie, the barista. It works! We show her on the laptop. It's sideways, but she's still still pleased.
So are we. We leave the coffee shop in triumph.
Thursday, December 27, 2012
The Application Lifecycle and Its Dual
Building an app was fun, so let's look at the next tutorial, on lifecycles. Maybe it'll modify the app I have to help me understand Karim's slide 46.
Slide 46 is the dual of the pyramid graphic, in the tutorial, which shows the states as nodes, with the functions that move between them as edges. Slide 46, in contrast, has the functions as nodes, and the states as edges.
Either way, I need to learn the states and how activities move among them.
Reading through the general description, I look back at my sources and find both of my activities have an OnCreate(), but none of the other functions. I wonder where those are.
Another mystery is the difference among what look like almost identical things, such as Paused and Stopped. "Paused" means "partially obscured," but when does that ever happen? Apps always take up the whole screen, right?
The next step in the tutorial answers that one, right away! A popup, such as a dialogue box, partially obscures, so it pauses the app.
The rest of the tutorial talks in generalities. There are code snippets, but there's no real exercise.
Bummer.
I Can Install Apps Via Email
I'm on a roll now.
If I understand what I've read, I should be able to install apps by emailing them to myself.
I attach the apk to a mail message, install it on my tablet (which asks me if I want to "install an update"), put the icon on the home screen, and take it over to Katie, behind the counter.
"Press this," I say. She presses the clock in the center of the screen.
I bring back the home screen, point to the little, green, Android icon, labelled MyFirstApp, and say, "No, the green thing."
She presses it, the app comes up, she reads it, and asks, "What's a 'string' ?"
Typical demo.
If I understand what I've read, I should be able to install apps by emailing them to myself.
- I disconnect the phone and uninstall the app.
- On my netbook, I attach the .apk file to a gmail message and email it to myself.
- I pick up my phone, go to my Gmail, and there's the message. I click on the attachment.
- The phone asks me if I want to install the .apk. Yes, I do.
- The app installs, I open it. It works!
There's an icon for it in my list of apps. It's really installed.
Oho. This trick should work for any Android device.
I pull out my Nexus 7 tablet. Look ma, no cables.
I know that it will install non-Play apps, because I have some from the Amazon store.
On the tablet, I go to Gmail, the message is still there, in my inbox, albeit read. Again, I click on the attachment. Again, the app installs and works. There's an icon for it in my list of apps, so it's really installed.
Yesterday, Katie, the Caffe Sole barista, pointed at my Beagleboard and said, "What's that? An external hard drive?"
I said, "No, it's an external computer." I showed her the Android GUI, and explained that she was seeing a "Desktop" on a completely separate computer.
"That totally rocks!" she said.
I go back to my app and change the strings (res/values/strings.xml) so that instead of saying, "Enter a string." it says "Enter Katie\'s string." Eclipse explains that I need to escape the single quote.
I also change the second activity, which displays the string I enter after I press the Send button, (To do this, I have to look up how to append to a string in Java, and hope that the code in the second activity is handling multi-line strings, but that makes it a good experiment.)
I can't figure out how to rebuild the .apk, so I go back, use the AVD manager to create and bring up an emulator, and click "Run" to get it onto the emulator. This both verifies that my changes worked, and rebuilds the apk.
I attach the apk to a mail message, install it on my tablet (which asks me if I want to "install an update"), put the icon on the home screen, and take it over to Katie, behind the counter.
"Press this," I say. She presses the clock in the center of the screen.
I bring back the home screen, point to the little, green, Android icon, labelled MyFirstApp, and say, "No, the green thing."
She presses it, the app comes up, she reads it, and asks, "What's a 'string' ?"
Typical demo.
I Pour the App I Built onto My Own, Android Phone
Yesterday, I built an app that runs on my Beagleboard. I should be able to put the same app onto my phone, right? Yes, this is a sidebar, but I have to know.
First step: My computer needs to be able to talk to the phone when I plug it in. It needs to recognize my phone as a legitimate peripheral.
This should just take an addition to my udev rules.
I hunt for the right udev settings for the phone -- a two-and-a-half year old HTC magic. This table reminds me that I can use per-vendor settings, so I add a line to /etc/udev/rules.d/51-android.rules:
Next, I look on my phone to see what version of Android it's running. I remember that when setting up the Eclipse project, I specified a minimum Android version the app would run on. I'd better check what version the phone has.
Menu->Settings->About Phone->Android version, tells me it's running 2.2.3 (Froyo).
Unfortunately, I don't remember what I said at setup (I bet I just took defaults), and it isn't obvious to me how to get back to that page. Googling tells me the information's in AndriodManifest.xml, so I look there and it says
This page tells me that 2.2.3 is SDK API version 8. Whew.
Plugging in the phone and permitting USB debugging (Applications->Development->USB debugging) makes /dev/sdc and /dev/sg2 appear, though nothing's mounted.
I bring up eclipse, pick MyAndroidProject, and press Run. The Choose a running Android device screen pops up and, sure enough, there's htc_t-mobile-mytouch-3g!
Crossing my fingers, I click on OK, and ... there it is. MyFirstApp appears on the phone, and behaves just as it did on the Beagleboard. There's even an icon for it in the list of apps. How cool is that?
First step: My computer needs to be able to talk to the phone when I plug it in. It needs to recognize my phone as a legitimate peripheral.
This should just take an addition to my udev rules.
I hunt for the right udev settings for the phone -- a two-and-a-half year old HTC magic. This table reminds me that I can use per-vendor settings, so I add a line to /etc/udev/rules.d/51-android.rules:
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"and run
sudo udevadm control --reload-rulesto get udev to re-read it.
Next, I look on my phone to see what version of Android it's running. I remember that when setting up the Eclipse project, I specified a minimum Android version the app would run on. I'd better check what version the phone has.
Menu->Settings->About Phone->Android version, tells me it's running 2.2.3 (Froyo).
Unfortunately, I don't remember what I said at setup (I bet I just took defaults), and it isn't obvious to me how to get back to that page. Googling tells me the information's in AndriodManifest.xml, so I look there and it says
android:minSdkVersion="8"
Great. I don't know which Android that is yet.
This page tells me that 2.2.3 is SDK API version 8. Whew.
Plugging in the phone and permitting USB debugging (Applications->Development->USB debugging) makes /dev/sdc and /dev/sg2 appear, though nothing's mounted.
I bring up eclipse, pick MyAndroidProject, and press Run. The Choose a running Android device screen pops up and, sure enough, there's htc_t-mobile-mytouch-3g!
Crossing my fingers, I click on OK, and ... there it is. MyFirstApp appears on the phone, and behaves just as it did on the Beagleboard. There's even an icon for it in the list of apps. How cool is that?
Wednesday, December 26, 2012
The Build Succeeds! Plus, I Now Have Timing Info
Having modified the makefiles to do a 32-bit build, it finally completes.
Eventually, with the modifications described earlier, the build succeeds.
How long has all this taken my little netbook? Here are the times for the two tries: the first failure, followed by the second success.
build-android.OUT:[ 11:29:21 ] : == ./build-android: BEGIN
build-android.OUT:[ 12:06:16 ] : == ./build-android: FAIL
build-android.OUT2:[ 12:36:49 ] : == ./build-android: BEGIN
build-android.OUT2:[ 18:01:25 ] : == ./build-android: SUCCESS
Started before lunchls, ended after supper.
How about once it's already built? How long does a no-op rebuild take?
[ 19:33:42 ] : == ./build-android: BEGIN
[ 19:38:18 ] : == ./build-android: SUCCESS
Three minutes. Not instant, but not bad.
How about a more interesting test? I'll clean it, then build using the cache.
[ 20:04:01 ] : == ./build-android: BEGIN
[ 22:49:13 ] : == ./build-android: SUCCESS
Two-and-three-quarters hours. Certainly much faster than a build from scratch.
Wait. "Cache"? What's this "cache"?
While Waiting on the Build, I Write an App
The build's slow, but chugging away steadily, so it's back to looking through the slides with google-mediated side-trips.
I finally finish the introductory material, about things like licenses and lawsuits, and get to section 1: "Android Internals"
At some point, perhaps the mention of Views and Viewgroups in slide 53, I wind up in the training tab of developer.android.com and think, "Oh, what the heck," so I set out to build their "My First Android App."
It's pretty fun, makes me use Eclipse and Java, neither of which I'm comfy with, but they're already installed, so it's another "opportunity for growth."
Sure enough, after following instructions, I end up with a two-activity application running on the Beaglebone. Now that's cool.
I also confirm that a real mouse, plugged into my host, actually lets me scroll around on the VNC'd Android GUI. Phew. If I still couldn't do that, I'd be in trouble.
The next step in their training is managing the app lifecycle, which meshes perfectly with slide 46. I could also try getting the app onto my cell phone. Plenty of directions to go.
Right now, though, I have to pack up and go home, with a stop at King Soops along the way, so I can pick up a cake for tonight's Wednesday night jam.
The build's still chugging away; I'll just let it run in the back seat of my car while I'm shopping.
I finally finish the introductory material, about things like licenses and lawsuits, and get to section 1: "Android Internals"
At some point, perhaps the mention of Views and Viewgroups in slide 53, I wind up in the training tab of developer.android.com and think, "Oh, what the heck," so I set out to build their "My First Android App."
It's pretty fun, makes me use Eclipse and Java, neither of which I'm comfy with, but they're already installed, so it's another "opportunity for growth."
Sure enough, after following instructions, I end up with a two-activity application running on the Beaglebone. Now that's cool.
I also confirm that a real mouse, plugged into my host, actually lets me scroll around on the VNC'd Android GUI. Phew. If I still couldn't do that, I'd be in trouble.
The next step in their training is managing the app lifecycle, which meshes perfectly with slide 46. I could also try getting the app onto my cell phone. Plenty of directions to go.
Right now, though, I have to pack up and go home, with a stop at King Soops along the way, so I can pick up a cake for tonight's Wednesday night jam.
The build's still chugging away; I'll just let it run in the back seat of my car while I'm shopping.
The Sources Need Minor Tweaks for a 32-Bit Build.
Final preps concluded, I guess I'm finally ready to try the big Android build on my little machine. Sadly, when I do it, it fails after half an hour.
frameworks/base/libs/utils/RefBase.cpp:483:67: error: passing ‘const android::RefBase::weakref_impl’ as ‘this’ argument of ‘void android::RefBase::weakref_impl::trackMe(bool, bool)’ discards qualifiers [-fpermissive]
make: *** [out/host/linux-x86/obj/STATIC_LIBRARIES/libutils_intermediates/RefBase.o] Error 1
Googling a bit, I wind up at "You can't build from Gingerbread forward with a 32-bit machine." Which is what I have.
Harumph.
Well, perhaps I'm not the first person to face this. Another google shows I'm not, and there's ways past this.
The post lists three sets of changes I need to make to build files in the system to permit a build on a 32-bit host. TI seems already to have made he first. I'll make the other two and try again.
My Little Computer
The timing info says I can only really run a couple of jobs at once? How wimpy is this computer, anyway?
Quite.
My workhorse, home laptop is a Dell Inspiron 1012 netbook. It's cheap, and easy to toss in a backpack. I keep it next to the bed and am typing this on it. It has, however, one, 600Mhz, single-core, Atom processor.. The OS is 32-bit Ubuntu 12.04. It came with 1G of memory, but my girlfriend , Kristina, put in a second gig, so that's a small mercy.
All this info is available from specsheets on the web, or by just looking in /proc/cpuinfo and /proc/meminfo/
In other words, if I can build on this, I can build on anything.
Quite.
My workhorse, home laptop is a Dell Inspiron 1012 netbook. It's cheap, and easy to toss in a backpack. I keep it next to the bed and am typing this on it. It has, however, one, 600Mhz, single-core, Atom processor.. The OS is 32-bit Ubuntu 12.04. It came with 1G of memory, but my girlfriend , Kristina, put in a second gig, so that's a small mercy.
All this info is available from specsheets on the web, or by just looking in /proc/cpuinfo and /proc/meminfo/
In other words, if I can build on this, I can build on anything.
How Many Parallel-Make Jobs Should I Use?
Before I start a really large build, collecting some more timing info seems worth a moment's work.
GNU make lets me do parallel builds, with make -j <Njobs>, so I'd like to know how big to make Njobs on my netbook. Too few, and I'm not taking advantage of the feature. Too many, and I may end up thrashing.
Building the bootloader's pretty fast, so I'll instrument just that build and run it with different "j" values.
== 1 ==
[ 10:56:14 ] : == ./time-parallel-bootloader-builds: BEGIN
[ 10:59:38 ] : == ./time-parallel-bootloader-builds: SUCCESS
== 2 ==
[ 10:38:28 ] : == ./time-parallel-bootloader-builds: BEGIN
[ 10:41:02 ] : == ./time-parallel-bootloader-builds: SUCCESS
== 3 ==
[ 10:41:02 ] : == ./time-parallel-bootloader-builds: BEGIN
[ 10:43:34 ] : == ./time-parallel-bootloader-builds: SUCCESS
== 4 ==
[ 10:43:34 ] : == ./time-parallel-bootloader-builds: BEGIN
[ 10:46:06 ] : == ./time-parallel-bootloader-builds: SUCCESS
Looks like make -j2 is the winner -- it's better than make -j1, and no worse than make -j3. (I even re-ran make -j1, just to make sure it wasn't slower because the filesystem cache hadn't been loaded up with the bootloader sources.)
Tuesday, December 25, 2012
Why "Bootloaders," Plural?
I mention "bootloaders," plural. Why more than one?
Let's contrast booting an Intel PC with booting an embedded system, which, typically, has some other, lower-power-requirement chip set.
In very coarse outline, when you start up an Intel PC,
Other systems are roughly the same, but the division of labor for the first steps changes. On Intel boxes, the BIOS can be pretty smart, and the bootloader pretty dumb, because the BIOS knows it's running on a well-standardized Intel platform.
Other embedded devices are more varied, so the bootloader needs to be smarter and more flexible. For Android, as for many other embedded systems, the bootloader of choice is Wolfgang Denk's powerful Das U-Boot. The problem that it faces, however, is that its sophistication and ability to run on many chipsets and boot many operating systems requires a lot of code. U-boot is so big that it can't fit into the boot ROM of typical TI chips. For these chipsets (like the one on the Beaglebone, or in the OMAP-based smartphone from aircell), u-boot is a second-stage bootloader, which is started by an earlier, first-stage bootloader, called x-loader or omap (and no, I don't yet know why it has two names).
The x-loader is a chopped-down version of u-boot, small enough to fit in the TI boot ROM, and that knows just enough about the TI architecture to be able to bring up u-boot.
Let's contrast booting an Intel PC with booting an embedded system, which, typically, has some other, lower-power-requirement chip set.
In very coarse outline, when you start up an Intel PC,
- the hardware jumps to a certain location in memory
- that location says "run the BIOS"
- the BIOS says "run the bootloader"
- the bootloader says "bring up the OS."
If it were a car, the BIOS would be the ignition, the bootloader would be the starter motor, and the OS would be the engine. Just as the starter motor is an engine, the bootloader is an OS -- it's just a very simple OS which knows only enough to bring up the "real" OS.
- The BIOS isn't very powerful, but knows some basic things about the Intel architecture.
- The bootloader is more powerful than the BIOS, and knows enough to load the operating system into memory including enough of a faked-up filesystem and drivers to let the OS start up.
- The OS is then up far enough that it can take over and start everything else.
Other systems are roughly the same, but the division of labor for the first steps changes. On Intel boxes, the BIOS can be pretty smart, and the bootloader pretty dumb, because the BIOS knows it's running on a well-standardized Intel platform.
Other embedded devices are more varied, so the bootloader needs to be smarter and more flexible. For Android, as for many other embedded systems, the bootloader of choice is Wolfgang Denk's powerful Das U-Boot. The problem that it faces, however, is that its sophistication and ability to run on many chipsets and boot many operating systems requires a lot of code. U-boot is so big that it can't fit into the boot ROM of typical TI chips. For these chipsets (like the one on the Beaglebone, or in the OMAP-based smartphone from aircell), u-boot is a second-stage bootloader, which is started by an earlier, first-stage bootloader, called x-loader or omap (and no, I don't yet know why it has two names).
The x-loader is a chopped-down version of u-boot, small enough to fit in the TI boot ROM, and that knows just enough about the TI architecture to be able to bring up u-boot.
Monday, December 24, 2012
First Build Steps: the Bootloaders and the Kernel
Okay, now that I have the sources, it's time to try some builds from them.
First, I'll do the bootloaders and the kernel because they're self-contained and have their own special instructions. If I'm going to fail, I want to fail fast. I use TI's directions for both the bootloaders, and
the kernel.
I'll stash the script I used for these two steps here.
I'd like to know how long each step takes, so I've instrumented the script with timing info. Doing this is a good excuse to use a couple of tricks.
Trick 1
To capture the info, I use set -x, which echoes each command as it's executed, and then set $PS4, the prompt issued before those echoes, to print the time.
PS4='[ $(date +%T) ] 'set -xThis time-stamps every command in the script as it's run.
Trick 2
I'd also like to mark off bigger blocks, so I can see when major sections and subsections start. For this, I use another trick -- the colon command.
':' is a real command -- a no-op. In really old Unixes, ':' was in /bin, but today it's a shell built-in. It has a variety of uses, but in this case, I just use it to mark off big chunks, like this:
: == Name of ChunkPaired with trick 1, from above, when the shell sees this command, it time-stamps it, then echoes it, like this.
[ 12:04:00 ] : == Name of ChunkI capture the output, I can find the chunks with this command:
grep '==' /tmp/build-bootloader-and-kernel.OUTI use a pair of equals signs because they don't occur in most shell commands. Subsections get four equals signs, sub-sub-sections, six, and so on. The grep, above, finds all these.
How long dose building this pair of pieces take? Three minutes for the bootloaders, twenty minutes for the kernel. Voila!
[ 17:51:39 ] : == ./build-bootloader-and-kernel: BEGIN[ 17:51:39 ] : ==== Build u-boot[ 17:54:18 ] : ==== Build the kernel[ 18:15:35 ] : == ./build-bootloader-and-kernel: SUCCESS
Dalvik: Not Your Father's JVM
Waiting for the last download to finish seemed like a good time to peruse more overheads.
Overhead 39 is a nice diagram of how Java files turn into apps. My pal, Jim Flanagan, made a jar in a conventional Java environment and downloaded it to his girlfriend, Marcia's phone, but it wouldn't just run.
Well, yes.
The "getting it onto his girlfriend's phone" part would just require attaching it to an email, but this shows why getting it to run is another story.
Android uses Java, and heavily, but the Java Runtime Environment (JRE) doesn't look anything like Sun's. (Yeah, yeah "... Oracle's.") Android's Java virtual machine (JVM), Dalvik, runs "dex" files (Dalvik EXecutables?) instead of "jar" files.
Plus, of course, they need to be signed and aligned.
Once I have all this internalized, I'll be able to show Jim how to build a dexfile that will run on her phone. I'll drive off that bridge when I come to it.
Why "Dalvik"? According to Wikipedia, it's named after an Icelandic fishing village.
TI Supplies the Gingerbread Source
Gingerbread (2.3) is a nice starting point. I lot of products still use 2.3, and it's smaller and more manageable than something like Jellybean (4.2). the current top-of-the-line version.
TI offers a 2.3.4 source tarball for the Beaglebone, which is a hefty, 2.6G and takes me an hour and a half to download. Once done, though, I simply untar them, cd into the directory, and see ...
a single README.txt file.
A du -sh of the directory says it's 2.7G, so either the README file is huge or there's something else going on.
Well, sure enough, ls -al reveals a .repo/ directory, and the README says this:
The .repo/ directory is a directory full of git repositories and associated metadata for the repo command, a Python program layered on top of git that manipulates a suite of repositories. Looks like instead of simply adding a new command to the git suite, Google decided to build another command that has a whole, new set of options with completely different names. For example, instead of git repos pull or even repo pull, it's repo sync.
Idiots.
There's a lot of stuff in the repo directory, so while that's happening I'll look at the man page for the repo command, which is a layer on top of git, to see what it says about "--local-only".
Aha. --local-only just updates the working tree from the local repositories, and doesn't fetch anything from the remotes. Just like it sounds, at least. It's git checkout for repos.
Well, that sync wasn't as bad as I feared. It only took five-and-a-half minutes to check out the code. Good!
As always, here's a script.
TI offers a 2.3.4 source tarball for the Beaglebone, which is a hefty, 2.6G and takes me an hour and a half to download. Once done, though, I simply untar them, cd into the directory, and see ...
a single README.txt file.
A du -sh of the directory says it's 2.7G, so either the README file is huge or there's something else going on.
Well, sure enough, ls -al reveals a .repo/ directory, and the README says this:
Sources are contained in the form of pre-packaged repo.Please use below command to populate sources.Fine, then, let's give it a shot.
$ ./.repo/repo/repo sync --local-only
The .repo/ directory is a directory full of git repositories and associated metadata for the repo command, a Python program layered on top of git that manipulates a suite of repositories. Looks like instead of simply adding a new command to the git suite, Google decided to build another command that has a whole, new set of options with completely different names. For example, instead of git repos pull or even repo pull, it's repo sync.
Idiots.
There's a lot of stuff in the repo directory, so while that's happening I'll look at the man page for the repo command, which is a layer on top of git, to see what it says about "--local-only".
Aha. --local-only just updates the working tree from the local repositories, and doesn't fetch anything from the remotes. Just like it sounds, at least. It's git checkout for repos.
Well, that sync wasn't as bad as I feared. It only took five-and-a-half minutes to check out the code. Good!
As always, here's a script.
I Can Host My Own Appstore. Google Can, Too.
Anyone can host an app store, not just Google. Me, for example. All I have to do, roughly speaking, is put up a website and let people upload apps to it that other folks can download.
(In fact, it looks like all I have to do to put an app on an Android phone is email it to the phone's owner. The phone is set up to recognize a correctly built and formatted app and install it.)
"Stores" add bells and whistles, like nice GUIs, search functions, ratings, ability to buy and sell, and so on, but their essence is only that -- a web site with a bunch of apps to download.
Google's app store (this week, called "Google Play") adds some security. Google claims that they screen for malware, in some way, so downloading apps from it is safer. Indeed, downloading from any other store typically requires changing a phone's settings to permit "unsafe" downloads.
Still, there are lots of stores out there. Me, I've used Amazon's -- free Angry Birds! -- but there are lots of smaller players, too. Here's a review of some, a few of which have already gone under.
The problem, as you'd guess, is that there's little motivation to provide apps through alternative stores. Everyone knows Google and Amazon. It's not like the sites can offer more convenience, like a neigborhood shop or corner grocery, either. Google's just as accessible as anything else. Better service? You click. It's done.
What's left? One market advantage for a smaller store is specialization. Here's a site that caters to people who want apps for e-book readers. Google Play has some broad categories and search (imagine that), but when you actually try searching, you quickly realize that it would be nice to have an app store that specifically catered to, say, language-learning apps, or pet apps, or ....
Another nich for small stores is the restricted-access store. A store specifically for JBC-P apps is a perfect example. The Marine Corps doesn't want just anybody to have access to battlefield apps, much less the ability to upload things that Marines can download onto their JBC-P devices.
My employer, Aircell, has talked about hosting a limited set of apps for the Aircell Smart Phone, which it would approve for use on airplanes. (There are FAA and FCC certification issues involved.) Aircell could do the work to set up its own, but may not need to. Google just announced that it will host "private" stores. Such a store would let Aircell leverage Google's UI, their hosting experience, and their security features.
I like it.
Sunday, December 23, 2012
Who's Using Android?
When I tell my friends I took an embedded-Android course, they say, "Isn't all Android 'embedded'?"
Well, yeah. But it started out as a phone OS, and the title emphasizes the fact that it's moving off into other embedded systems, like tablets, ebook-readers, washing machines, ....
Karim's slide 23 lists some manufacturers using Android. Now that I'm reading them at leisure, I'm poking around and learning things I didn't know.
That Barnes-and-Noble Nook color that I re-flashed to run Cyanogenmod? It was already running Android -- just not one that was very accessible.
But the coolest Android platform today? It has to be the Joint Battlefield Command-Platform (JBC-P/JBC-P2).
The US military ("joint") is turning out a slew of devices, running Android, that do things you'd want to be able to do in the field, like letting everyone else in your unit see your position using GPS.
The article points out that this has many side benefits, which include letting our armed forces field their own app stores for military apps, and letting them create equipment that requires almost no training, because they have the same basic UI's as civilian devices.
This choice of Android, instead of iOS, for the platform base is an historical echo: it mirrors the DoD's choice of Unix over VMS in the early 80's.
The argument then was that even though the DoD was buying VAXs as fast as Digital Equipment Corporation could sell them, there might come a day when DEC was no longer the top gun. Unix offered robustness: it could run on VAXen, but it could run on other manufacturer's hardware, too. That's important to the DoD.
Remember Digital Equipment Corporation?
JTAG? Really? I Have JTAG?
Karim's slide 13 says that the Beaglebone has "Single-cable USB/Serial/JTAG."
I've seen the USB cable supply power and serial, but JTAG? Hmm. I really know nothing about JTAG, but I think of it as a low-level, run-time, debugging tool that requires a special connector, special tools on the host end, and a EE degree to use it.
A quick google for "JTAG beaglebone" lands me here.
Yes, it really does let me do JTAG! Looks like TI has a free tool, Code Composer Studio, that's an Eclipse plugin to do JTAG stuff. On the Beaglebone, it can do all the relevant work over the power/serial cable. Whatever that work may be.
There's lots of stuff here to explore, eventually.
I Start Through Karim's Slides
Might as well start going back through Karim's slides. There are 350, so to do them in a week means 70 a day. We did that in his class, but I won't do that now, even though I've been through them once.
I want to stop and think about everything.
The first thing I hit of interest are three sites he recommends as references: {source,developer,tools}.android.com. This seems like a good time to browse through them, learn which is good for what, and internalize that.
source.android.com starts with this:
Here you can find the information and source code you need to build an
Android-compatible device.
The first two links on the page are for companies (the docs that set out the rules for what companies should do to create Android devices) and tips for developers on how to get involved. One link
talks about setting up a dev environment, including how to do it on Ubuntu 12.04, the Long-Term Stable (LTS) release I'm running, so I'll grab the packages it recommends.
Here's the script.
The next one's developer.android.com, which looks to be for app developers. Though that's not what I'm trying to do, lots of this stuff is interesting and some of it is going to be essential knowledge. For example, I've been mystified by "signing," which is explained clearly enough here.
Google encourages me to sign apps with certificates that will be good for at least 25 years, to allow for updates. (Updates need to have matching certs.) This tells me I'm in the wrong game.
First, I doubt anyone will be using any app I'd write in 25 years. 25 years ago was 1988. I doubt I could even have imagined smartphones, and I'm not likely to be able to imagine what we'll have in 25 years. (Unless, of course the government finally successfully regulates the internet, in which case, we'll be internetting like it's 1988 and have to go back to using land-lines.)
Second, I'm likely to be dead. I'm 64 and can't think of any male in my family who's lived to be 90.
The third is tools.android.com. This is info on the Android Developer Toolkit (ADT), such as the Android Virtual Device (AVD) Manager and the Software Development Kit (SDK).
An hour's browsing through these, learning acronyms and buzzwords, and shoring up the sides of my mental boxes seems like time well spent.
Navigating the VNC GUI With a Trackpad's Hard
I just spent way too much time trying to navigate the Android GUI through VNC.
Basically, it sucks. It's so unresponsive and so easily confused that the whole experience is completely frustrating. Here, in theory, are instructions. I can't make the keystrokes work.
I'm trying to do this through my netbook's trackpad. I could try plugging a mouse into the remaining USB port, but wait ...
The same instructions say that the USB port on the board works if something's plugged into it at boot time. Yow. That would actually give me a mouse running on the target.
I borrowed a mouse from the guy sitting next to me in the coffee shop, and tried it. Yep. It works. Unfortunately, it's very jerky and I still can't figure out how to scroll.
Maybe with my own mouse it'll work better. I'll try tomorrow.
Maybe with my own mouse it'll work better. I'll try tomorrow.
Adb Is the Swiss-Army Knife of Android Development
Okay, I've now been shoved onto two projects with very tight deadlines, so I haven't had a chance to learn anything, even at lunch.
This is bad. "I'm too busy sawing to sharpen the saw."
I'm on Christmas vacation -- which I had to take or lose it -- so I can pause between obligations daily, go to a coffee shop, and exercise my brain.
I'll try shaking off some rust, and take a little closer look at adb.
What do I know?
- adb shell gets me into the box over the serial line,
- adb kill-server gets me out of situations where the adb server is confused,
- adb logcat dumps out logs,
but there's more to it, so I'll read the man page and do some experiments to firm up my mental model.
The host adb client talks to the target adb daemon (adbd), therough the host adb server.
If no server is running, any use of adb creates a new one. I can convince myself like this:
$ adb kill-server # kill any server that might be running
$ ps ajax | grep [a]db # no output
$ adb shell ps | grep adbd # daemon running on the target
root 67 1 3416 172 ffffffff 00008294 S /sbin/adbd
$ ps ajax | grep [a]db # 'adb shell' started a new host server
1 7161 7158 3629 pts/4 7201 Sl 1000 0:00 adb fork-server server
$ adb kill-server # kill host server again
$ ps ajax | grep [a]db # no output
$ adb shell ps | grep adbd # target daemon target still running
root 67 1 3416 172 ffffffff 00008294 S /sbin/adbd
$ adb kill-server # but now there's a new server, again started by 'adb shell'
1 7240 7237 3629 pts/4 7249 Sl 1000 0:00 adb fork-server server
adb shell creates a new shell on the target, launched by adbd, and talks to it over port 5037.
A quick peek at the help (adb --help) shows many other sub-commands.
- adb forward does port forwarding
- adb backup dumps over 10,000 lines of info
- adb push pushes files to the device
- adb pull pulls them off
What would you pay? But wait. There's more.
- adb get-serialno prints the device name, "0123456789ABCDEF"
- adb get-state prints "device"
- adb get-devpath prints "usb:1-1.2"
- adb devices -l gives all of these, together
List of devices attached
0123456789ABCDEF device usb:1-1.2
It's also a monitoring and exploration tool. adb status-window prints "device", switches to "unknown" when I unplug it, then back to "device" when I plug it back in.
If I reboot, the switch to "device" is coincident with the announcement by Network Manager that the connection has been established.
"Established" doesn't mean the device is pingable. For that, I need to bring the network up. Again, the tool is adb.
I could do what I want by connecting to the target, with adb shell, then executing commands.
I could also create a script and push it over with adb push, and modify the remote startup files to execute it at board bring-up.
But adb shell [cmd] lets me do it all on the host, like this:
$ adb shell 'netcfg eth0 up'$ adb shell 'ifconfig eth0 192.168.1.1 netmask 255.255.255.0'and now I can ping 192.168.1.1!
Similarly,
$ adb shell androidvncserver &> /tmp/androidvncserver.log &brings up the remote vncserver and lets me connect to it from my VNC client on the host.
Note that the command, above, puts the job in the background on the host. I can't yet figure out how to bring up this job from the host so it's running in the background on the target, so killing the server kills the connection. (I can, of course, still adb shell directly into the box and launch it in the background on the target itself.)
There's a lot of stuff here to figure out, even just about adb.
On coming up, the target vnc server says it's listening on for VNC connections on port 5901. I can connect over ethernet, but if I don't have an ethernet cable handy, I can even use adb to tunnel all traffic over the serial line between the VNC ports on the host and the target, like this:
$ adb forward tcp:5901 tcp:5901The target vnc server also says it's listening for http connections on 5801. Sure enough, if I browse to http:192.168.1.1:5801 in a browser, I do get connected. Sadly, the browser just displays "File Not Found" so I don't yet have this piece all figured out, either.
Here are some other things I can't yet get to work, either:
- adb reboot bootloader says it should reboot and stop in the bootloader. It reboots, but completely. If I want to stop in u-boot, I still need to use minicom to get in over the serial line, and press a key while u-boot is running to stop the automatic reboot.
- Setting ANDROID_LOG_TAGS is supposed to filter the adb logcat output. That would be useful but, again, I can't figure out how to make it work.
- adb connect <host>[:<port>] is supposed to make a network connection. Me I can't make heads or tails of it yet.
The list of things I'm at sea with is still long. Maybe tomorrow it'll all make sense.
Sunday, December 9, 2012
My Work's Getting in the Way of My Work
Friday, we had meetings all day long. No Android.
Yesterday, I spent much of the day helping a new co-worker move.
Tomorrow, we have off-site meetings all day long.
Today, I have to do chores -- like laundry so my co-workers will be able to stand sitting near me.
I suppose I can spend a few minutes editing and updating old posts, but I'd like to be able to plug in a board and spend an hour or two educating myself.
Grumble.
Yesterday, I spent much of the day helping a new co-worker move.
Tomorrow, we have off-site meetings all day long.
Today, I have to do chores -- like laundry so my co-workers will be able to stand sitting near me.
I suppose I can spend a few minutes editing and updating old posts, but I'd like to be able to plug in a board and spend an hour or two educating myself.
Grumble.
Friday, December 7, 2012
More Presents! A Burner and an Ethernet Cable
Amazon has delivered an ethernet cable and an SD-card burner, so my equipment cup overfloweth.
I scrounge an old backpack out of the closet, repurpose it, and turn it into an equipment bag. I spend much of the lunch hour re-bagging, labelling, and rearranging. Cleanliness is next to Godliness.
I burn Karim's default distro onto one of my new SD cards with the burner, to verify that it works. Yup.
Next, I connect the CAT-6 cable. Now to bring up the network.
I'm going to have a little, dedicated 192.168.1 network, with the board as the "gateway". I set my host up like this:
Okay, that should do it. I go up to the network manager icon at the top of the screen and select "beaglebone". Doesn't connect.
Can I ping the box? Nope.
Oh. Wait. I need to have networking on the target, too.
I "adb shell" into the target, then magically incant
More networking exploration will have to wait until next time.
I scrounge an old backpack out of the closet, repurpose it, and turn it into an equipment bag. I spend much of the lunch hour re-bagging, labelling, and rearranging. Cleanliness is next to Godliness.
I burn Karim's default distro onto one of my new SD cards with the burner, to verify that it works. Yup.
Next, I connect the CAT-6 cable. Now to bring up the network.
I'm going to have a little, dedicated 192.168.1 network, with the board as the "gateway". I set my host up like this:
- Bring up Network Manager (Launcher > Manager)
- Create a new connection (Edit Connections > Add > IPV4 Settings > Add)
- Make the address static, with sensible values (Connection name: beaglebone / Method: manual / Address: 192.168.1.2 / Gateway: 192.168.1.1)
Okay, that should do it. I go up to the network manager icon at the top of the screen and select "beaglebone". Doesn't connect.
Can I ping the box? Nope.
Oh. Wait. I need to have networking on the target, too.
I "adb shell" into the target, then magically incant
# netcfg eth0 up# ifconfig eth0 192.168.1.1 netmask 255.255.255.0Hah! Now I can connect and ping the target.
More networking exploration will have to wait until next time.
Wednesday, December 5, 2012
My Supplies Arrive: It's Early Christmas!
Last night, Amazon delivered my two, 4GB SD cards and the USB barrel connector. I took these in today and played with them.
I've blocked out noontimes to work on embedded Android, and got Mary Todd to reserve a room for it, so anyone who wants to come join me and work, too, can do it: a noontime, Android Hacking Society.
Yesterday, it was John Ware and I. Today, John had a prior commitment, but Steve Tarr wandered in. Steve hadn't been able to sit in on the course, but he's the most serious embedded-systems guy on our team. Steve did the bulk of our kernel and boot-loader work, and is as comfortable with SBCs as I am uncomfortable.
I returned Jim Schilling's 4GB card, then burned one of my new SD cards, slipped it into the target, and booted it. Steve watched me with a jaundiced eye. I said, "I'll just adb shell into it." He started to tell me why it wouldn't work, but I got a shell prompt before he could.
When I said Karim had told us that by using a power cable instead of powering it over the serial line it would run faster, he was dubious.
"Well, let's try it!"
First, I powered it up with the barrel-connector.
We did a bunch of experiments, and it really is who gets plugged in first. For example, if I plug in the barrel connector, then plug in the serial cable, then unplug the barrel, it keeps running at 720MHz.
He fiddled around a bit with a few more boots and got it to give him a U-Boot prompt. He used
Well, or try. "There's no NAND?" he asked, incredulously, and looked at the board again.
I explained that people kept bricking the models made with NANDs.
"Oh, you can't brick them. All you have to do is attach a JTAG and rescue it."
I reminded him who he was talking to. I could no more "attach a JTAG and rescue it" than bicycle to Alaska. I could, however, burn an SD card and boot this board. He'd seen me do it.
Next, I used VNC to show him the GUI. Now, he was hooked. Good. I'll need his help.
"How much are these?" he asked.
Like Alan, he cautioned me that I needed stand-offs -- little feet for my board to lift it off the table -- so I wandered over to the hardware lab and asked James if he had some I could use. He though he did, but couldn't find any so he made some.
Made some.
People who can just make whatever they need, without muss or fuss, like James, or my sister Jo, have talents I can't even imagine having.
I've blocked out noontimes to work on embedded Android, and got Mary Todd to reserve a room for it, so anyone who wants to come join me and work, too, can do it: a noontime, Android Hacking Society.
Yesterday, it was John Ware and I. Today, John had a prior commitment, but Steve Tarr wandered in. Steve hadn't been able to sit in on the course, but he's the most serious embedded-systems guy on our team. Steve did the bulk of our kernel and boot-loader work, and is as comfortable with SBCs as I am uncomfortable.
I returned Jim Schilling's 4GB card, then burned one of my new SD cards, slipped it into the target, and booted it. Steve watched me with a jaundiced eye. I said, "I'll just adb shell into it." He started to tell me why it wouldn't work, but I got a shell prompt before he could.
When I said Karim had told us that by using a power cable instead of powering it over the serial line it would run faster, he was dubious.
"Well, let's try it!"
First, I powered it up with the barrel-connector.
$ adb shell# cat /proc/cpuinfobogomips: 718.02Then, I unplugged it and powered it back up with the USB-to-mini-USB serial cable.
$ adb shell# cat /proc/cpuinfobogomips: 498.89Now, Tarr was interested.
We did a bunch of experiments, and it really is who gets plugged in first. For example, if I plug in the barrel connector, then plug in the serial cable, then unplug the barrel, it keeps running at 720MHz.
He fiddled around a bit with a few more boots and got it to give him a U-Boot prompt. He used
U-Boot# mmcinfoto give him info about the card,
U-Boot# printenvto show me the boot command, and
U-Boot# nand infoto look at the NAND.
Well, or try. "There's no NAND?" he asked, incredulously, and looked at the board again.
I explained that people kept bricking the models made with NANDs.
"Oh, you can't brick them. All you have to do is attach a JTAG and rescue it."
I reminded him who he was talking to. I could no more "attach a JTAG and rescue it" than bicycle to Alaska. I could, however, burn an SD card and boot this board. He'd seen me do it.
Next, I used VNC to show him the GUI. Now, he was hooked. Good. I'll need his help.
"How much are these?" he asked.
Like Alan, he cautioned me that I needed stand-offs -- little feet for my board to lift it off the table -- so I wandered over to the hardware lab and asked James if he had some I could use. He though he did, but couldn't find any so he made some.
Made some.
People who can just make whatever they need, without muss or fuss, like James, or my sister Jo, have talents I can't even imagine having.
Unity Is A Launcher
A few years back, I bought a Mac, just to see what it was like. Nice box. I recommended Macs to my sisters, who are very happy with them. After a year or so, the motherboard died and I went back to Linux.
When I had the Mac, on the advice of my Mac friends, I used Quicksilver.
Quicksilver's simply a great launcher. It lets you launch applications with just a keystroke or two, and learns what you want to do. It's been around for almost a decade. For Mac-heads, it's an integral part of the UI.
Other platforms were stuck with CLIs and menus for years, but eventually, some pretty good alternatives appeared. Launchy and GNOME-Do come to mind, but there are others.
By-and-bye, the Ubuntu folks decided, first for netbooks, then for everything, to jump, feet-first, into the launcher world, by making a launcher be the GUI. That's what Unity's really about. They call it a "heads-up display" or something.
People who've been using Linux for a while still try to navigate using the icons on the left. Yeah, you can do that, but it's clumsy so they complain. They want "real Linux."
I try to tell them it's like using a dime for a screwdriver: you can do it, but it isn't the right tool for the job. Once I'd rotated my brain to think of Unity as a launcher, I experienced a great sense of relief. (I'd used Quicksilver pretty steadily for a while, so it wasn't an unfamiliar way to work.)
To launch vinagre, I press the "Windows key" and an overlay pops up with lots of choices. I begin typing "vinagre" and, by the time I get to "vina", the only choice left is the "Remote Desktop Viewer" icon. I press "Enter" and it launches. Boom.
If I want to read the pdf notes Karim passed out for the Beaglebone, I type "Windows-key" then "bea" and the first choice is "ea-beaglebone-120911.pdf" (which it has found in ~/Downloads, though it doesn't even bother to tell me that). I press <ENTER> and it launches the pdf viewer to let me see it. No mousing, no searching, no clicking.
When I want more control than that, I pop up a terminal window and I'm back in what I think of as "real Linux."
Vinagre Lets Me Use the GUI
Android has a beautiful GUI. It's what I use on my phone and tablet to do everything. The Beaglebone is headless. Now what?
The solution is remote-desktop sharing, using Virtual Network Computing (VNC), which lets me share desktops over a network.
Of course, the serial connection isn't a network, but never mind about that.
The current Ubuntu VNC client is vinagre. Android ships with a VNC server, imaginatively named androidvncserver.
So, taking this as an opportunity to use the Android Derbug Bridge (adb), I first go onto the target, then launch the server
Finally, all I have to do is launch vinagre on my netbook, choose the VNC protocol (I check "Use JPEG Compression" to make things a little faster), and connect to localhost:5901.
Presto! The screen fills with a familiar Android display.
Not only does this impress me, it everyone I show in their tracks. This is the "Aha!" experience for this course. This headless little board, though looking nothing like a phone or a tablet and lacking both keyboard and display, is uncontestably running Android.
The solution is remote-desktop sharing, using Virtual Network Computing (VNC), which lets me share desktops over a network.
Of course, the serial connection isn't a network, but never mind about that.
The current Ubuntu VNC client is vinagre. Android ships with a VNC server, imaginatively named androidvncserver.
So, taking this as an opportunity to use the Android Derbug Bridge (adb), I first go onto the target, then launch the server
$ adb shell # on the host, gets me a root prompt on the targetNext, back on the host, I use adb again, to fake up a "network" connection to the server. VNC talks on port 5901, so I tunnel tcp traffic between that port on the host, over a serial, adb connection, to the same port on the target board. The VNC client and server think they're talking over a network, adb is handling the traffic.
# androidvncserver &
$ adb forward tcp:5901 tcp:5901Cool, huh?
Finally, all I have to do is launch vinagre on my netbook, choose the VNC protocol (I check "Use JPEG Compression" to make things a little faster), and connect to localhost:5901.
Presto! The screen fills with a familiar Android display.
Not only does this impress me, it everyone I show in their tracks. This is the "Aha!" experience for this course. This headless little board, though looking nothing like a phone or a tablet and lacking both keyboard and display, is uncontestably running Android.
Tuesday, December 4, 2012
Use Minicom to Connect Over Serial
Okay, it's plugged in and the little blue light on the board is glowing. Now what?
I install minicom, start it up, and use Hayes modem commands to configure it. "Sherman, set the Wayback machine for 1981."
"Start it up" means "sudo minicom" because I lack permission to talk to whatever it thinks it's talking to. Maybe I could fix that. Right now, I just want to connect.
Really and truly, the user interface for minicom makes me feel young again. This was what talking to modems looked like on a CRT tube. It was so much higher-tech than waiting for the screech of the modem over the phone line, then plugging your telephone handset into the rubber cups of an acoustic coupler of a 150-baud modem. The Hayes Smartmodem was a godsend.
Thirty years later, the command set is still the same. I'm tempted to type ATDT and some ancient phone number just for old-time's sake.
It says ^A Z will get me help, which it does. The speed's already correct. I set hardware control flow to "off" and the device to /dev/beaglebone-serial, save it as a dfl file (it winds up in .minicom.dfl), and exit, resetting the modem. (".dfl" stands for "default." I looked it up.)
Why do I turn hardware flow control off? I have an easy, technical answer: that's what I was told to do. What is "hardware flow control" doing in my terminal program and why does minicom turn it on by default? Jeepers. Not a clue.
Now I start up minicom again, wait for it, and -- Presto! -- a root prompt from the Beaglebone.
All my standard Linux commands now work, running on the target. Oh, okay, not all of them, but why be a Debbie Downer? For now, I'm just thrilled. Time for another cup of coffee.
But first, I'll transform "connecting" into a test case, which I squirrel away here.
I install minicom, start it up, and use Hayes modem commands to configure it. "Sherman, set the Wayback machine for 1981."
"Start it up" means "sudo minicom" because I lack permission to talk to whatever it thinks it's talking to. Maybe I could fix that. Right now, I just want to connect.
Really and truly, the user interface for minicom makes me feel young again. This was what talking to modems looked like on a CRT tube. It was so much higher-tech than waiting for the screech of the modem over the phone line, then plugging your telephone handset into the rubber cups of an acoustic coupler of a 150-baud modem. The Hayes Smartmodem was a godsend.
Thirty years later, the command set is still the same. I'm tempted to type ATDT and some ancient phone number just for old-time's sake.
It says ^A Z will get me help, which it does. The speed's already correct. I set hardware control flow to "off" and the device to /dev/beaglebone-serial, save it as a dfl file (it winds up in .minicom.dfl), and exit, resetting the modem. (".dfl" stands for "default." I looked it up.)
Why do I turn hardware flow control off? I have an easy, technical answer: that's what I was told to do. What is "hardware flow control" doing in my terminal program and why does minicom turn it on by default? Jeepers. Not a clue.
Now I start up minicom again, wait for it, and -- Presto! -- a root prompt from the Beaglebone.
All my standard Linux commands now work, running on the target. Oh, okay, not all of them, but why be a Debbie Downer? For now, I'm just thrilled. Time for another cup of coffee.
But first, I'll transform "connecting" into a test case, which I squirrel away here.
I Can Run Android on my Beaglebone
Impatience got the better of me, and at lunchtime, I ran Android on my Beaglebone from my netbook.
The two steps are
Making the card is necessary because the board runs off of it. There's no flash with magic software on the box to burn in. Karim says that the manufacturer originally made boards with flash, but customers kept bricking them, so they stopped.
Jim Schilling scrounged up a brand-new, 4-Gig, SD card for me -- the ones I ordered don't arrive until tomorrow -- and I borrowed a burner.
Next, I grabbed a lets-see-if-it-comes-up, Beaglebone distro tarball, which Karim gave us and he tells me is also available here.
After an untar and a cd into the directory, I typed in this command to create a card:
The only touchy part was being really careful to make sure I was reformatting the SD card, not my hard disk.
What device the card mounts as depends on your own setup. So first, I used dmesg to see what device it thought it was adding.
Then I discovered that plugging in the card actually mounted it (looks like they come mountable, even brand-new), and mount would let me see what the device was mounting as. (It mounted the partition /dev/sdd1, but mkmmc-android.sh wants the name of the device itself: /dev/sdd.)
All this is done by this script, which documents the steps. The tarball download and the burn each take several minutes.
After the SD card is burned, I put it into the slot under the board, writing-side down. I press it in until it locks, then plug the board into the host with the serial (USB-to-mini-USB) cable.
Next step? Connect to see if worked.
This post's already long, so I'll put that step in the next one.
The two steps are
- Burn a card with software for it to run off of.
- Plug the card in, power up the board, and use a terminal-emulator (or adb shell) to connect to it.
Making the card is necessary because the board runs off of it. There's no flash with magic software on the box to burn in. Karim says that the manufacturer originally made boards with flash, but customers kept bricking them, so they stopped.
Jim Schilling scrounged up a brand-new, 4-Gig, SD card for me -- the ones I ordered don't arrive until tomorrow -- and I borrowed a burner.
Next, I grabbed a lets-see-if-it-comes-up, Beaglebone distro tarball, which Karim gave us and he tells me is also available here.
After an untar and a cd into the directory, I typed in this command to create a card:
sudo ./mkmmc-android.sh /dev/sddand waited about 5 minutes for the card to get formatted and populated.
The only touchy part was being really careful to make sure I was reformatting the SD card, not my hard disk.
What device the card mounts as depends on your own setup. So first, I used dmesg to see what device it thought it was adding.
Then I discovered that plugging in the card actually mounted it (looks like they come mountable, even brand-new), and mount would let me see what the device was mounting as. (It mounted the partition /dev/sdd1, but mkmmc-android.sh wants the name of the device itself: /dev/sdd.)
All this is done by this script, which documents the steps. The tarball download and the burn each take several minutes.
After the SD card is burned, I put it into the slot under the board, writing-side down. I press it in until it locks, then plug the board into the host with the serial (USB-to-mini-USB) cable.
Next step? Connect to see if worked.
This post's already long, so I'll put that step in the next one.
Udev Lets the Host Recognize the Beaglebone When I Plug It In
Right now, when I have my beaglebone plugged in, there's a /dev/beaglebone-serial. If not, there isn't. I talk to the board over this device.
The thing that makes this happen is udev, the Linux machinery that manages devices. It all runs in user space, and it's governed by textfiles in /lib/udev/rules.d and /etc/udev/rules.d . (Remember textfiles? Before XML, when someone told you something was "human-readable," it was a textfile, which actually was.)
The ones in /etc are meant to be local, so you can add new ones. To talk to the Beaglebone, I need to add rules. The details are still magic incantations to me, but Karim gave us a pair that work: 73-beaglebone.rules and 51-android.rules.
After installing them, and getting the udev daemon to re-read its rules, with
sudo udevadm control --reload-rules
plugging in the bone makes /dev/beaglebone-serial appear.
Note: This step, together with all the other basic, beaglebone setup steps I talk about in the next few posts, are documented and implemented here. Clone the repo, then do a make in that directory, and everything should get set up.
I put things in scripts and Makefiles, not just because I'm lazy (which I am), but because doing so forces me to document every picky, little detail. It's on GitHub, so if you're ever reading this, trying it yourself, and find stuff I've missed, fork the repo, fix it, and send me a pull request.
No nit is too small to pick.
Note: This step, together with all the other basic, beaglebone setup steps I talk about in the next few posts, are documented and implemented here. Clone the repo, then do a make in that directory, and everything should get set up.
I put things in scripts and Makefiles, not just because I'm lazy (which I am), but because doing so forces me to document every picky, little detail. It's on GitHub, so if you're ever reading this, trying it yourself, and find stuff I've missed, fork the repo, fix it, and send me a pull request.
No nit is too small to pick.
Sunday, December 2, 2012
And Here's How to Get the SDK and Eclipse
One ring to rule them all,
One click for the install.
Here's the ADT-bundle-download page that worked for me in class. Google has set it up as a one-click.
Took me half an hour to download, though. It's big.
One click for the install.
Here's the ADT-bundle-download page that worked for me in class. Google has set it up as a one-click.
Took me half an hour to download, though. It's big.
Here's An Easy Way to Install Sun's Java
After some poking around, I found this page.
Scroll down a little, until you get to How do I download and run this thing? and just follow instructions.
It does take a while. My little netbook took 23 minutes to run the script at a coffeeshop. After that, it took another few to do the
The "HelloWorld.java" in Karim's slide 337 is used by the first test in the subdirectory
Scroll down a little, until you get to How do I download and run this thing? and just follow instructions.
It does take a while. My little netbook took 23 minutes to run the script at a coffeeshop. After that, it took another few to do the
sudo apt-get install sun-java6-jdk sun-java6-plugin
sudo apt-get update-java-alternatives sun-java6Alternatively, the tools right here document and implement the steps to install both Sun's java6 and the whole Android Dev Toolkit, including the SDK and Eclipse. Using the stuff there won't be faster, but it'll be less typing.
The "HelloWorld.java" in Karim's slide 337 is used by the first test in the subdirectory
sysadmin/setup-java-dev-environment/t/
Saturday, December 1, 2012
Blogger Finally Lets Me Make My Blog a FIFO. Whew.
Blogs are great but they have a huge disadvantage: they're LIFO: Last In First Out.
A year or so ago, I accidentally wrote an book on how to play Old-Time Music -- the kind of music I play -- using Blogger.
I've been giving workshops at music-and-dance festivals two to three times a year since 1978, so writing the posts wasn't hard: I just started writing down the things I usually say.
Every morning, at 5am, my alarm would ring, I'd sit up in bed, grab my laptop, and write a post. Topics were random -- whatever struck my fancy on first waking.
I reckoned I'd start early and stop when I ran out of material. By the time I stopped to print things out, because the weekend was imminent, I had about 150 pages of material.
I'd written a small book.
But the order? Aargh.
Blogger just isn't meant to be turned into printable material. Too bad, actually, because. except for that, it's an awesome tool. I ended up rearranging my downloaded posts into alphabetic order -- no worse than anything else, I figured -- and I printed it out that way.
When I started this time, I assumed that'd still be true. Should someone stumble on these posts one day and want to read them as a guidebook, chances are they'll want to read them from start to finish, not finish to start. Oh well.
Moments ago, I poked around a bit and discovered Blogger now permits this order. (Maybe it always did and I just didn't know any better.)
I've rearranged the order of the archives like this:
A year or so ago, I accidentally wrote an book on how to play Old-Time Music -- the kind of music I play -- using Blogger.
If you're curious, old-timey is to bluegrass as blues is to rock-and-roll: it's a predecessor, but a distinct genre. It's dance music, and I play dances. There's a jam at my house, every Wednesday, no matter what. It's been going on for ... lessee ... thirty-five years. Much longer than I've been a software engineer.My band had been hired to play the Pilgrim's Progression dance weekend, in Lawrence, Kansas, over Thanksgiving, and I thought it would be useful to have some handouts.
I've been giving workshops at music-and-dance festivals two to three times a year since 1978, so writing the posts wasn't hard: I just started writing down the things I usually say.
Every morning, at 5am, my alarm would ring, I'd sit up in bed, grab my laptop, and write a post. Topics were random -- whatever struck my fancy on first waking.
I reckoned I'd start early and stop when I ran out of material. By the time I stopped to print things out, because the weekend was imminent, I had about 150 pages of material.
I'd written a small book.
But the order? Aargh.
Blogger just isn't meant to be turned into printable material. Too bad, actually, because. except for that, it's an awesome tool. I ended up rearranging my downloaded posts into alphabetic order -- no worse than anything else, I figured -- and I printed it out that way.
When I started this time, I assumed that'd still be true. Should someone stumble on these posts one day and want to read them as a guidebook, chances are they'll want to read them from start to finish, not finish to start. Oh well.
Moments ago, I poked around a bit and discovered Blogger now permits this order. (Maybe it always did and I just didn't know any better.)
I've rearranged the order of the archives like this:
Design -> Edit -> Blog Archive -> Show Oldest Posts FirstCould I also download it in this order and convert it to something printable? Doubt. But perhaps someday!
Color Helps Me Keep Track of What I'm Doing
I use color a couple of ways.
One way is to color-code my prompts. I have red-versus-green for stop-versus-go etched into my firmware, so whenever a command fails, I turn the prompt red. When it succeeds, I turn it green.
I seldom overlook an error message, and I don't need to print out $? to see the exit status of my commands. I don't have to think about this, the color just makes it jump out at me. Maybe it's just me, but if it's you, too, the code to make it happen is here, on GitHub.
The second way I use color is to color-code my terminals.
I'm an SCM/build guy, so I always have a lot of terminals up on my screen, connected to a plethora of machines, and as an array of users: myself, git, root, someone else I'm helping out, ...
Some folks have information about who and where they are in their prompts. Doesn't work for me.
First, the prompts get really long. Second, like Google ads, my brain's learned to ignore them.
Not so, color. Red prompt? STOP! Pay attention.
In the terminal app, I go to Edit->Profiles, and create profiles for an array of background colors. Then, when I go to a new machine or become a new user, I pick a different profile for that terminal window. My own machine is always the default profile. Root is almost always yellow. When I swap to a new window and it's yellow, I'm more cautious, without thinking.
Ubuntu 12.04's "terminal" gives me a lot of convenient, pre-defined color profiles. I remember when "making color profiles" meant tediously picking values from a color wheel, for both background and text.
I was in Dave Barach's living room when he got a call from our Maryland office saying they'd gotten the delivery of our editor, to go into IBM's still-unreleased PC/IX. Dave listened as they inserted the floppy and brought it up.
"It's coming up. That's good. ... It's up. ... Great. What? ... It's the wrong color? ... What do you mean, color???"
Every monitor we knew, and had developed for, was green-on-black. Nobody'd ever even hinted that an IBM PC might do colors.
One way is to color-code my prompts. I have red-versus-green for stop-versus-go etched into my firmware, so whenever a command fails, I turn the prompt red. When it succeeds, I turn it green.
I seldom overlook an error message, and I don't need to print out $? to see the exit status of my commands. I don't have to think about this, the color just makes it jump out at me. Maybe it's just me, but if it's you, too, the code to make it happen is here, on GitHub.
The second way I use color is to color-code my terminals.
I'm an SCM/build guy, so I always have a lot of terminals up on my screen, connected to a plethora of machines, and as an array of users: myself, git, root, someone else I'm helping out, ...
Some folks have information about who and where they are in their prompts. Doesn't work for me.
First, the prompts get really long. Second, like Google ads, my brain's learned to ignore them.
Not so, color. Red prompt? STOP! Pay attention.
In the terminal app, I go to Edit->Profiles, and create profiles for an array of background colors. Then, when I go to a new machine or become a new user, I pick a different profile for that terminal window. My own machine is always the default profile. Root is almost always yellow. When I swap to a new window and it's yellow, I'm more cautious, without thinking.
Ubuntu 12.04's "terminal" gives me a lot of convenient, pre-defined color profiles. I remember when "making color profiles" meant tediously picking values from a color wheel, for both background and text.
Actually, I remember when, ....
I was in Dave Barach's living room when he got a call from our Maryland office saying they'd gotten the delivery of our editor, to go into IBM's still-unreleased PC/IX. Dave listened as they inserted the floppy and brought it up.
"It's coming up. That's good. ... It's up. ... Great. What? ... It's the wrong color? ... What do you mean, color???"
Every monitor we knew, and had developed for, was green-on-black. Nobody'd ever even hinted that an IBM PC might do colors.
My Post Titles Are Usually Sentences. Thanks, Jim.
Task titles matter to me. So do blogpost titles.
I'm more likely to do a task (and remember what it was) if it's a full sentence. Not "git repository," but "Create git repository": subject and predicate.
Ditto for blog-post titles. I learned this from Jim Watson's little paperback, Molecular Biology of the Gene, one of the language's great books: content plus style, in spades. Like E. O. Wilson, Paul Samuelson, and Kernighan & Ritchie, Watson didn't just build his field by doing, he also did it by writing about it.
He opened it for guys like me.
He opened it for guys like me.
Years after I read the book, I noticed that his section heads were often sentences. Not "Enthalpy" but "Enthalpy Is the Total Energy of the System." I wonder whether he just listed the points he planned to make on a piece of paper, then filled in explanations.
His is the first book I ever remember seeing do this. For all I know, everything does now. Even if no one else does, I still try to.
The book's blimped out over the years and taken on lots of other authors. For all I know, if you want a good overview of the field, it's still great book. Still, to get the punch of Watson, writing it right, you have to go to the original, from 1965. Even the second edition seemed watered down. Unfortunately, it looks like that's easier said than done. I just found one on eBay that was snapped up at $80. Another, from Albris books, is in "Very Good" condition, for $850. Yow.
His is the first book I ever remember seeing do this. For all I know, everything does now. Even if no one else does, I still try to.
The book's blimped out over the years and taken on lots of other authors. For all I know, if you want a good overview of the field, it's still great book. Still, to get the punch of Watson, writing it right, you have to go to the original, from 1965. Even the second edition seemed watered down. Unfortunately, it looks like that's easier said than done. I just found one on eBay that was snapped up at $80. Another, from Albris books, is in "Very Good" condition, for $850. Yow.
It is not coincidental that when Watson wrote the story of his discovery of the structure of DNA, The Double Helix, it was a best seller. He can flat-out write.
Not I, but I do know to steal a good idea when it smacks me in the face.
GitHub Has Project Management, Ticketing, & a Wiki
I've started opening (and closing) tickets in GitHub. Project management and tracking, here I come.
This also lets me try out new features of GitHub that I haven't played with before. Because GitHub is an important tool for me, I look for excuses to explore all its corners. My time's limited, so I love killing two birds with one stone whenever I can.
I created two milestones. The first was Initial Infrastructure, which I wanted to get set up this weekend. I identified tasks, opened them, then closed them as they got done. Most were closed instantly, since I had to do them to get to this point, but some weren't.
The second milestone was Bring Up Android on the Beaglebone: building the base build and bringing it up. I don't expect to finish that until next weekend, so this let me define the tasks. It's this week's sprint!
GitHub also gives each repo its own wiki. I don't really have much to put there, so I just linked this project's back to this blog.
This also lets me try out new features of GitHub that I haven't played with before. Because GitHub is an important tool for me, I look for excuses to explore all its corners. My time's limited, so I love killing two birds with one stone whenever I can.
I created two milestones. The first was Initial Infrastructure, which I wanted to get set up this weekend. I identified tasks, opened them, then closed them as they got done. Most were closed instantly, since I had to do them to get to this point, but some weren't.
The second milestone was Bring Up Android on the Beaglebone: building the base build and bringing it up. I don't expect to finish that until next weekend, so this let me define the tasks. It's this week's sprint!
GitHub also gives each repo its own wiki. I don't really have much to put there, so I just linked this project's back to this blog.
Karim Has the Course Material On Line
Karim has made the course materials available, under a creative-commons license, right here.
They're good. Plus, having them on-line already means I don't have to host them.
They're good. Plus, having them on-line already means I don't have to host them.
GitHub Is Hosting My Code
The repo for all this work is now on GitHub.
Like all my GitHub repos, it's public, so anyone can get it with either
The first contents I put in is a directory of files for customizing my environment. I have my vimrc, a suite of bash customizations (I'm a heavy bash user), and a script for keeping the host Ubuntu distro up-to-date, which I usually run from cron.
Early on in the course, my laptop died. Setting up my environment anew on the replacement was easier because I had easy access to these files. Good thing I put them somewhere easy to find, so I can do the same on any box. In this case, I'm running on a little, Dell Inspiron Mini 1012.
Like all my GitHub repos, it's public, so anyone can get it with either
git clone git://github.com/jsh/electricsheep.gitor
git clone https://github.com/jsh/electricsheep.gitOf course, first they have to have git, which they can get with
sudo apt-get install git(The package used to be called git-core, but now it's just git.) There's an analogous yum install in Fedora, but I'm working on Ubuntu, so I can testify to that.
The first contents I put in is a directory of files for customizing my environment. I have my vimrc, a suite of bash customizations (I'm a heavy bash user), and a script for keeping the host Ubuntu distro up-to-date, which I usually run from cron.
Early on in the course, my laptop died. Setting up my environment anew on the replacement was easier because I had easy access to these files. Good thing I put them somewhere easy to find, so I can do the same on any box. In this case, I'm running on a little, Dell Inspiron Mini 1012.
Here Biginnith the Book of the Tales of Aundroidbury
Having just finished a week of excellent embedded-Android training, by Karim Yaghmour, it behooves me to be certain I learn the material.
Me, I either learn things or I forget them. "Learn" means they're in there forever. I learned Mendelian genetics and how to walk. "Forget" means that I got them in there long enough to get by for a little while but, by a month later, couldn't have given you more than a vague overview. I forgot physical biochemistry and Vietnamese.
I want Android internals in my brain for good: solidly enough to use and think about without reference books at hand.
All this is embedded-systems programming -- software to run hardware. The last three companies I've worked at have produced devices. QMS made printers. Aztek made telephony equipment -- switches and stuff. Aircell makes telecom equipment for the aircraft industry. I just finished releasing a phone based on Android. Sloccount tells me the code base has twenty-six million lines of code. Million.
So I know all about this stuff, right? Not a clue. I'm a software guy. Axolotls know more about hardware than I do. I have, in fact, never taken an engineering class.
This doesn't mean I'm as dumb as I look. Think about it: how could I be? Here's a good opportunity to learn. AFOG.
First things first.
Monday, I ordered a Beaglebone (bb). It's the hardware platform we used in class, so it's not a variable. Keeping the intellectual "moving parts" at a minimum works for me. Thursday night, it appeared, and came right up. I was able to bring up the SD card that came with it, which runs Open Embedded, and the card that I'd been using in class, running Android.
What's this mean? It means the hardware works and I don't have to worry about that piece.
Unlike the bb from class, it didn't come with either an ethernet cable or a USB-to barrel-connector power cable, so I ordered both from Amazon on Friday morning, with advice from Carl Wagner and Alan Bennett on what to get. They should show up early next week. Meanwhile, the board will run (slower) on power from the usb-to-mini-usb cable that came with it, and I can talk to it on the serial port over the same cable with minicom, putty, .... (I even used cables from work to verify that the power and ethernet connectors on the bb work.)
I also ordered a pair of 4Gb, micro SD cards from Amazon. The bb has no flash memory -- it does everything running off the SD card. Carl says that the different type numbers available correspond to different speeds, and recommended I pay slightly more to get a type 6, because the type 4 cards, which looked like the cheapest, would be noticeably slower.
Okay. Learn as I go.
Next, infrastructure.
With that, here I go.
Me, I either learn things or I forget them. "Learn" means they're in there forever. I learned Mendelian genetics and how to walk. "Forget" means that I got them in there long enough to get by for a little while but, by a month later, couldn't have given you more than a vague overview. I forgot physical biochemistry and Vietnamese.
I want Android internals in my brain for good: solidly enough to use and think about without reference books at hand.
All this is embedded-systems programming -- software to run hardware. The last three companies I've worked at have produced devices. QMS made printers. Aztek made telephony equipment -- switches and stuff. Aircell makes telecom equipment for the aircraft industry. I just finished releasing a phone based on Android. Sloccount tells me the code base has twenty-six million lines of code. Million.
So I know all about this stuff, right? Not a clue. I'm a software guy. Axolotls know more about hardware than I do. I have, in fact, never taken an engineering class.
This doesn't mean I'm as dumb as I look. Think about it: how could I be? Here's a good opportunity to learn. AFOG.
First things first.
Monday, I ordered a Beaglebone (bb). It's the hardware platform we used in class, so it's not a variable. Keeping the intellectual "moving parts" at a minimum works for me. Thursday night, it appeared, and came right up. I was able to bring up the SD card that came with it, which runs Open Embedded, and the card that I'd been using in class, running Android.
What's this mean? It means the hardware works and I don't have to worry about that piece.
Unlike the bb from class, it didn't come with either an ethernet cable or a USB-to barrel-connector power cable, so I ordered both from Amazon on Friday morning, with advice from Carl Wagner and Alan Bennett on what to get. They should show up early next week. Meanwhile, the board will run (slower) on power from the usb-to-mini-usb cable that came with it, and I can talk to it on the serial port over the same cable with minicom, putty, .... (I even used cables from work to verify that the power and ethernet connectors on the bb work.)
I also ordered a pair of 4Gb, micro SD cards from Amazon. The bb has no flash memory -- it does everything running off the SD card. Carl says that the different type numbers available correspond to different speeds, and recommended I pay slightly more to get a type 6, because the type 4 cards, which looked like the cheapest, would be noticeably slower.
Okay. Learn as I go.
Next, infrastructure.
- If I write stuff down, it'll make me think about it harder. Vide supra et infra.
- I need to stash my code somewhere. GitHub gets the nod.
- I need to pay attention to what I do, how long it takes, and what needs to get done next. This one's harder. I spent an hour looking at various project-management (pm) options and rejected them all. Remember the Milk seems too heavyweight and isn't tailored to the Agile-and-ticket-tracking "thing." Trac and Redmine are self-hosted, which turns pm into a science experiment. I'm already doing this one and don't have time for another. JIRA? Great, but even the cheapest version is $120/year: four months of double cheesburgers off of Macdonalds' dollar menu. I'll try using what GitHub supplies. It may be good enough, and I'll get more familiar with what they offer, an added value.
With that, here I go.
Subscribe to:
Posts (Atom)