| Android, Debian, Linux, remote keyboard to G1, ... |
[Dec. 14th, 2008|11:02 pm] |
I'm loving Android more and more. I keep finding (and filing) bugs, but they're all fixable, and this is only going to keep getting better.
Today I installed Debian on my G1. I followed those instructions up until the unionfs part, where I opted to use bind mounts instead, letting me have a /android/data and /android/system inside my Debian chroot.
Anyway, I now have openssh, perl, python, sqlite3, emacs, git, svn, gcc, screen, nmap, tcpdump, iftop, etc... all running on my phone in a little 2GB filesystem. (I have a 16GB SD card). Then using ConnectBot, I just keep an ssh connection from the phone to localhost all the time, so Debian is accessible when I'm out and about.
But when I'm at home and want to ssh in, I have a bash alias which forwards a port over USB:
alias droid='$ANDSDK/tools/adb forward tcp:1622 tcp:22 && ssh -p 1622 root@localhost'
... so then my openssh server only needs to listen on localhost.
Now that I can just ssh into my phone to work on stuff, I was getting annoyed having to reply to SMSes by using the little phone keyboard when I was sitting in front of a real keyboard.
So I wrote this:
http://github.com/bradfitz/android-misc/tree/master/type.pl [mirror]
That's an app which captures my keystrokes in my ssh session (I have it running in a screen window), and then injects them into the Linux input layer, so Android thinks I'm typing them on the keyboard.
Even cooler: I wrote that all ssh'd into my phone, over ssh in Emacs in screen, including git-push'ing it to github.com.
Fun stuff.
(Don't worry --- I'm not just working on useless stuff. ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) dan_erat and I were hacking on an Android app today which everybody can use....) |
|
|
| K-9 SMS: v2 |
[Dec. 8th, 2008|11:56 pm] |
Updated K-9 SMS. Same download URL:
http://bradfitz.com/android/K9Sms.apk
Changes:
*) fix duplication issues with system SMS service/notifications also running.
*) enter key now inserts a literal newline instead of sending the SMS. (by request, and because I accidentally send too many SMSes too that way)
*) little about menu with version number |
|
|
| K-9 SMS: faster SMS for Android |
[Dec. 7th, 2008|10:08 pm] |
I pulled the latest Android git code and fixed some performance bugs in the SMS app. Here's the improved SMS app:
http://bradfitz.com/android/K9Sms.apk
It's a lot faster to scroll around and stuff now. No more repetitive, uncached, blocking SQL queries in the UI thread when each list items comes in/out of view.
With permission from Jesse Vincent, I named it after k9mail, as it's in a similar spirit. We'll probably put it in k9mail's svn repo until all the changes get merged into mainline. Consider this a temporary, experimental fork. |
|
|
| This Just In: Forbes Clueless! |
[Dec. 6th, 2008|11:24 pm] |
Oh man. Worst article ever. Count the inaccuracies and stupidities within.
Some of the highlights:- they reference my Android garage door opener app but confuse it and say that Android was ported to run on a garage door opener. I mean, almost the same, right? :P
- they call X11 an old version of Unix:
Google employees not using the secret OS are employing various versions of Unix, such as Linux or Ubuntu, and some older operating systems, like X11, he says.
Love it. |
|
|
| JavaFX Fail |
[Dec. 4th, 2008|11:19 pm] |
I go to look at the JavaFX demos. I'm redirected by javafx.com to a URL that contains /mac-player.jsp. Write-once-run-anywhere, my ass. Sun's own URL is calling an end to that lie.
Then, after a long hang, my browser goes white and all the other windows and tabs hang and start spinning rainbow beachballs and I get a trust dialog:
After that Safari hung so hard I hand to force kill it a few times.
Good job.
I still don't know what JavaFX is. |
|
|
| AddressBooker & exporting my Facebook Phonebook |
[Nov. 30th, 2008|09:25 pm] |
This 4-day weekend was awesome for catching up on personal hacking projects. In addition to adding IPv6 support to Perlbal and hacking on my interactive shadow/art wall more, I also worked on a little address book management tool, AddressBooker [source here].
Basically AddressBooker takes a POST of contacts data in JSON form, and does stuff with it, where "stuff" is currently limited to merging it into your Google Contacts. (GMail, Android, etc) This was my experiment in learning GData, AuthSub, and App Engine a bit more.
Anyway, I then wanted to get my Facebook Phonebook exported to my Google Contacts, so it'd sync to my Android phone. I didn't see an export option in Facebook (maybe I missed it?), so I wrote a little GreaseMonkey script instead to automate the whole process:
http://bradfitz.com/greasemonkey/facebook_phonebook_export.user.js
If you have Firefox and GreaseMonkey, then click the above link and it'll ask if you want to install it. Install it, then go to your Facebook Phonebook (sorry, no permalink to it), then go into Tools > GreaseMonkey > User Script Commands... > and you'll see Export Facebook Phonebook. That'll then page through your phone book (you should probably start on page 1: it's kinda flaky) and extract the data, and then POST it to AddressBooker for you, which will then guide you through merging it into your Google Contacts.
Enjoy!
(And keep in mind I barely know browser stuff or Greasemonkey or Python or App Engine or GData, so patches welcome!... brad@danga.com, or Github)
Update 2009-05-09: Updated the JavaScript to work with Facebook's new layout. |
|
|
| IPv6 (or, hello from 2001:470:1f04:900::2 !) |
[Nov. 17th, 2008|11:44 pm] |
I figured it was time to learn IPv6 so I setup IPv6 at home using Hurricane Electric's free tunnel broker, one termination point of which is across the Bay in Fremont, so latency overhead is negligible, and he.net's IPv6 deployment is good (or so Lorenzo tells me).
sammy:~# ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes
64 bytes from 2001:4860:0:2001::68: icmp_seq=1 ttl=58 time=97.7 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=2 ttl=58 time=96.9 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=3 ttl=58 time=97.2 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=4 ttl=58 time=98.0 ms
sammy:~# ping google.com
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=246 time=94.5 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=246 time=97.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=246 time=93.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=4 ttl=246 time=92.5 ms (Not that much worse.)
And I can now see all the dancing logos on various websites. (it's IPv6 tradition to serve animated GIFs of your company/site logo for people accessing it over IPv6.... silly, but cute.)
Still have some work to do... I need to get the rest of my machines routing through my Linux server (the one with the tunnel), including wifi. What's the typical configuration here? DHCPv6 and broadcast the route? Or does the IPv6 stateless auto-configuration for assigning the locally-scoped/link-local/etc addresses also include smarts of hosts w/ gateways advertising that?
In any case, still clueless, but at least with the tools to get slightly less clueless now.
It's weird having my own /64. (that's 2^64 addresses for my house) |
|
|
| Android Garage Door Opener |
[Nov. 16th, 2008|11:36 am] |
I've finally put the source code to my Android garage door opener online:
To get it, just run:
$ git clone git://github.com/bradfitz/android-garage-opener.git
Or browse the code online. Just keep in mind the code might suck because I barely know Java or Android, so educate me if you see bugs. But it works. *shrug*
Enjoy. |
|
|
| Ass Robots |
[Nov. 7th, 2008|08:36 am] |
I think the world needs more robots that climb up your ass:
 |
