I don't think so
http://www.androidcentral.com/android-advanced-usb-otg-nexus-4
http://www.amazon.com/Micro-Cable-Power-Samsung-AtomicMarket/dp/B009YPYORM/

I'm confused as to why the PIN code is entered into the wallet application, rather than the device itself - surely that increases the risk of a successful physical theft. Assuming the PIN code is not changed on a regular basis, using the device on an infected workstation would essentially render the PIN code useless if attacked through a combination of both digital and physical means. On the other hand, if the code was to be entered on the Trezor itself, such a scenario is not possible unless the PIN code is provided by the owner under duress.

Whoa, weird.  I never noticed that.  There is actually two slashes prefixing each line in the HTML, but it very much looks like a single slash when the page is rendered by Chrome (at least).  I'll play around with it.

Though, the entire website will be overhauled, soon, anyway

Don't forget the -logfile argument.  Not that it will help run armory.  I'm not sure what the problem is, but I had all sorts of Armory problems until I ran bitcoin-qt first then opened armory (disable the appropriate setting in armory).  Maybe loading them separate will help diagnose your issue.

After the BFL debacle, I'm very wary of pre-ordering anything BTC-related, especially since this isn't slated for release until October / November.

Why pre-order? These things can't be difficult to make - once they have made one - they can make zillions. Pre-order queues are only their for the companies' benefit:

1) Cash in the bank to fund development (plus interest)
2) To judge customer demand

And of course if its a scam, its just a way of taking people's money, never to be seen again. Not saying these are, just a fair % of bitcoin services have been scams.

I'd love a hardware wallet, don't get me wrong. But I'll buy mine when they are available and have been reviewed by peers. Customers gain nothing from pre-ordering, you are just risking your own capital for no reward.

If they wanted to reward customers that pre-order, they would offer incentives such as a discount or "limited edition" for first 100 orders.

Well he already said Armory is ready and Electrum is coming.

Unfortunately, it can't be that simple.  In fact, even for the simple case you describe, it is dramatically more complex.  Why?  Allow me to explain how offline wallets work in Armory, and why data sizes will never be that small.

Satoshi decided not to include the input values of the inputs being spent in the transaction inputs or explicit declaration of the fee in the transaction data to be signed.  This sounds arbitrary, because that information is located in the blockchain, so the node only needs to go look it up the OutPoints in the blockchain to know.  Right?   Well, offline wallets can't do that.  And part of the value of Armory for offline transactions is that the offline computer doesn't need the blockchain.  You might say "okay, well just throw that information in with the tx to be signed so that the offline computer knows."  If only it were that simple...

gmaxwell expressed concern, rightly, that if your online computer is infected, the next transaction you make might have a devastatingly malicious modification:  it completes your transaction, but sends the rest of the balance of your wallet to transaction fee.  But you don't know this, because the attacker also modified the "supplementary" information in the transaction, so that the offline computer thinks it's only signing a 1.01 BTC input, with 0.5 to recip, 0.5 to change, and 0.01 to fee.  But the attacker actually put a 300 BTC input on the tx-to-be-signed, but put in the "supplemental" information that the input is only 1.01 BTC.  The result will be the offline computer showing you that you are sending 0.5 BTC to the recipient with 0.01 fee.  But when you send the transaction, it's actually 299 BTC fee.

THEREFORE:  my BIP 0010 "protocol" includes the entirety of each transaction which supplies inputs to the transaction-to-be-signed.  For each input in the tx-to-be-signed, Armory sees the OutPoint (txHash, txOutIndex), and verifies that it was passed a transaction with the same TxHash.  From that transaction, it can verify the value of the input and the final tx fee. 

• If the attacker changes the recipient or the amount sent to recipient -- the user should notice because they can see the list of recipients and values before they sign it
• If the attacker changes the value specified on the supplementary tx -- the suppl tx hash will no longer match the OutPoint on the tx-to-be-signed, verification will fail
• If the attacker changes the supplementary tx value and the OutPoint hash -- the transaction is no longer valid, because that OutPoint doesn't actually exist

In fact, that pretty much clears up every possible avenue for tricking the offline computer.  Now, every piece of important information is verifiable by the offline computer.  If there is manipulation, the either the tx won't be valid, or the user will notice when they look at the transaction details.

---

Okay, so that gets us back to the original question of "how much data do we have to transfer between online and offline computer?"  Unfortunately, the simplest case is not relevant to this discussion:  you have to design the protocol around the 99.9'th percentile case:  which is the case that someone has an offline donation address that they want to clear out.  Let's say they have received 40 donations.

So the transaction will have 40 inputs and 2 outputs. 

The bulk of the data is the supporting transactions which can be anything (transactions created by the donors).  Each one itself may have dozens of inputs, and the signatures are necessarily included!  Let's assume 30 "standard" supporting transactions, and the other ten have 10 inputs each.

• Tx-to-be-signed:  30 inputs (unsigned) of 48 bytes each, and two outputs of 40 bytes each = 1.5 kB 
• 30 standard supporting tx:  250 bytes each = 7.5 kB
• Ten larger tx:  180 bytes for each input (signed), so about 2 kB each = 20 kB

So the online computer needs to communicate 30 kB to the offline computer in this case.  And the offline computer needs to transfer back 30 signatures, which is, at best, 2 kB at a minimum.  The "maximum" a QR code can handle is 3 kB of binary, so that's 10 QR codes from online to offline.  1-2 QR codes the other way.

So the protocol should handle 30 kB without causing a lot of pain.  If the user has to wait a little bit because of a slow communication rate, that's okay because this case is abnormal and waiting 60s for the transfer isn't the end of the world.  But if they can't succeed because it's confusing and they can't figure out how many and which QR codes have been scanned, or which webcam they're supposed to be pointing at which device, and frustrated there are wires everywhere, etc.  Then there's a problem...

As you can tell, I'm very sensitive to the "convenience" of a given feature.  I think the biggest barrier to security is convenience -- users just don't use things that are inconvenient.  But I also don't want to sacrifice security, at all, no matter how much work it is for me.  Which is why there are so many recommendations here that are great, but don't quite the bill.  But I'm pretty sure a solution exists where the user can actually have both, in which case everyone wins

But Armory's offline signing isn't standalone.


It still needs the connected instance to create the unsigned transaction which is than brought over to the offline system for signing.

And here's the reason you wouldn't want to trust the merchant to build the unsigned transaction for you:
 - http://bitcointalk.org/index.php?topic=68482.msg1187718#msg1187718

I haven't looked at this closely but the approach is interesting

VisualBTC - Android-based hardware offline wallet using animated QR codes
 - http://bitcointalk.org/index.php?topic=210371.0