開始使用囉，5s

電力也沒有很優呀。
充了一晚上的電，100% 開始...
開著 waze, 以前 tx 用掉 20 幾 % 的路程。
5s 用掉 30 出頭，剩下 68%.

然後就開啟 wifi 了。
就看 一些 social network app: g+. fb. twitter, feedly.
從 9:00 用到 11:30。
掉到 10% 警告。

也就是說用 wifi 瀏覽網頁，3hr 用掉 58%.

感覺跟 TX 一樣呀。

UI 不用說，這種平面的設計，button, 訊息 區分得不清楚。
所以有時候看到個 "好" 字，都不知道是不是可以按的 button。

唯一比較厲害的有兩部份：

• 反應：拍照，啟動 ap都是立即動作。
• touch keyboard : 雖然螢幕小，但是按鍵都正確。

注音輸入真的超。超。超難用。。。

"No such file or directory" -- 可是 file 明明就在

執行一個程式，卻說 :

/bin/sh: no such file or directory

這是因為 loader 無法載入的關係。
並不一定是找不到檔案。

ref: http://unix.stackexchange.com/questions/13391/getting-not-found-message-when-running-a-32-bit-binary-on-a-64-bit-system/13409#13409

When you fail to execute a file that depends on a “loader”, the error you get may refer to the loader rather than the file you're executing.

The loader of a dynamically-linked native executable is the part of the system that's responsible for loading dynamic libraries. It's something like /lib/ld.so or /lib/ld-linux.so.2, and should be an executable file.
The loader of a script is the program mentioned on the shebang line, e.g. /bin/sh for a script that begins with #!/bin/sh. (Bash and zsh give a message “bad interpreter” instead of “command not found” in this case.)

The error message is rather misleading in not indicating that the loader is the problem. Unfortunately, fixing this
would be hard because the kernel interface only has room for reporting a numeric error code, not for also indicating that the error in fact concerns a different file. Some shells do the work themselves for scripts (reading the #! line on the script and re-working out the error condition), but none that I've seen attempt to do the same for native binaries.

ldd won't work on the binaries either because it works by setting some special environment variables and then running the program, letting the loader do the work. strace wouldn't provide any meaningful information either, since it wouldn't report more than what the kernel reports, and as we've seen the kernel can't report everything it knows.

This situation often arises when you try to run a binary for the right system (or family of systems) and superarchitecture but the wrong subarchitecture. Here you have ELF binaries on a system that expects ELF binaries, so the kernel loads them just fine. They are i386 binaries running on an x86_64 processor, so the instructions make sense and get the program to the point where it can look for its loader. But the program is a 32-bit program (as the file output indicates), looking for the 32-bit loader /lib/ld-linux.so.2, and you've presumably only installed the 64-bit loader /lib64/ld-linux-x86-64.so.2 in the chroot.

You need to install the 32-bit runtime system in the chroot: the loader, and all the libraries the programs need. On Debian amd64, the 32-bit loader is in the libc6-i386 package. You can install a bigger set of 32-bit libraries by installing ia32-libs.

這常常發生在， 64 bit 系統，沒有裝 32 bit library，在 run 32bit 執行檔時，...

build android with Ant

現在 各distribution 附的都是 ant1.9 (wheezy, 13.10..)
但是有附 ant1.7

安裝 distribution default ant :

apt-get install ant

之後 build:
產生 make file:

$ android update project --path .

build:

 $ ant release

       [dx]
       [dx] UNEXPECTED TOP-LEVEL EXCEPTION:
       [dx] java.nio.BufferOverflowException
       [dx]     at java.nio.Buffer.nextPutIndex(Buffer.java:499)
       [dx]     at java.nio.HeapByteBuffer.putShort(HeapByteBuffer.java:296)
       [dx]     at com.android.dex.Dex$Section.writeShort(Dex.java:818)
       [dx]     at com.android.dex.Dex$Section.writeTypeList(Dex.java:870)
       [dx]     at com.android.dx.merge.DexMerger$3.write(DexMerger.java:437)
       [dx]     at com.android.dx.merge.DexMerger$3.write(DexMerger.java:423)
       [dx]     at com.android.dx.merge.DexMerger$IdMerger.mergeUnsorted(DexMerger.java:317)
       [dx]     at com.android.dx.merge.DexMerger.mergeTypeLists(DexMerger.java:423)
       [dx]     at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:163)
       [dx]     at com.android.dx.merge.DexMerger.merge(DexMerger.java:187)
       [dx]     at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439)
       [dx]     at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287)
       [dx]     at com.android.dx.command.dexer.Main.run(Main.java:230)
       [dx]     at com.android.dx.command.dexer.Main.main(Main.java:199)
       [dx]     at com.android.dx.command.Main.main(Main.java:103)

google 一下：

• https://code.google.com/p/android/issues/detail?id=61710
• http://stackoverflow.com/questions/19727915/android-dex-gives-a-bufferoverflowexception

大意是說.. android sdk 的 Android SDK Build-tools 19 跟 22.3 版，只有y9測試過 build api 4.4，
所以 build 2.3 就會 fail 了。

所以解決方法就是安裝 Android SDK Build-tools 18.1.1 :

• 啟動 android sdk manager (console: $ android)
• Tools -- Android SDK Build-tools , check 18.1.1

裝完後，
再指定使用 18.1.1 來 build:
在 project.properties 加一行： sdk.buildtools=18.1.1

---

其他：

• using arnt to automate building android