Android SDK R20 の emulator でハードウェアキーボードが使えない (続編)

R18 に戻すというのは確かに簡単で確実ではあるんだけど、いつまでも古い revision を使い続けるのは忍びないので改めて調べてみたところ、hw.keyboard の値を yes にする方法を見つけました。hardware-qemu.ini を手で書換えてはいけなかったんですね。ちゃんと AVD Manager から設定しなくては。

  1. ADV Manager を起動。
  2. 対象の ADV を選択し「Edit...」をクリック。
  3. Hardware: 欄の「New...」をクリック。
  4. Property: 欄から「Keyboard support」を選択し「OK」をクリック。
  5. Hardware: 欄に追加された「Keyboard support」の「Value」カラムをクリックし「yes」を選択。
  6. 「Edit AVD」をクリックし確認ダイアログを「OK」で閉じる。
  7. 必要な ADV の数だけ上記を繰返したら ADV Manager を閉じて完了。

後は、ADB Manager から起動しようが、起動 option 付のショートカットから起動しようが、不通に実キーボードが有効になります。単純な話でしたね。
とは言え、これ程重要なことは release note なり README なりに書いておいて欲しいものですねー。R20 から初めて使い始めた人は、Android emulator ってソフトウェアキーボードしか使えないもんだって思い込んでしまってもおかしくないと思います。

Android SDK R20 の emulator でハードウェアキーボードが使えない

Windows 用の Android SDK を R20 に上げたら、emulator (ADV) 環境でソフトウェアキーボードしか使えなくなってしまったので対処法。

  1. 下記 URL から R18 をダウンロード。
    http://dl.google.com/android/android-sdk_r18-windows.zip
  2. zip から android-sdk-windows/tools/emulator-arm.exe を展開。
  3. 展開したファイルを %ProgramFiles%\Android\android-sdk\tools にコピー。
  4. 同様に emulator-x86.exe もコピー。

R19 までは hw.keyboard = yes だったのに、hw.keyboard = no になったことに起因していると思われます。多分、Android 4.1 用の予測変換に対応するための措置なんでしょうけど、4.0.3 以前の ADV に対しては旧来のままにしてくれても良かったのにね。hardware-qemu.ini を手で書換えても emulator が自動的に上書きしてしまうので意味ありませんでした。hardware-properties.ini の既定値も yes から no に変わったので意図的なんでしょうね。

Cygwin 1.7.1 続報

先日お話しした、Cygwin 1.7.1 の vim が -iconv 状態で UTF-8 な環境では使い物にならないという件ですが、ここで報告してから丁度 24 時間後くらいに vim-7.2.264-2 として +iconv で re-build したパッケージが公開されてました。一応動作確認してみましたが、UTF-8 環境での cp932 や EUC-JP の編集も問題なく、一応の解決は見られたようです。.exrc の設定が必須なので、ある程度 I18N 状況に明るい人じゃないと対応出来ないとは思いますが、そのうちどこかにまとめサイトでも出来るといいですね。
さて、この blog は専ら私個人の備忘録的な位置付けで色々書いてるに過ぎないんですが、このレスポンスの速さを見るに、今回の vim の件って誰かこの blog 情報をチクったんじゃないかという気がしてます。7.2.264-1 の release が 2009/10/01 なんで、4 ヶ月も放置されてた障害が私が見つけた直後に修正されるってのは、偶然にしては余りに出来過ぎた話です。むむー、こんなトコをチェックしてる人はそんなにいないと思ってたんですがねー。
でも、どーせなら libtermcap の方を上訴してくれた方が幸せになれる人が多かったのに :-)

いけてない Cygwin 1.7.1

