More of the same?


Changing the encryption pass phrase on Cyanogenmod 13 / Marshmallow

Filed under: Android, Software — Tags: , , , , , , — _ds_ @ 19:56

I’ve recently been looking at improving my phone’s security configuration, and I found some advice regarding filesystem encryption which applied to Android L but not to M – and some reports of problems with this advice when applied to Cyanogenmod 13, which led me to information about a bug which stopped this working. I discovered that it was was fixed in mid-February, but my CM13 installation predates that: this meant that my phone, until shortly before writing this, never asked me for anything other than the usual at the lock screen.

So here’s a quick guide to changing your phone’s filesystem encryption pass phrase. You may know this as the boot pass phrase; in one important way, it is indeed exactly that, so I’m going to call it that.

This information is valid for Cyanogenmod 13, and may also be valid for other modified OSes and for stock Marshmallow.

Keeping lock screen and boot pass phrases the same

This is easy. Just set the pass phrase for the lock screen and you’ll be asked whether you want to use it at start-up. If you choose not to then any existing boot pass phrase will be removed and you won’t be asked for one after rebooting.

Making them different


I’m assuming a certain amount of technical capability here (if I didn’t, this article would be about three times the size – at least).

  • Developer mode is enabled.
  • Access to a root shell on your phone. It doesn’t matter whether this is via a terminal app or via ADB.

CM13 has a terminal app built in. You can enable it and allow root access via developer options once developer mode is enabled.

Back up first!

In case of mistakes, make a backup. Make sure that it’s stored somewhere other than on the phone. If you make a mess of changing the pass phrase, you’re going to have to wipe and re-install.

A good way to create a backup is to run adb backup -apk -all -shared -system, which will create a file named “backup.ab”. You can later restore this using adb restore backup.ab should you need to.

As I use TWRP for recovery and update purposes, I created my backup using that and copied it from my phone by using “adb pull /sdcard/TWRP/BACKUPS .”. Had there been a problem, I’d flash an appropriate stock Marshmallow image, re-install TWRP, start that up then push the backup directory back to my phone then tell TWRP to restore the correct backup from that.

Making the change

You’ll need the current boot pass phrase. This is whatever you type in when asked “To start Android, enter your password”; if your phone doesn’t ask then it’s using the hard-coded default, which is “default_password”.

Choose a pass phrase. The usual advice about something easy to remember and hard to brute-force applies. Do not choose an empty pass phrase!

“default_password” and “new_password” as appropriate (no encoding needed, except perhaps a \ or two in specific circumstances):

vdc cryptfs changepw password 'default_password' 'new_password'

Or, if you’re setting a PIN:

vdc cryptfs changepw pin 'default_password' 'new_password'

This will take somewhere between 2 and maybe 10 seconds to run, depending on your phone. If all is well, you’ll get this response:

200 0 0

If not, something’s gone wrong. I don’t have sufficient information about errors here, unfortunately. Anyway, if the output differs, retry the command, first checking that you entered it correctly; otherwise, you’ll have to look up result codes from that command and decide from that.

Reboot and test

Now. Here’s the fun bit. Reboot your phone. You’ll fairly quickly be asked for the new boot pass phrase, so enter it. All being well, your phone will continue to boot and you’ll end up at the lock screen as normal.

Remember that you’ve not changed anything which affects the lock screen: you can unlock exactly as you did before making the boot pass phrase change.

Oh, and don’t forget that pass phrase…

Other notes

It appears to be possible to set the pass phrase to a pattern. I’m guessing that the pass phrase, in this case, would be a sequence of digits describing the dots to be joined, and in what order.


“Okay, Google” without en_US

Filed under: Mobile, Software — Tags: , — _ds_ @ 14:51

This hack works for stand-alone Google search but not the integrated Google Now in the Nexus 5 launcher. (It was developed and tested with English (UK) on my Nexus 4 running Cyanogenmod 10.2.)

First, make sure that the voice search data for your language is installed and that English (US) is up to date.

Then, root shell time. Run the following commands, replacing en-GB with the appropriate directory name if you need to

