はるかに簡単な解決策は、あちこちのすべてのif
チェックを忘れて、Antターゲットを呼び出すときにProGuardを使用して任意のLog.d()
またはメソッド呼び出しを削除することです。Log.v()
release
そうすれば、通常のビルドのデバッグ情報が常に出力され、リリース ビルドのコードを変更する必要がなくなります。ProGuard は、バイトコードに対して複数のパスを実行して、他の望ましくないステートメントや空のブロックを削除し、必要に応じて短いメソッドを自動的にインライン化することもできます。
たとえば、Android 用の非常に基本的な ProGuard 構成は次のとおりです。
-dontskipnonpubliclibraryclasses
-dontobfuscate
-forceprocessing
-optimizationpasses 5
-keep class * extends android.app.Activity
-assumenosideeffects class android.util.Log {
public static *** d(...);
public static *** v(...);
}
したがって、それをファイルに保存し、Ant から ProGuard を呼び出して、コンパイルしたばかりの JAR と使用している Android プラットフォーム JAR を渡します。
ProGuard マニュアルの例も参照してください。
更新 (4.5 年後):最近では、Android のログ記録にTimberを使用しました。
既定の実装よりも少し優れているだけでなく (Log
ログ タグが自動的に設定され、書式設定された文字列と例外を簡単にログに記録できます)、実行時にさまざまなログの動作を指定することもできます。
この例では、ロギング ステートメントは、アプリのデバッグ ビルドで logcat にのみ書き込まれます。
Application
onCreate()
木材は私の方法で設定されています:
if (BuildConfig.DEBUG) {
Timber.plant(new Timber.DebugTree());
}
次に、コードの他の場所で簡単にログを記録できます。
Timber.d("Downloading URL: %s", url);
try {
// ...
} catch (IOException ioe) {
Timber.e(ioe, "Bad things happened!");
}
より高度な例については、 Timber サンプル アプリを参照してください。開発中にすべてのログ ステートメントが logcat に送信され、本番環境ではデバッグ ステートメントはログに記録されませんが、エラーはサイレントに Crashlytics に報告されます。