GingerbreadことAndroid2.3のリリースに合わせて公開された新しいSDKとEclipseプラグイン、個人的に一番興味があったのは難読化ツール「ProGuard」が統合されたことです。
少々解説しておくと、Javaは比較的リバースエンジニアリングに弱いというか、コンパイル済みのファイルから結構なところまでソースコードが復元できてしまうので、リバースエンジニアリングから防御するためには、変数名やメソッド名を意味のない値にする(例えばgetDate()というメソッドをa()にしてしまう)ツールが有効で、そんなツールがProGuardです。変数名やメソッド名が短くなることにより、アプリケーションのファイルサイズが小さくなるというメリットもあります。
さて、新しいSDK+Eclipseプラグイン環境でProGuardを使うためには、まずプロジェクト内のdefault.propertiesに
proguard.config=proguard.cfg
という内容を追記します。ここでproguard.cfgはProGuardの設定ファイルで、新しい環境でAndroidプロジェクトを作るとある程度お仕着せのproguard.cfgが自動でプロジェクトに含まれます。既存のプロジェクトにproguard.cfgを追加する方法がわからなかったので、自分は空のAndroidプロジェクトを1個つくってproguard.cfgを拝借しましたw。基本的にはこれだけで、リリース用ビルドを行う(「Export Signed Application Package…」を実行する)時に自動的にProGuardで処理してくれます。
さて、これでProGuardが万全かというとそうでもありません。自分の場合Twitterライブラリ「Twitter4J」で少々つまづきました。まず、通常のビルドでは必要とされていない依存ライブラリがProGuardで必要とエラー表示されたので、proguard.cfgに以下の記述を追加。
-libraryjars (JARファイルへのパス)/slf4j-api-1.6.1.jar
-libraryjars (JARファイルへのパス)/commons-logging-1.1.1.jar
-libraryjars (JARファイルへのパス)/log4j-1.2.16.jar
ここで(JARファイルへのパス)はライブラリが存在するパス(相対・絶対のどちらでもOK)です。
これでProGuardは正常終了してアプリケーションファイルが生成できるようになりますが、実際に動かしてみるとTwitter4J関係のところで異常終了してしまいます。厳密にコードを追えば原因を特定できるのでしょうが、もともとTwitter4Jはソースが公開されているライブラリで難読化する意味が無いと考えたので、proguard.cfgに以下の記述を追加してまるっと難読化の対象から外してみました。
-keepclasseswithmembers class twitter4j.**
{
*;
}
ここで「twitter4j.**」というのは、twitter4jパッケージ配下の任意深さの階層の全て、要は「まるっと」という意味です。
これでTwitter4J部分のプログラムも動くようになりました。ちなみにどのクラスがどんな名前にされたかは、proguardフォルダのmapping.txtに出力されるので、設定を調整するときの参考にすると良いと思います。
参考までに拙作「twicca マルチ画像プラグイン」の場合、ファイルサイズが234KB→176KBに削減されました。変数名やメソッド名を書き換えるという性質上、リリースビルドでひと通りテストを行うことが必須となりますが、少しでもファイルを軽くしたい、自分のコードを守りたいという人にとって試す価値のあるツールだと思います。