# cd /data/data/
# ls ../en-US

If that second command succeeds, the next step is this:

# ln -s ../en-US/dnn ../en-US/*hotword* ../en-US/phone* .

Otherwise, this:

# ln -s /system/usr/srec/en-US/dnn /system/usr/srec/en-US/*hotword*
        /system/usr/srec/en-US/phone* .

When done, find -type l should list 9 symlinked files.

Of course, ideally this wouldn’t be needed. Maybe Google will, one day, get round to adding hotword detection to other languages and localisations…?

Update (2014-04-26)

A little belated with this, but anyway…

Google have added “okay, Google” to various other English localisations and a few other languages this year. It’s now recognised for British English (which means that I get to use it without hacks), Canadian English, Australian English, German and French.

If your language still isn’t supported (and the above procedure doesn’t help), here are two other sites which can help (and if they don’t, search instead).


x32 isn’t x86

Filed under: Hardware, Linux, Software — _ds_ @ 17:41

There’s a shiny new possibly-to-be-in-Debian architecture named x32. This is, basically, amd64 (x86_64) with a 32-bit address space and 32-bit long integers.

Unfortunately, people have been referring to i386 (x86) as x32, presumably influenced by a certain monopolistic company calling amd64 ‘x64’ – I’ve seen search results including “Ubuntu 10.04 x32”. If x32 gains significant traction (looks like it could be gaining that now) and gets into Debian proper, and subsequently also derivatives such as Ubuntu, then this is going to be a little bit interesting…


What’s wrong with Google+ on Android…?

Filed under: FAIL, Miscellaneous, Mobile, Software — _ds_ @ 02:45

What I don’t like about the ‘new’ +Google+ UI, having just upgraded downgraded from the last version for Android which supported Incoming (due to them finally having switched it off):

  • Circles menu is… inconvenient.
    • Being able to select which circles are shown there is useful, particularly if you have many. Alternatively, being able to mark some as ‘important’ (regarding placement in that menu) would work – and I include the pseudo-circles in this.
  • Pictures and videos are initially confusing, being above the name and posting text.
    • In portrait mode, they look like they’re associated with the content immediately above.
    • In landscape mode, the avatar and name appear misplaced.
    • The avatar shouldn’t overlap them – as is, it looks bad. I’d put it, name, date etc. above.
  • The avatar looks bad.
    • It should match desktop browser G+, i.e. not clipped to a circle.
  • In landscape mode:
    • Posting arrangement is strange. Should be vertical.
    • Notifications are badly placed. I didn’t find them until I saw the side menu in portrait mode.
    • Viewing a single thread makes bad use of the available space.
      • Here, it’s restricted in width to the height of the display (more or less). It needs to use the full width of the display (which, here, is 800×480).
    • Adding a comment doesn’t work well.
      • This is due to the above thread view limitation.
      • Portrait mode is better for display reasons, but this makes soft keyboard rather more awkward (narrow buttons).
      • Strangely, given this, making a new posting works as well as it previously did in landscape mode.
  • Nothing to indicate that there’s more text in a posting (in the stream view).
  • Still no indication of struck-through text.
  • No scroll bar in the stream view? Weird.
  • ‘Swipe to switch circles’ is missing.
  • ‘What’s Not’ is present.
  • Incoming is missing (but I expected that).
    • I don’t expect to go through each and every ‘not yet in circles’ profile to see what’s there – that’s what Incoming’s for.

The UI in the last version for Android to support Incoming works. It’s nice and clean. This one’s… less clean.

I’ve reported most of this little lot via the G+ feedback page (in smaller chunks due to the paltry 500-character limit). Hopefully we’ll see some improvements, including the return of Incoming. But somehow I think that that’s not going to happen…

Finally, according to the ‘city-level’ location, I’m in Northern Europe. While technically true, it often makes attaching my location rather less than useful.


Google+ – Incoming not merely hidden, but completely removed?

Filed under: FAIL, Miscellaneous, Mobile, Software — _ds_ @ 22:58
Android G+ screenshots showing nothing found

