Tue
May 13
May 13
Evening hack: multiheaded Nokia 3310 displays
I know, I know, 84x48 pixels should be enough for anybody. But I just find that I’m so much more productive with the extra space.
About
I'm Nicholas FitzRoy-Dale, a software developer from Sydney, Australia. I'm interested in embedded systems and operating system research, code optimisation, 8-bit music, rock climbing, shiny things...
SPI Flash programmer for Arduino
I’ve released an SPI Flash programmer sketch, along with a Python driver library (written for Python 3). It requires pySerial. Full docs are available on Github:
This isn’t particularly nice code, but I couldn’t find a usable SPI programmer sketch when I wanted one. This one has been tested on a couple of chips and should work, but let me know either way if you use it.
One thing it doesn’t support is the extended command set for large SPI Flash chips, so for now it only works with chips up to 16MB.
Mon
May 12
May 12
Call-by-name semantics
I’ve been playing around with call-by-name semantics recently, and they’re kind of interesting. This post is about function calling behaviour, and I’m not an expert in the field, so I apologise in advance if I get some of this wrong. (Please point it out to me if I do.)
Most programming languages use call-by-value or call-by-reference semantics, or some combination. Under call-by-value semantics, when calling a function, each argument passed to the function is first evaluated. The values are then supplied to the function. So, for example, using a lisp-like language I’ve been playing with, here is a definition of a function called add1. It takes one argument, named lhs. When it’s called, it adds 1 to its parameter and returns the result.
(def add1 (lhs) (
(+ lhs 1)))
If you were to call it like this:
(add1 (* a 2))
… then, under call-by-value semantics, here’s what happens
- The expression (* a 2) is evaluated, yielding an integer (presumably).
- That integer is passed to “add1” and bound to “lhs”.
- add1 executes, adding the value of lhs, which is just an integer, to 1.
Call-by-name, however, behaves differently. Under call-by-name, function arguments are not evaluated immediately prior to the function call. Instead, the function can choose to evaluate them whenever it likes — it can also not evaluate them, or it can evaluate them more than once. Here is what happens during a call to to add1 if you rewrite it to use call-by-name semantics:
- The expression (* a 2) is compiled to a thunk, which is a parameterless closure — it’s a callable thing (i.e. it is code which produces a value), which retains the scope of wherever it was defined.
- A pointer to the closure is passed to add1.
- add1 evaluates “lhs”, which results in an integer.
- add1 adds the result of the evaluation to 1 and returns it.
On the face of it, this seems a lot more work for little gain. But thunks capture the scope of wherever they are defined, which means you can do very cool things. For example, you can implement iterators by having your expression return different things each time it’s evaluated. You can also implement control structures. For example, logical AND and OR are short-circuiting operators, which means they don’t evaluate their second parameter if they don’t need to. So you could implement them as taking their second parameter by-name. Here’s an example for “or”, where “>” is syntax for by-name calling, and “if” takes three arguments, being an expression, a list of expressions to evaluate in the true case, and a list of expressions to evaluate in the false case:
(def || (lhs >rhs) (
(if lhs (true) (if (rhs) true false))))
Note that rhs has parentheses around it to evaluate it, whereas lhs doesn’t.
Of course, what actually gives call-by-name its power is closures. But it’s quite interesting to see that call-by-name gives you quite a lot of the the same power without ever exposing closures to the programmer. By-name parameters let the function author choose whether arguments are evaluated eagerly or lazily.
There are two downsides to call-by-name.
Firstly, it’s quite a lot of overhead. Some of this can be ameliorated in the compiler, but I do recognise that “this isn’t a problem given a sufficiently powerful compiler” is a hymn which has been sung for a long time now.
Secondly, it’s potentially terribly confusing if you don’t realise what’s going on. For example, if you pass a side-effect-generating argument as a by-name parameter, then it will possibly be evaluated more or fewer times than you’d like. That seems fine for implementing simple, well-known things such as short-circuiting Boolean operators, and even for implementing complex, well-known control structures such as, for example, generators, but it’s probably not really a good idea for any other reason.
ALGOL was entirely call-by-name. Simula and Scala support it in roughly the above way (by annotating function arguments). Someone on the c2 wiki reckons that the C preprocessor is an extreme form of call-by-name. And of course you get some approximation of it in any language which lets you define closures.
Fri
Apr 11
Apr 11
Walter Bright on making programming languages
Hacker News has been on a bit of a Walter Bright (creator of D) festival recently, which is fine as he seems pretty great. Two articles of his from Dr. Dobbs:
So you want to write your own language?: “Redundancy is important” — Walter makes the point that a truly non-redundant syntax would mean that anything was valid and it would be impossible to generate error messages. So syntax redundancy is actually very useful. He also recommends not using a parser generator, also in the name of good error messages: parser generators aren’t very good at them. (I’d argue that hand-written parsers aren’t usually very good at them either but I guess you probably do have a better chance of adding them.) Other interesting parts of this article are error-message poisoning (he’s big on error messages) and the concept of lowering as proof of design (and a way to simplify the implementation).
How I came to write D: "In 1999, I decided I was retired and spent about six weeks watching TV until I thought I'd go mad.” (This isn’t what motivated him to write D, it’s what motivated him to stop not writing D.)
Fri
Jan 24
Jan 24
AOSP: emulator: don't copy the system image
The Android emulator seems to insist on copying the system.img file somewhere else (into /tmp/emulator-$USER on my system) before starting up. This is pretty annoying because the system.img file is 550 megabytes and it takes a while to copy.
I haven't tested this for very long, so maybe it will break everything. As a precaution, you might want to remount as ro before quitting the emulator if you make any changes to /system (i.e. if you have previously done an adb remount): adb shell mount -o remount,ro /system.
The code doesn't quite know what it wants: there is the concept of an “initial system image” and a “rw system image”. If you create a file called system-qemu.img in the same directory as your system.img (i.e. in out/target/product/generic-whatever/) (or do what I did, and ln -s system.img system-qemu.img) then one part of the emulator will be happy to proceed without an initial image, using system-qemu.img only… but the Android initialisation portion will complain that there is no initial system image!
I guess all of this makes sense if you're supporting AVDs and don't want the system image corrupted, but if you're actually working on the system image it's a bit of a time sink.
You don’t need an initial system image. If you screw up the rw image you can fix it using make snod. To stop the complaints:
aosp/external/qemu$ git diff
diff --git a/vl-android.c b/vl-android.c
index 4b0c991..3b35a63 100644
--- a/vl-android.c
+++ b/vl-android.c
@@ -3601,7 +3601,7 @@ int main(int argc, char **argv, char **envp)
pstrcat(tmp,sizeof(tmp),",initfile=");
pstrcat(tmp,sizeof(tmp),initImage);
} else {
- PANIC("Missing initial system image path!");
+ VERBOSE_PRINT(init, "No initial system image specified. Ho hum");
}
if (android_hw->hw_useext4) {
/* Using a nand device to approximate a block device until full
I haven't tested this for very long, so maybe it will break everything. As a precaution, you might want to remount as ro before quitting the emulator if you make any changes to /system (i.e. if you have previously done an adb remount): adb shell mount -o remount,ro /system.
Thu
Jan 23
Jan 23
WhatsApp: fake contacts
(I haven’t tried it yet, but I want to)
Tue
Dec 31
Dec 31
Five-minute AOSP hack: remove proximity sensor support
I recently dropped my Nexus 4 and broke its LCD. If replacing this £85 part wasn’t annoying enough, I also managed to lose the tiny rubber part which makes the proximity sensor work. Without it, the LCD turns off, and stays off, during phone calls. (Actually, I didn’t break the LCD — I just cracked the front glass — but I had to buy a new LCD + glass + digitiser assembly anyway.)
Fortunately, the proximity sensor sucked even before I broke it. :) I don’t press phones right up to my face, so talking is often a flickery screen-on, screen-off business anyway. So I hacked AOSP to ignore any hardware-supported proximity sensors.
With this change, you can control the LCD normally using the power button, even during phone (or Skype, etc) calls.
wzdd@ubuntu:~/aosp-nexus4/frameworks/base$ git diff
diff --git a/core/java/android/hardware/SystemSensorManager.java b/core/java/android/hardware/SystemSensorManager.java
index 0204e94..9dd8d7f 100644
--- a/core/java/android/hardware/SystemSensorManager.java
+++ b/core/java/android/hardware/SystemSensorManager.java
@@ -265,7 +265,7 @@ public class SystemSensorManager extends SensorManager {
Sensor sensor = new Sensor();
i = sensors_module_get_next_sensor(sensor, i);
- if (i>=0) {
+ if (i>=0 && (sensor.getType() != Sensor.TYPE_PROXIMITY)) {
//Log.d(TAG, "found sensor: " + sensor.getName() +
// ", handle=" + sensor.getHandle());
fullList.add(sensor);
Wed
Oct 30
Oct 30
Five-minute AOSP hack: dismiss voicemail notification
My Android device (a Nexus 4) won't let me dismiss the voicemail notification icon without actually clearing the voicemail. This is pretty annoying, particularly since either my phone provider (Three UK) or my device sometimes gets it wrong and tells me that I have voicemail when I don't.
If you're compiling your version of Android from the AOSP source code (and I realise this means almost nobody) you can change this by removing the piece of code in the phone app which tells Android not to let you dismiss the notification. Here's a patch against 4.2.2:
wzdd@ubuntu:~/aosp-nexus4/packages/apps/Phone$ git diff
diff --git a/src/com/android/phone/NotificationMgr.java b/src/com/android/phone/NotificationMgr.java
index 42dcdb6..906ba61 100644
--- a/src/com/android/phone/NotificationMgr.java
+++ b/src/com/android/phone/NotificationMgr.java
@@ -1283,7 +1283,7 @@ public class NotificationMgr implements CallerInfoAsyncQuery.OnQueryCompleteList
if (vibrate) {
notification.defaults |= Notification.DEFAULT_VIBRATE;
}
- notification.flags |= Notification.FLAG_NO_CLEAR;
configureLedNotification(notification);
mNotificationManager.notify(VOICEMAIL_NOTIFICATION, notification);
} else {
Remember to envsetup and lunch. Then you can patch and "mmm packages/apps/Phone", then copy the new Phone.apk (from out/) to the device.
4.4 update: For Android 4.4, it all changed:
- Modify packages/services/Telephony/src/com/android/phone/NotificationMgr.java
- mmm packages/services/Telephony/
- Install out/target/product/hammerhead/system/priv-app/TeleService.apk
Mon
Apr 1
Apr 1
KeePass NFC: Unlock your KeePassDroid database with NFC
I'm pleased to announce KeePassNFC, a stand-alone application which lets you use a rewritable NFC tag to unlock your KeePassDroid database. This is a follow-up to KeePassDroid: NFC Support (this is a better implementation of that same idea) and Idea: an NFC authentication scheme.
To use it:
- Install KeePassNFC: Play store
- Set up your NFC tag
- Unlock your password database to your heart's desire
To set up the tag, launch KeePassNFC:
Here you must select a database, and then, optionally, a keyfile and password. The options are hopefully self-explanatory. Press "Write NFC" and hold an NFC tag near your device to program it, and you're done.
Now, holding the tag near your device will automatically load KeePassNFC, which will decrypt your password using the data stored on the fob and launch KeePassDroid.
KeePassNFC is open source, and you may download the source code.
Questions:
- Why two separate apps? KeePassDroid has very few application permissions, which is good security practise. Using two separate apps means not having to give NFC permission to KeePassDroid itself.
- How secure is it? Reasonably. The NFC tag stores only random numbers, and the password itself is encrypted with those numbers. So an attacker would have to scan your NFC tag and either steal or root your Android device to get your password. If you suspect that your NFC tag has been read, you can use KeePassNFC to re-write it with new random values, rendering the previous information useless.
Update: A previous version of this blog included a custom version of KeePassDroid. I'm pleased to say that the current version of KeePassDroid in the Play store incorporates the required changes (technical: it supports being supplied a database password via an Intent), so my custom version isn't required. For the curious: here is the source code for the required changes.
This NFC implementation grew out of discussion on the KeePassDroid forums. You can view and add to that conversation at Google Groups' KeePassDroid forum.
Sat
Mar 9
Mar 9
KeePassDroid NFC support
Update: I reimplemented this as two separate apps, which is a bit nicer from a security perspective. Write-up and APK for the new version.
Just as I threatened in my previous post, I've implemented NFC support in KeePassDroid. This means that you can create an NFC tag which decrypts your database, no password required.
You'll need a spare, writeable NFC tag, such as one of these.
You'll also need to use my version of KeePassDroid:
KeePassDroid.apk | Source code on Github
Select a database as normal. When you get to the password screen, enter your password and press the new "NFC..." button.
You will be taken to the NFC writing activity:
Select "Write NFC" and place an NFC card on your device.
When you're done, you should be able to scan your NFC card and go directly to your password database from anywhere in Android.
Details on the security of this scheme are in the previous post. The short version is that it's okay if your NFC tag gets stolen or copied, and it's okay if your phone gets stolen, but if your NFC tag gets copied and your phone gets stolen you have a problem.
Note that you can rewrite the NFC tag as many times as you like. Each time you do, a new encryption key is generated. So if you lose an NFC tag, just write a new one and the previous tag immediately becomes useless.
Comments, questions, and bug reports welcomed. This has been minimally tested (on a Nexus 4) and I make no guarantees that it does anything at all. :)
Of course, I didn't write KeePassDroid. It's by Bryan Pellin and a lot of other contributors. Official site.
Good luck and enjoy!