署名Androidアプリケーション作成時のWarning

Google PlayにAndroidアプリケーションを載せる前に、アプリケーションに署名を行ないますが、 Export Signed Application Package...を選択した時に、同一パッケージ内で can't find referenced classのワーニングが大量に発生して、パッケージを作成する事ができませんでした。

いろいろ調べると、proguard設定に-dontwarn設定を追加すれば良いと書かれていますが、 不必要に全てのワーニングを抑制するのが嫌だったのでproguardのサイトを眺めた時のメモです。

ワーニングメッセージの例

...
Proguard returned with error code 1. See console
Warning: com.example.android.MenuFragment$1: can't find referenced class com.example.android.TempActivity
Warning: com.example.android.ToolsFragment: can't find referenced class com.example.android.ImportAsyncFragment
Warning: com.example.android.ToolsImportFragment$1: can't find referenced class com.example.android.ImportAsyncFragment
...

• EclipseのADTバージョンによるproguard設定の指定方法の違い
• Proguard トラブルシューティング記事のまとめ
• 選択肢1. 必要なjarファイルが指定されていない場合
• 選択肢2. アプリケーションの稼働に不要なクラスの参照関係が解決できない場合
• 選択肢3. filter outが気に入らなければ-ignorewarningsか-dontwarnを使えばいいよ
• さいごに

EclipseのADTバージョンによるproguard設定の指定方法の違い

Eclipse 3.6ベースのADTを使っていた時には、project.propertiesにproguard.cfgファイルを指定していました。

...
target=android-4
proguard.config=proguard.cfg...
...

この時のproguard.cfgは必要な設定全体を含んでいましたが、 Android 3.7ベースのADT 18.0.0では、project.propertiesに次のような行が含まれています。

...
# To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home):
#proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
...

コメントの一部なのでまぎらわしいですが、proguard.configで始まる一行をコメントアウトして、システム全体で共通の設定ファイルを使うように変更されています。

自分のアプリケーション用の設定は、AndroidManifest.xmlなどと同じフォルダにproguard-project.txtを作成し、 差分だけを記述するように変更されています。

Proguard トラブルシューティング記事のまとめ

proguardサイトのトップページから"Manual"をクリックすると、左のメニューが変化して"Troubleshooting"ページにアクセスする事ができるようになります。

can't find referenced classで検索すると、3つの項目が並んでいました。 Eclipseを使ってAndroidアプリを開発している場合には、1,2はなさそうです。

選択肢1. 必要なjarファイルが指定されていない場合

指定漏れのあるjarファイルがあれば、-injarsオプションなどで適宜追加するように書かれています。 コマンドラインでビルドする場合には注意が必要でしょうが、Eclipse内でビルドが正常に完了して、Eclipseからproguardを起動していれば必要ないはずです。

選択肢2. アプリケーションの稼働に不要なクラスの参照関係が解決できない場合

ワーニングに指定されているクラスへの参照は必要ないから、解決できなくても動くよ、そんな場合にはfilter outの指定をするように書かれています。

これは1.との合わせ技で、-injarsで指定するjarファイルの後ろに無視する条件を指定する方法で、これもEclipseを使っていれば本来必要ないはずです。

選択肢3. filter outが気に入らなければ-ignorewarningsか-dontwarnを使えばいいよ

ほとんどのEclipseでAndroidアプリを開発している場合にあてはまるのが、このオプションを指定する場合だと思います。

StackOverflowなんかをみていても、-dontwarnを指定すればいいんじゃない?、というアドバイスが多かったです。

Troubleshootingページをみると、"-dontwarn java.awt.**" みたいな指定ができるので、 自分が作成した同一パッケージ内でのクラスの参照関係が解決できなくても無視するように次のような設定をしています。

現状のproguard-project.txt全体

-keepclassmembers class com.example.android.InfoFragment.DemoJavaScriptInterface {
   public *;
}
-dontwarn com.example.android.*

WebViewを使ってJavaScript用にオブジェクトを設定している場合には、そのクラスを指定するように書かれているので、その下に-dontwarn行を追加しました。

さいごに

署名済みAPKファイルは無事に生成できるようになりました。

別のprogurad.cfgの挙動が変化した分けじゃないんですが、ADTをアップグレードして空のプロジェクトを生成した時にproguard.cfgがなくなったりすると、そのまま昔のproguard.cfgをproguard-project.txちょっとした混乱が起きそうです。

Googleで解決策がみつかるのは良いんですが、そのまま信用して簡単な策を取ると、いろいろ問題がありそうですね。 まぁ趣味の範囲なら、なんでも良いんですけれど。

いろいろな事がボーダーレスになって、プロとアマチュアの境界があいまいになりつつあるのが、少し怖いです。 怖いのはアマチュアに侵食されるんじゃなくて、プロのはずがアマチュアに落ちる事なんですけどね。