Screenshots from the last Android Google+ app to support Incoming, showing “no posts found” (but there should be content). Taken on 2012-08-31.

Seems that Google+ have decided to cut off all but Nearby for those of us who still have the last version (on Android) to support Incoming.

This is Bad and Wrong.

Now I can’t easily and conveniently dip in and see what people who’ve circled me (but I’ve not circled back) are posting. There was a suggestion of looking at each individual profile to see what’s posted, but that’s repetitive, time-consuming and error-prone.

I might have decided to see what’s being shared for a while after being circled (i.e. not just what’s public) before deciding what to do. Incoming allowed this in a convenient way.

Well done, Google+, for removing useful stuff

I am now forced to downgrade to a newer version of the Android G+ app if I want something which works.

(Also, scrapbook pictures. Yes, I use them. No, I will not choose to use cover images instead. Yes, I want to use them on one of my pages, but somehow that got downgraded to cover image and I can’t revert that – THAT IS JUST PLAIN BROKEN.)

(You may pretend that the above text is liberally padded with expletives. That would be a lot closer to what I’m thinking.)


Geolocation: how to fake it or fix it in Chromium

Filed under: Desktop, Mobile, Software — _ds_ @ 14:06

After a little searching, I’ve found out how to set my location for desktop browsers without involving Google. There is sufficient detail there for any competent person to be able to appropriately configure Firefox, but it’s a bit lacking for Chromium and Google Chrome.

Quoting from the above page:

The way these geolocation services work is by requesting a file from Google which then responds with your location in JSON format. To fake this in Firefox, you can create a file on your computer with this text:

{"location":{"latitude":48.861426,"longitude":2.338929, "accuracy":20.0}}

You can find this location by locating it in Google Maps or any other maps program that supports Latitude and Longitude. Google maps generates a link that looks like the following:,2.338929&spn=0.011237,0.027874&z=16

In this case the first number is the latitude and the second the longitude.

The full name of the file should look, on GNU/Linux, something like /home/user/.config/location.txt.

To make Chromium respect your chosen location, you need to load ~/.config/chromium/Local State (on your common or garden GNU/Linux distribution etc.) and look for "geolocation" (complete with quotation marks); replace with the full path name of the file containing the JSON text describing your location, converted into a URL, so you’ll need to prefix with file:// and quote certain characters, e.g. spaces become ‘%20’ and, on Windows, backslashes become forward slashes. Using the above example name, you’ll end up with file:///home/user/.config/location.txt. Now save the file.

Do this while the browser is not running, else it’ll take no notice of your changes and will happily overwrite them.

While I couldn’t say for Google Chrome, I do expect that the only difference from Chromium is the file which you need to edit.

This allows me to properly attach my location to Google+ postings without having to rely on my phone, but it’s limited: I do still need to use the mobile browser version of G+ (which works fine in desktop browsers) if I want more control over the location, for example to use what Google call “your city-level location”.

(There is one error in the how-to, though: the example JSON text contains an extra number just before “longitude”.)


Wide browser windows

Filed under: Software — _ds_ @ 13:54

Is it just me, or do any of you lot hate wide browser windows too?

I’m putting up with horizontal scrolling (or zooming out, in some cases) here so that I can have the window width which I want – which allows me to open an X terminal alongside it, as it happens…

800 pixels is a reasonable minimum width, and anybody who thinks that 1024 pixels is a better choice or, worse, lets text be reformatted to the window width no matter how wide (without making some effort to constrain it to something reasonable) should be… I don’t know. Suggestions?

What has to be remembered here is that there are many devices out there with small displays:

  • Netbooks with 7″ panels
  • Smartphones

These typically have displays which are 800 pixels by 480 pixels (or possibly 480×800), and while the phones may be redirected to ‘mobile’ versions of the content, both they and netbooks may display the full site. It is true that many browsers, these days, have a zoom function, but it’s possible that the content may be rendered too small to read if the user has to use this to shrink it to fit the available screen space. (I can manage with quite small text, but that doesn’t mean that I necessarily want to.)