|
|
| Android Garage Door Opener, part 2 |
[Oct. 26th, 2008|12:06 pm] |
This is a follow-up to my previous post to say:
SO. FUCKING. AWESOME.
I got it all working. I now have an Android Activity (GarageDoorActivity) which interacts with an Android Service I wrote (InRangeService), letting me start and stop the service's wifi scanning task. The service gets the system WifiManager, holds a WifiLock to keep the radio active, and then does a Wifi scan every couple seconds, looking for my house.
When my house is in range, it does the magic HTTP request to my garage door opener's webserver (HMAC-signed timestamped URL, for non-replayability/forgeability if sniffed) and my garage door opens. Complete with a bunch of fun Toast notifications (like Growl) and Android Notifications (both persistent ongoing notifications for background scanning, and one-time notifications for things like the garage door actually opening).
I just threw on some shoes and hopped on my motorcycle to do a test lap around the neighborhood. When I got to the corner, I pulled up the activity and press "Start" (aka "Going home now"). A lady on the corner saw me playing with my phone on my motorcycle and said, "The reception's not so good up here." I thanked her, not wanting to explain what I was actually doing.
I then finished the lap around the block and the garage door started opening a few houses away. By the time I pulled up, I could already back the bike into the garage. HELL YES.
Update 2008-11-16: The source code is now available. |
|
|
| Fun with Android |
[Oct. 20th, 2008|10:31 am] |
I've been having fun writing Android apps.
My main Android app I care about is my garage door opener. I have a webserver hooked up my garage door opener, so I can open my garage over the network. Combined with a background process doing wifi scanning, the idea's that when I'm on my way home, I pull up to my house on my motorcycle and the garage door magically opens and I back into my garage without taking off my helmet/gloves/etc.
Last night I wrote the background wifi scanning service part and walked around my house and neighborhood to get the signal strengths to the three different APs in my house (and the other ones of my neighbors). Looks like it'll work perfectly. Now I just need to wire up my wifi scanning service with my garage door opening code (simple http client that HMAC signs one-time timestamped URLs).
I just mentioned to evan that it looks like I have enough data to real-time triangulate within my house which room I'm in, since I have enough access points and their signal strengths vary enough. I was going to just make some stupid widget on http://bradfitz.com/ show where I'm at (which room at home, at work, in car via Bluetooth detection, on google shuttle via wifi detection, etc...) even without GPS (or with, if available).
But evan went one further:make it turn on the lights for whatever room you're in.
that'd be cute.
you could call it "magic wand of light" Hell yes.
Update: See the conclusion in Part 2. |
|
|
| Tech mumblings |
[Sep. 10th, 2008|09:21 pm] |
* Android SDK == even awesomer[1] than last time I checked it out. Too many apps I want to write.
* Eclipse ... seriously? You really need to use 850 MB of memory, you fat, slow piece of shit? Emacs is using 8 MB. Le sigh.
[1] if Apple can use the word funnest, I can use awesomer. |
|
|
| Perl on App Engine |
[Jul. 22nd, 2008|08:38 pm] |
Fellow Perl hackers,
I'm happy to announce that the Google App Engine team has given me permission to talk about a 20% project inside Google to to add Perl support to App Engine. To be clear: I'm not a member of the App Engine team and the App Engine team is not promising to add Perl support. They're just saying that I (along with other Perl hackers here at Google) are now allowed to work on this 20% project of ours out in the open where other Perl hackers can help us out, should you be so inclined.
As background, I've been writing Perl code for almost 15 years now and quite fond of the language. (I'm "bradfitz" on CPAN.) Here at Google, though, it's not one of our big languages so I don't get to write as much Perl as I used to. I'd still like to run my personal web apps on App Engine, though, and I'd like to write them in Perl. And I'm definitely not alone, looking at how many people have starred the wishlist bug. Some of you have already started talking about it. We'd like to join the discussion, and start hacking out in the public.
In the process we can build the start of an open source App Engine server clone that's suitable for many purposes: initially just for regression testing & local development (like the "dev_appserver" that comes with the App Engine Python SDK), but perhaps in the future (once Hypertable/Hbase/etc are ready) a full stack to give to ISPs to let them run App Engine apps on their own.
Before I get into my proposed roadmap, let me describe what's publicly known about the App Engine architecture. In a nutshell, it looks like this:
The App runs in a multi-layer hardened environment, one layer of which will need to be a hardened Perl interpreter.
Basically, we need a hardened Perl runtime which can:
- open & read files
- NOT write files
- NOT open sockets
- NOT fork
- NOT do any other system functionality that's not strictly needed for a web app
Basically we need a Perl interpreter that's very tame and isn't allowed to do anything other than read web requests and write out responses. Any privileged operations (like Datastore access, fetching URLs, etc) need to be done via a trusted XS Perl module (the "apiproxy") that takes a service request parameter and returns a service response. The request and response are both encoded as Protocol Buffers, which were recently open sourced by Google.
Perl on App Engine then would involve the following steps (in no particular order):
- Hardened Perl Interpreter: basically, we'll be statically linking in a hardened, customized libperl to a C++ application, disabling all Perl dynamic loading. Only vetted, security-audited XS modules will be allowed. Only safe Perl opcodes will be allowed. (No sockets, no ioctl, no fork, etc, etc.) To get a preview for what this'll feel like restriction-wise, check out the newly written Sys::Protect which Artur and I wrote this evening and will be continuing to develop for people's dev environments (not production).
- Protocol Buffers for Perl: we need support for Protocol Buffers for Perl. I've started on this project internally and will open source the code soon, once I have a few free minutes.
- Server: we need to write an App Engine server for testing, local development, and potentially production deployment. (Replace Bigtable with MySQL, Hypertable, Hbase, Couch DB, etc.)
- Libraries: Perl client libraries for Datastore, URLFetch, etc services. Including docs.
Not included is the Google-internal side of things, gluing the hardened Perl interpreter into the GAE world. That needs to be done by a Googler and not open source.
If you'd like to discuss this and/or help out, join the perl-appengine mailing list. We'll be submitting code to the appengine-perl project on Google Code hosting. For more information about this, see the Perl-on-AppEngine FAQ.
Brad & the other Perl Googlers |
|
|
| IPv6 |
[Jul. 15th, 2008|02:05 pm] |
I saw that this was open sourced today:
http://code.google.com/p/stubl/
I followed our internal instructions for using it and now I have IPv6 on my desktop at work. Any good IPv6 sites to hit? (besides the Great Experiment, which isn't quite SWF) |
|
|