暗証番号と生体認証の違いと国民総背番号制

これまで生体認証については、指紋の他に虹彩や静脈認証の経験がある。 静脈認証はかなり良い線いっているけれど、工作で回避できたという主張もある。

とはいえ、いまの暗証番号よりも信用しすぎる事がなければ、ずっと良い代替手段にはなるはずだ。

では切り替えが進んでいないようにみえる背景にはどんな事があるんだろう。

• 基本的なことがら
• 生体情報をいろいろな場面で要求される事で発生する問題

基本的なことがら

暗証番号が生体認証におきかわったとした未来を想像して、いままでの自分の経験に照らして困る事といったら、17,18の頃に父親の代りに生活費を銀行口座から引き出していた事ぐらいだ。

とはいえ、パソコンのログインパスワードが生体認証に置き換わった時には、相当混乱するであろう現場をいままでの経験から両手では数え切れないぐらい知っている。

だからパスワードは無くならないと思う。

容易に他人に移譲できる暗証番号番号から、物理的にも特定の個人に紐付く生体認証にかわっただけの事で、その基本的な機能は変化していない。ただ、一時的な例外的な扱いにつて、例外処理を厳格に設けなければいけなくなっただけだ。

権限が移譲されている事の証明が必要になる。

しかし、なにより、基本的にはこれまで適切な人間を代理人に指名して、それを証明する便利な方法は存在していない。

社会生活上は委任状の仕組みがあるけれど、それはただの責任を回避する仕組みでしかない。

住民票の取得なんかで免許証で個人を特定できたとしても(Authentication)、その人が権限を移譲されているかどうかを判断すること(Authorization)とは本質的に別の事だ。

ある人が他人に自分の権限を移譲するためには、これまた別の第三者がそれを信じるに足る相当な理由が客観的に証明されなければいけない。そのために時間がかかるようでもいけない。

代理人の存在を証明するには、その生体認証そのものを使って署名をするのがベストな方法だと思う。 その署名データが流通する仕組みがあれば、、他人も十分に代理人の正当性を信じる事ができるだろう。

データの流通の問題が解決できれば生体認証の仕組みを使って相当に便利な世の中にする事ができるはずだ。 それを提供するのは行政の役割のような気もするし、社会インフラとして整備すれば、ある情報が特定の人によって了承された事が容易に証明できるようになる。

一卵性双生児の存在がセキュリティホールにならない程度に生体認証の精度が上げられれば、技術的にはパスワードは不要なものとなるだろう。

生体情報をいろいろな場面で要求される事で発生する問題

署名とはいっても実際にはICカードなどに入っている電子的な本人証明書にアクセスするための鍵として生体認証が使われるだけだけれど、そのICカードと生体との電気的接続の間をハイジャックする事ができれば、同じ電気信号を与える事と鍵の入っているICカード的なものを盗む事でその鍵を開けられてしまうかもしれない。

ICカードなんかからチャレンジコードを出してタンパー耐性のあるデバイスと暗号通信させるしかないんだろうけれど、手軽に指をガラス上に置く機会が増えれば鍵となる生体データをコピーされる機会もまた増えるだろう。

問題は解決しないように思えるけれど、定期的な証明書の再発行と古い証明書の廃棄で被害を抑えこむ事はできるだろうし、暗証番号とは違って外部からの観察によって漏れる危険はかなり低いから現状よりはずっと安全になるだろう。

現状の暗証番号を使う場面よりも、安全だと勘違いをして、広く権限を与えるような事をしなければ、つまり、いままでと同程度の使い方であれば、生体認証への切り替えはずっと安全になるはずだ。

最終的には生体認証を積極的に使うべきだと思うけれど、その導入が銀行のATMだけなら、コストとラーニングカーブの観点からかなり普及は難しいだろう。普及のハードルはかなり高い。

人間の心理的な抵抗を甘くみることはできない。

とはいえ、全体的な絵を描けるアーキテクトが出現するか、現行のシステムが破綻するほど治安が悪化すれば、生体認証は表舞台に立てるだろう。 そうでなければ、せいぜい大企業のシステムに取り込まれるぐらいで終ってしまうかもしれない。

普及についての議論はおおいに盛り上って楽しいものになるだろうけど、現実の近未来を考えると、その見通しはかなり悲観的に感じざるを得ない。技術的な問題よりも心理的な抵抗を軽減することが難しいと思う。

自分自身をその変化に適応させてまで必要だと納得するのは難しいだろう。 現行のシステムに欠点があると知っても、それが自分自身にふりかかるまでは、耐えられるからだ。

積極的な普及を図るなら、小さい成功事例を積み上げていくしかないだろう。 いまのところは個人で始められるのは、NFCがRFIDぐらいだけれど、可能であればいろいろな場面で生体認証を使う機会を増やして、その可能性が確かなものか試していきたい。