The Treehouse Blog

I like Oreos, but every time Google hijacks a new dessert, I need to revist the HSC app to accommodate its new flavor. Sigh.

Firstly, startTethering() now checks for and fails if it is passed a null callback (see here), which I had been doing. You wouldn’t think this would be a big thing to handle. The callback class is ConnectivityManager.OnStartTetheringCallback, an abstract class that is not present in the Android SDK. I’ve still been using reflection to access parts of the System API, as it has seemed to be the easiest approach for this type of thing. However, you can’t create a subclass using reflection. With Dynamic Proxy you could do this if it were an interface, but it’s not.

So I needed to find a better way of compiling against the non-public pieces of the Android API. The way that ended up working for me was to build the SDK from the AOSP sources. Following the documentation, I had a number of build errors having to do with things being defined in multiple places, which I would comment out as I encountered them. Eventually the build was almost successful (seemed to fail on the last step or so), but it got far enough to produce the .../framework_intermediates/classes.jar, which is to have what is needed. After stumbling through various things (I’ve found no great documentation for this), I ended up going with these gradle modifications to let me get at the class in question. I copied the above classes.jar as system_libraries/framework_all-26.jar.

top-level build.gradle, added to “allprojects” block:
gradle.projectsEvaluated {
tasks.withType(JavaCompile) {
options.compilerArgs.add('-Xbootclasspath/p:hsc/system_libraries/framework_all-26.jar:android/net/ConnectivityManager.class')
}
}

app-level build.gradle, added to the “dependencies” block:
provided files('system_libraries/framework_all-26.jar')

With these changes, AndroidStudio still can’t see changes (the IDE is unable to resolve the symbols), but the build process is nevertheless successful. There’s probably a better way, maybe even something trivial, or perhaps using a different IDE that is more flexible, for one.

Secondly, this: Privileged Permission Whitelist Requirement. Enforcement of this started in Android 8.0, and it means that even putting HSC into the /system/priv-app directory is not enough to give it the necessary privileges. Fortunately, adding the necessary permissions to /system/etc/permissions/privapp-permissions-platform.xml is apparently sufficient:

<privapp-permissions package="me.alleman.brady.hsc">
<permission name="android.permission.CHANGE_NETWORK_STATE" />
<permission name="android.permission.CHANGE_WIFI_STATE" />
<permission name="android.permission.ACCESS_WIFI_STATE" />
<permission name="android.permission.CONNECTIVITY_INTERNAL" />
<permission name="android.permission.TETHER_PRIVILEGED" />
<permission name="android.permission.ACCESS_NETWORK_STATE" />
<permission name="android.permission.MANAGE_USERS" />
<permission name="android.permission.WRITE_SETTINGS" />
</privapp-permissions>

The updated package, in case you find it useful: hsc8.apk

What did I read in 2014?

Not as much as I should have.  I have a lot of books on the queue, and just didn’t spend a lot of time reading this past year.

The Three Investigator’s (read these from the library as a kid; building my own collection now and re-reading them as I get them):

• The Mystery of the Headless Horse ^(ad)
• The Mystery of Monster Mountain ^(ad)
• The Secret of the Haunted Mirror ^(ad)

• The Liberty Amendments: Restoring the American Republic ^(ad)
  • Levin presents some interesting ideas on constitutional amendments, many in support of providing for additional checks and balances in the system.
• One Second After ^(ad)
  • Forstchen provides an account of how a small town is affected by an EMP attack on the United States.  While I’m hopeful that the situation would not be as bad as the author supposes, it is a compelling story about how we would react to having most of our technology suddenly stripped away.
• Lila: An Inquiry into Morals ^(ad)
  • Interesting, but to me seemed to end without concluding much useful.
• The Martian: A Novel ^(ad)
  • The best book I read this year.  Take the premise of Apollo 13 – bad stuff happens, and lots of problems need to be thought out and worked around to stay alive and get home.  The book fully embraces the technical aspects of things, and reminds me a lot of a Michael Crichton novel.
  ^(ad)

Firstly, I’m not a mechanic, but with electrical problems I’m willing to take a stab.

A few weeks ago, I was driving my truck (2005 Ford Ranger) back from a hike with a friend when the engine stopped.  I shifted into neutral and tried to restart, and it would crank but that’s it.  We got pushed off the road and checked for fluid leaks, etc.  Eventually I decided to try the fuel pump shutoff inertia switch and the truck started immediately.  I wasn’t completely convinced this was the problem – that maybe whatever the problem was had resolved itself around the time I reset the switch.  There was no jolting of the vehicle that should have set off the switch.  Researching the problem online, there was some indication that passenger’s wandering feet are sometimes the cause of the problem, as the switch is located in the passenger foot-well, and other indications that if it trips once reset it, if it trips twice, replace it.  I was content to reset and forget, as my passenger also indicated he may have been repositioning his feet when it happened.

