・進捗：
　・80系と88系でキーの色を分けてみた
　・88系の矩形でないリターンキーを表現してみた
　・ローマ字カナ変換のコマンドキーを用意した (さらに表現も変えてみた)
　・「横向き」かつ「ハードウェアキーボード(KEYBOARD_QWERTY)あり」の場合はキーボードを非表示(初期状態)としてみた
　　さらに「現在使用可能な状態にあるか？」も考慮する必要があると思う
　・キーボードの表示状態を、縦,横で分けて覚えておくようにした
　・ハードキーボードの [SHIFT]+[2] で「”」が入らないのは何故だ？と思いつつ放置していたのを調べた
　　 → [SHIFT] +「KEYCODE_APOSTROPHE」に化けるぞ！ → キーマップファイルに「75」も追加登録した
　・FileChooser(Saveモード) 作りこみ (ファイル名入力でディレクトリ移動, 新規ファイル作成)

・懸案：
　・SHIFT時の文字を表示する簡単な方法を模索中
　　keyLabel と keyIcon は排他利用？ → フォントをそろえるために全キーicon化は避けたい
　　それに、icon には 9patch 効かなかったような。。。
　　 → APIのソースコードを精査中
　・カナ(海外版はALT)ロック時に表示を差し替えようか検討中
　　「ローマ字カナ変換機能が有効な場合はカナロック無視」という仕様を表現する必要あり
　・グラフィック表示は無視する予定 (シールなし仕様)
　・画面の向きによらずレイアウトを固定できるようにしたい → システム側で設定すべき？
　　システム側の設定とアプリでの画面の向きの制御の関係をもう少し勉強したい
　・ソフトキーの出し入れを簡単にしたい
　　j80のタッチパネル機能と競合するので「画面タップ」については検討が必要
　・横画面のキーボードと「タッチパネル機能」は競合するので排他制御が必要
　・修飾キーのイベントに癖があるので、ハードキーボードはあてにしない方が良いかも...
　　前にも書いたけど、併用するキーが押されるまで修飾キーを押したイベントが来ないみたい
　　副作用の無いキーに(も)[SHIFT]を割り当ててしまえば良いのだけれど、キーの数が足りないだろうなぁ
　・そろそろ「シリアルキーボード」を何とかしないと...

・雑感：
　　キーボードまわりのAPIソースを見て「ちょっと雑だし甘いな」と感じました。
　xml でイロイロ指定できるのですが、決め打ちでハードコーディングしている部分も多いのです。
　今回キーの色分けや色セットを複数持たせる拡張を複数の実装で試してみたのですが、
　思わぬ副作用が出て、ソースを読んではじめてわかった仕様なんてのもありました。
　(ドキュメントを読みきれていないだけかもしれませんが)
　　いちばん気になったのは、キーのレンダリング関数が private だったりして、継承して使いにくい点です。
　こんなところから「やっつけ仕事」に感じてしまうんですよねぇ。
　「痒いところに限って手が届かない」のはストレス溜まりますね。
　　j80では、android.view.inputmethod の KeyboardView, Keyboard, Row, Key を「借りて」使っているのですが、
　システム側の「文字入力」とは無関係だし、「キーボードのデザイン」を含むほとんどの設定の影響を受けないので、
　独自実装してしまっても良いかな？と思っています。(Java版用のキーボードもついでに？)

KeyboardViewの調査：
・描画とイベントが一致しない(実機未確認)
　キーを押した状態で指(エミュ上ではポインタ)を動かしたとき、フォーカスは移動するがイベントが来ない
　「on」の状態も変化するけど、イベントが来ないので。。。
　実機でもこんなだったらパッチ当てが大変だなぁ
　そのときはフルスクラッチしたほうが良さそう

関連して、j80側の Keyboard クラスを整理しました。
・キーが押しっぱなしになることがあるので対策を少し
・88(8MHz機)のシリアルキーボードに対応しました
　実装に当たっては、PC-8801覚え書き を参考にしました
・80mkII/SR の [Tab] キーパッチも、上記ロジックに組み込んでスッキリさせました

今後の予定などを。。。

・Android版のリリース時期は未定です
　実機を手に入れて動作確認をするまではリリースしません
　エミュレータ本体は Java版のままなので、急ぐ必要はないと思っています

・Android版のターゲットも未定です
　なんとなくですが、4.0以降をターゲットとしようかと考えています
　現状では開発環境(エミュレータ)の都合で古いAPIでも動くようにしていますが、
　結局のところ、古い機体だと重くて使い物にならないと思うのです
　そうであれば制約の少ないAPIを使いたいな。と