気がついたら Cygwin が 1.7.1 という新しい version になってたんですが、こいつがかなりいけてない。利用者を無視した独善的な「改良」を一方的に押しつけた結果、実用的に使えない代物になり下がってしまいました。もう release から一ヶ月以上経つと言うのに、誰も文句言わないってのはそれだけ使い倒されてないってことなのかしらん。
一つ目は勝手に termcap library (libtermcap) を撤廃しちゃったこと。まぁ最近の主流は terminfo かも知れないので、BSD なおじさん以外は policy 的には容認出来るとは思いますが、往年の UNIX な source が幾つか compile 出来なくなって嘆いている声も無くはない筈。まー、面倒なんでメンテしてられっかという気持ちは判るんですが、そもそも Cygwin ってそういう UNIX な source を Windows 上で compile したいってところから始まってるんじゃないのかしらん?それとも「UNIX = Linux」という考え違いをしてるのかなー。
二つ目は UTF-8 化です。既に Windows NT architecture は内部コードに UCS2 を使ってるんで、Cygwin も親和性を高めるために Unicode をって気持ちは判ります。でも、そういう運用が可能かどうか、もう少し調べてから移行すべきだったかと。最初は「設定をいじると UTF-8」にしておいて、暫く様子を見てから「標準が UTF-8」にすべきだったと思います。いきなりだったんで色々不都合出てますね。
特に CJK 圏ではまだ Shift_JIS が幅を効かせてたりして、text file の中身は Shift_JIS の方が多いと思います。で、Cygwinvim で開こうとすると UTF-8 じゃないので化け化け。vim って I18N 化してた筈と思って色々 .exrc に書いてみたけど駄目なので「vim --version」とか打ってみると見事に「-iconv」とか言ってきやがります。誰だ、libiconv 抜きの環境で build したのは。
因みに一つ前の古い vim (7.2.148-1) は +iconv なので、setup.exe でその古いのを install すれば vimShift_JIS なファイルも編集出来ます。但し、Linux な人は要注意。Linux の iconv と GNU libiconv では charset 名称の「Shift_JIS」が違うものを指します。GNU libiconv では「\」が 0xa5 に mapping された、そんなんどこで誰が使ってるのか聞いたこともない code 体系なので、当然「\」を含んだ text は編集出来ません。GNU libiconv では「cp932」を使いましょう。vim 的には「japan」が「cp932」の alias になってるのでそっちでも構いません。一応必要な設定を挙げとくとこんな感じ。

set fileencodings=cp932,utf-8,euc-jp,iso-2022-jp,latin1
set fileencoding=cp932
set encoding=utf-8
set termencoding=utf-8

fileencodings の順序は優先順位になってるので、utf-8 を優先させたい人は逆順にしましょう。あと、fileencoding も設定しておくと、空の text file を作成する時にその code が有効になります。これは utf-8 でも構わないと思います。

VMwareTools その後

VMware も 6.5.3 になって VMwareTools の非英語圏締出しに拍車が掛かって来ましたね。US-ASCII を前提とした個所が多過ぎて、もう個別の shell script に「LANG=C」を追加してたんじゃ追い着かなくなってます。特に vmware-config-tools.pl の中で「gcc --version」でバージョンチェックしているところがあって、LANG=C じゃないと必ず非対応コンパイラ扱いです。仕方ないので、起動時に「LANG=C ./vmware-config-tools.pl」とした方が手っ取り早そうですね。
因みに、これとは別に vmware-guestd や vmware-toolbox や vmware-users 辺りに「LANG=C」を追加するという hack は必要になるので面倒です。こいつらは config 時以外にも起動されるので、vmware-config-tools.pl に細工したって付け焼刃にしかなりません。兎にも角にも、VMware は非英語圏をとことん忌み嫌っている様子が徐々に表面化して来てます。時代に逆行するこの流れ、何とかならないもんでしょうかね?

VMware6.5 の VMwareTools の I18N 問題

VMware6.5.1 がリリースされてようやく 6.5 も日本語化されたので使ってみました。どうやら VMwareTools を I18N 対応したようなんですが、例によって例の如く US-ASCII だけで暮らしてる平和な人たちが実装した様子で、UTF-8 に対応した程度で I18N を完遂した気になってるようですね。
Google ってみるとあちこちで悲鳴が挙がってるようですけど、ja_JP.eucJP な Vine Linux とか、キリル文字使ってるロシア人とか、vmware-config-tools.pl の時点で「Unicode_EncodingEnumToName: Unknown encoding -2」とか言われて先に進めずに困っているみたいですね。どうやら想定外の locale を設定されて対応出来なくて panic 起こしてるようです。
取り敢えずの回避法としては、このエラーを出している vmware-guestd の script だけ書換えてしまえば vmware-config-tools.pl は通るようになります。この実体は OS によって異なりますけど、主だった環境では以下の場所にあります。

Linux:
/usr/lib/vmware-tools/sbin/vmware-guestd-wrapper
Solaris:
/usr/lib/vmware-tools/sbin/i86/vmware-guestd

この script の最終行に exec コマンドが記述されていますので、その直前に以下のような 2 行を追加してあげましょう。

LANG=C
export LANG

他にも vmware-toolbox 等主要なプログラムにも同じ問題が存在していますが、取り敢えずはこの script 一つだけ書換えておけば初期設定は完了しますし、OS 起動時の VMwareTools 動作も問題無く完了します。