A week later, the switch tripped again.  The same passenger was present, but this time there was no recollection of any bad feet positioning.  Resetting the switch was the first remedy attempted and was immediately successful.  It was now clear that replacing the switch would be the next step.  Researching Ford’s parts database found that in addition to a replacement switch, a “conversion kit” was available that would move the switch from its foot-well location to behind the trim panel (“cowl”) next to the fuse box.  I had initially decided against this (it was 4x as expensive), but the Ford dealer indicated that the kit was the appropriate resolution, so I bought one.

Installation was very straightforward, though it is difficult to position your drill in the necessary orientation to drill the pilot holes for the switch mounting bracket.  After breaking the head off a ground screw while trying to remove it (remedy: different screw), and breaking the pop-off holding the cowl in place (remedy: zip tie), the switch was finally in place.  Upon starting the vehicle, however, the airbag light began flashing a sequence.  Panic.  Must have drilled through airbag wiring or something.  No!

Fortunately, Google translated that code “27” was indicating that the passenger airbag off light was burned out.  Interesting coincidental timing.  So, I disassembled the portion of the dash and removed the offending keyswitch/light module for a little repair work.  I de-soldered the light and replaced it with a resistor and LED.  It ended up being a lot dimmer than the factory bulb, but the airbag computer is fine with it.

So far, so good.  Hopefully no relapse is on the horizon.

References

My Haynes Repair Manual does little more than acknowledge the existence of the fuel pump inertia switch and air bag system, so here are some of the resources I found.

• Inertia Switch Teardown
• Inertia Switch, notes on a kick shutting it off
• Inertia Switch problems
• Inertia switch over-sensitivity
• Airbag Code 27 and Bulb Replacement Instructions
• Airbag Codes

Since the root zone was signed this week, I spent a bit of time today setting up DNSSEC validation on my home recursive server.  It was relatively painless (so far).  I did opt to not enable DLV though – not fond of it receiving every host name I resolve.

Resources:

• RHEL RPMs from http://people.redhat.com/atkac/bind/5.6-test/ – if someone finds a better source for BIND 9.7+ RHEL RPMs, I’d like to know.  I had no luck building from the Fedora SRPMs.
• http://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers – instructions for setting up BIND to use the root key.
• http://fanf.livejournal.com/107310.html – A more thorough walk-through of setup.

One resource I would have liked to find and could not was a deliberately unvalidatable non-root zone/record that could be used to see a validation failure.  If anyone knows of or finds such a thing, please pass it along.  Now we get to wait for .com, .net, etc, to catch up to .bg and .uk in the publishing of DS glue for deeper validation.

UPDATE 7/22/10:  Just found the following site which makes available bad records for testing purposes: http://dnssec-tools.org/testzone/index.html

A few years ago, I decided to improve the light switch situation in my garage.  The garage had lights at either end controlled by pull strings.  It was a frequent hassle to walk from one end to the other, often tripping over a variety of obstacles, to get both of them on or off.  Having already deployed X10 to control a few things around the house, it seemed like a reasonable and economical idea to use X10 here as well.  I used two LM15As for load switching, two SS13As for control near both doors in the garage, and an RR501 to tie everything together.  Initially, the project seemed to be a great success.

Then it becomes apparent that the SS13As are not that great.  The adhesive backing would refuse to stick to the garage wall for extended periods of time, necessitating the addition of some screws to provide a slight ledge for them to sit upon.  They are also battery powered, and the stock batteries were nearly useless in cold weather.  Naturally, the colder times of year require the use of lights in the garage more often, and it became incredibly annoying to have to warm the switch with your hand and make multiple attempts to turn on the light… when the pullstring that otherwise would work is in reach.  My suggestion is to never use SS13As in anything but warm environments, and probably just avoid them altogether.  The one I had used inside would “forget” its code assignments and the coldness of the window sill was enough to keep it from working well.

To fix these issues, I revisited the idea of wiring regular three-way switches in the garage.  With the layout of the existing wiring, even the most creative ideas would require two new wires run the length of the garage, with one of them likely needing to be a 3-conductor that I don’t happen to have laying around.  And copper isn’t really cheap right now.  So, X10 was again looked at for a solution.

I decided to go with hard-wired X10 controllers, specifically the XPT4-W.  I installed these near existing wire locations with a minimal of effort – maybe 3 hours total. So, now I have fully functional control of my garage lights (probably even in cold weather), and didn’t need to run crazy amounts of cable for three-way switches.