I mentioned, above, wide text. It’s particularly annoying to have to scroll back and forth horizontally just to be able to read the text (but again, zoom functionality); there are times when I’ve had to zoom out when reading a forum because of some large screenshot which the poster didn’t think to thumbnail. This is particularly fun when the screenshot is 1920×1080; consider that the largest monitors here are 1280×1024.


What to do?

Web designers: flexible width wins. Primary content which fits within a column at most 800 pixels wide wins, even if it loses in other ways. It may even be necessary to enforce a minimum width to prevent, for instance, a column of single-word lines… But, if you must allow it to be wider, constrain it to some suitable readable maximum. The CSS2 properties min-width and max-width help with these.

And, for un-thumbnailed images: one possible solution is max-width: 100%; which will, on most browsers, prevent it from widening its containing box; and another is overflow: auto; which may cause scroll bars.

It’s a minefield out there ☺


xine and WebM

Filed under: Media, Software — _ds_ @ 20:37

I’ve just this evening been pointed at WebM. It’s looking like the video format (VP8) will need a small amount of work to be supported in xine, but the container format (a Matroska subset) is essentially already supported, requiring only minor tweakage.

With any luck, it’ll take but a few days to sort out the VP8 support, so it should all be ready in plenty of time for 1.1.19 (which, as usual, will be ready “when it’s ready”).


Oh, for a user with clue… (or Lowest Common Documentation)

Filed under: Documentation, Software — Tags: , , — _ds_ @ 01:05

Now that that’s grabbed your attention… 🙂

Fortunately, many do seem to have some clue, or at least the capacity to absorb some clue, which is good; these ones, as we all know, are usually easy enough to deal with even when they file reports about distributor-specific bugs in the upstream bug-tracking system, sometimes without any indication whatsoever of what they’re actually using. (Clearly, we upstream people know exactly what the bug reporter is using and know exactly what differences are present in each and every distributors’ patched sources.)

I saw an example of this recently. It turned out to be a distributor-added bug: a wrapper script which used $@ instead of "$@", and those of us who grok shell stuff know what that means. (Oh go on, throw a filename containing a space at it. You know that you want to. Waka waka waka.)

But then there are ones like this…



xine-lib upcoming: VDPAU and BluRay

Filed under: Media, Software — Tags: , , — _ds_ @ 21:41

For those of you who regularly taint your kernels with nVidia code, VDPAU support has been merged into xine-lib. I created a copy of the xine-vdpau repository yesterday, first importing it (up to r275)¹ into a local Mercurial repository with the help of hgimportsvn and hgpullsvn (hgsvn).

Since the VDPAU support requires incompatible ABI changes, it needed to be ported to xine-lib 1.2; this is fine because the 1.2 API and ABI are not fixed yet². Consequently, it’s still a bit experimental, so it’s in a new (and temporary) 1.2 repository; it’ll go into the main 1.2 repository in due course.

(I can’t test the VDPAU code myself. I don’t have any nVidia graphics hardware, and nor do I want any: I sometimes use 3D and I don’t want the taint preventing me from upgrading to newer kernels as and when I choose and with whatever configuration options are appropriate for the hardware and I want to be able to report and occasionally fix kernel bugs without having to reboot without re-tainting the kernel just to get trustworthy kernel logs… so here’s hoping that VDPAU becomes supported by open-source drivers, and not only for nVidia hardware…)

Also, we’ve also got some basic BluRay support going into the next release in 1.1.17, which was released on 1 December. It won’t play discs as yet (and that probably won’t land in 1.1), but it should be able to handle decrypted files reasonably well. (No, I’ve not been able to test this either – yet. M2TS files are definitely playable, at least from hard disk.) There are still things missing; I’m currently expecting more patches.

Finally, if anybody wants to contribute to xine-lib and, hopefully, get involved in developing it (and I don’t just mean new features), by all means, send patches, fix bugs, acquire fame and fortune, get your name in lights the authors list…

¹ r276, the current revision at import time, is a bug fix and has nothing to do with VDPAU. As such, it went directly into 1.1.
² They will be when 1.2.0 is (eventually) released

Older Posts »

Blog at