I've been dealing with a nasty bug in Helium (formerly Carbon) since the initial release: The app icons that are saved to the SD Card during app backup pollute the user's Gallery. I tore my hair out trying to fix this, as this was the number one complaint about the app, including:

  • .nomedia file in all relevant directories. This does not work as of Android 4.0.
  • Naming the image as a hidden file by dot prefixing it, ie ".com.package.png"
  • Putting the hidden png file in a .nomedia directory.

Then the obvious solution hit me: look at the Android source code and see how the MediaScanner works, and figure out how to bypass it.

Digging through MediaScanner.java, I found that any file designated as "isNoMediaFile" would not be scanned. But, I didn't want to name the image.png files, .nomedia, as that is just hacky. Looking through the implementation of isNoMedia, I found that not just .nomedia files fall into this category...

Well, apparently '._' prefixed files are also considered "isNoMediaFile"! This is there because mounting the external SD card on a Mac often results in the Mac creating '._' files in various directories. This is the Mac convention for hidden system files, and Android needs to ignore those files as well!

So, the fix was to change "file.png" to "._file.png". Though, one should also keep a .nomedia file anyways, as this is the recommended practice, and it also ensures backwards compatibility with older versions of Android.

Although I consider it a bug that the MediaScanner is scanning directories with .nomedia files in them, I am relieved and happy to find a workaround.

Hiding Images from Android's MediaScanner<p>I've been dealing with a nasty bug in <a href="https://play.google.com/store/apps/details?id=com.koushikdutta.backup">Helium</a> (<a href="https://plus.google.com/103583939320326217147/posts/LUBoUuetNA8">formerly Carbon</a>) since the initial release:</p><p><a href="/post/nomedia" title="Read more of Hiding Images from Android's MediaScanner">read more</a></p>

Earlier this week, I met with some of the folks on the HTCDev team in Seattle to talk about supporting CyanogenMod and root users/developers.

We had a chance to discuss some of the misperceptions of both sides, and the conversation was enlightening. On the ROM community's end, there seems to be a misunderstanding of what "S-OFF" means; as there are a few issues being conflated here. So much so, that they recently released a S-OFF FAQ on their HTCDev portal about it.

There are two distinct concepts here:

  • Being able to flash a custom ROM (boot, recovery, system)
  • Being able to flash the black box partitions (bootloader, radio, trustzone, etc). This also enables carrier unlock via SuperCID.

The term "S-OFF" is specific to HTC's bootloader, and is now being generically used and misnomered across all Android phones. The HTC Dev Unlock tool (as of the One) allows a user to flash the partitions that are interesting to custom ROMs. A full S-OFF turns off all security, allowing flashing of the radio and bootloader (and switch carriers). The latter bits are complete black boxes to all developers, and are generally not very interesting. Anyone that is involved with the radio stack, etc, are most likely employed by either Qualcomm, Samsung, etc. There is no "radio" development in the ROM community.

In a previous post, I stated the that "...the HTCDev unlock on this device actually behaves properly, unlike its predecessors. It behaves like a Nexus device."

The HTC One is not S-OFF. But neither are the Nexus devices (Secure Boot, good luck flashing a "custom" radio image).

To put things in perspective (and these are my/CyanogenMod's opinions); I'm not particularly concerned about devices being S-OFF. Even if they were, I wouldn't want to (or be able to) make changes to the radio anyways. I do want my phones to be unlocked so I can flash custom firmware, and I can do that.

S-Off vs Unlocked, and flashing firmware<p><center><img alt="" src="/post-content/soff/soff.jpg"/></center></p><p><a href="/post/soff" title="Read more of S-Off vs Unlocked, and flashing firmware">read more</a></p>

A little over a year ago, I added 'await' support to node.js (Chrome V8). I had also planned on adding support for 'yield', but never got around to it. But last night, I needed a break from another project I'd been working on, and decided to try my hand at implementing 'yield'.

A-wait? What are you talking about?

A quick summary: await is a syntax/runtime feature from C# 5.0 that allows suspension execution of a function until a task (ie, a callback) is completed. The function does not block.

Here's an example of code without await. I want to download two text files in node.js, combine them, and return them to the caller:

Normal Code

Om nom nom, callback spaghetti!


What's this same function look like with 'await'?

Keep in mind, that 'await' does not block. It suspends execution, by turning everything below the await into the callback body. The 'await' is syntactic sugar. The two examples are essentially equivalent. You can think of 'await' as an asynchronous 'var' declaration.


Firefox has had 'yield' support (aka generators) since JavaScript 1.7, which was released in 2008. Though this is not part of the ECMA standard, it really ought to be.

The underpinnings of yield and await are essentially the same. They both, under the hood, are leveraging 'call/cc', short for call-with-continuation. The call/cc mechanism is what allows mid-function execution suspension and resume.

Generators are extremely powerful. They allow a program to create an iterator that evaluates the next result upon every iteration. Consider the following program written without generators. The entire fibonacci series (up to 10) is generated and returned up front:

Normal Fibonacci

Generator Fibonacci

In this generator example, note that the 'while' loop seems as if the program would continue infinitely... but it does not due to the 'yield' which suspends execution until the next iteration. The fibonacci series is generated on an as needed basis.


Chances of this being taken upstream are minimal. I imagine the V8 guys will eventually get around to doing their own proper implementation. Admittedly, my understanding of V8 internals and optimization is naive. And the node.js guys will want to remain on V8 proper. So, in the meantime, I'll continue maintaining this fork.

If you're a CoffeeScript fan and want similar functionality, you may want to check out IcedCoffeeScript. It brings async/defer to CoffeeScript.

How Can I Get This?!

My modified version of node.js/V8 is on Github. Make sure you check out the async-v0.10.x branch.

Hacking V8: 'yield' and 'await' in node.js<p>A little over a year ago, I <a href="https://github.com/koush/node/wiki/%22async%22-support-in-node.js">added 'await' support to node.js</a></p><p><a href="/post/yield-await-v8" title="Read more of Hacking V8: 'yield' and 'await' in node.js">read more</a></p>