Comment supprimer tous les appels de journalisation de débogage avant de créer la version finale d'une application Android?

Selon Google, je dois " désactiver tous les appels aux méthodes Log dans le code source " avant de publier mon application Android sur Google Play. Extrait de la section 3 de la liste de contrôle de publication :

Assurez-vous de désactiver la journalisation et de désactiver l'option de débogage avant de créer votre application pour publication. Vous pouvez désactiver la journalisation en supprimant les appels aux méthodes Log dans vos fichiers source.

Mon projet open-source est volumineux et il est difficile de le faire manuellement chaque fois que je publie. De plus, la suppression d'une ligne de journal est potentiellement délicate, par exemple:

if(condition)
  Log.d(LOG_TAG, "Something");
data.load();
data.show();

Si je commente la ligne Log, la condition s'applique à la ligne suivante et il est probable que load () n'est pas appelée. Ces situations sont-elles suffisamment rares pour que je puisse décider qu'elles ne devraient pas exister?

Alors, existe-t-il une meilleure façon au niveau du code source de le faire? Ou peut-être une syntaxe intelligente de ProGuard pour supprimer efficacement mais en toute sécurité toutes les lignes de journal?

Je trouve qu'une solution beaucoup plus simple est d'oublier toutes les ifvérifications partout et d'utiliser simplement ProGuard pour éliminer tous les appels Log.d()ou la Log.v()méthode lorsque nous appelons notre releasecible Ant .

De cette façon, nous avons toujours les informations de débogage générées pour les versions régulières et nous n'avons pas à apporter de modifications de code aux versions. ProGuard peut également effectuer plusieurs passes sur le bytecode pour supprimer d'autres instructions indésirables, des blocs vides et peut automatiquement incorporer des méthodes courtes le cas échéant.

Par exemple, voici une configuration ProGuard très basique pour Android:

-dontskipnonpubliclibraryclasses
-dontobfuscate
-forceprocessing
-optimizationpasses 5

-keep class * extends android.app.Activity
-assumenosideeffects class android.util.Log {
    public static *** d(...);
    public static *** v(...);
}

Donc, vous enregistrez cela dans un fichier, puis appelez ProGuard de Ant, en passant votre JAR juste compilé et le JAR de la plateforme Android que vous utilisez.

Voir également les exemples dans le manuel ProGuard.

Mise à jour (4,5 ans plus tard): Aujourd'hui, j'utilisais Timber pour la journalisation Android.

Non seulement c'est un peu plus agréable que l' Logimplémentation par défaut - la balise log est définie automatiquement, et il est facile d'enregistrer des chaînes formatées et des exceptions - mais vous pouvez également spécifier différents comportements de journalisation lors de l'exécution.

Dans cet exemple, les instructions de journalisation seront uniquement écrites dans logcat dans les versions de débogage de mon application:

Le bois est installé dans ma Application onCreate()méthode:

if (BuildConfig.DEBUG) {
  Timber.plant(new Timber.DebugTree());
}

Puis, n'importe où ailleurs dans mon code, je peux me connecter facilement:

Timber.d("Downloading URL: %s", url);
try {
  // ...
} catch (IOException ioe) {
  Timber.e(ioe, "Bad things happened!");
}

Voir l' exemple d'application Timber pour un exemple plus avancé, où toutes les instructions de journal sont envoyées à logcat pendant le développement et, en production, aucune instruction de débogage n'est enregistrée, mais les erreurs sont silencieusement signalées à Crashlytics.

Toutes les bonnes réponses, mais une fois mon développement terminé, je ne voulais pas utiliser les instructions if pour tous les appels Log, ni utiliser des outils externes.

La solution que j'utilise est donc de remplacer la classe android.util.Log par ma propre classe Log:

public class Log {
    static final boolean LOG = BuildConfig.DEBUG;

    public static void i(String tag, String string) {
        if (LOG) android.util.Log.i(tag, string);
    }
    public static void e(String tag, String string) {
        if (LOG) android.util.Log.e(tag, string);
    }
    public static void d(String tag, String string) {
        if (LOG) android.util.Log.d(tag, string);
    }
    public static void v(String tag, String string) {
        if (LOG) android.util.Log.v(tag, string);
    }
    public static void w(String tag, String string) {
        if (LOG) android.util.Log.w(tag, string);
    }
}

La seule chose que je devais faire dans tous les fichiers source était de remplacer l'importation de android.util.Log par ma propre classe.

Je suggère d'avoir un booléen statique quelque part indiquant s'il faut ou non se connecter:

classe MyDebug {
  statique final booléen LOG = true;
}

Ensuite, où que vous souhaitiez vous connecter à votre code, procédez comme suit:

if (MyDebug.LOG) {
  if (condition) Log.i (...);
}

Maintenant, lorsque vous définissez MyDebug.LOG sur false, le compilateur supprimera tout le code à l'intérieur de ces vérifications (car il s'agit d'une finale statique, il sait au moment de la compilation que le code n'est pas utilisé.)

Pour les projets plus importants, vous souhaiterez peut-être commencer à avoir des booléens dans des fichiers individuels pour pouvoir facilement activer ou désactiver la journalisation là-bas selon les besoins. Par exemple, voici les différentes constantes de journalisation que nous avons dans le gestionnaire de fenêtres:

static final String TAG = "WindowManager";
static final boolean DEBUG = false;
static final boolean DEBUG_FOCUS = false;
static final boolean DEBUG_ANIM = false;
static final boolean DEBUG_LAYOUT = false;
static final boolean DEBUG_RESIZE = false;
static final boolean DEBUG_LAYERS = false;
static final boolean DEBUG_INPUT = false;
static final boolean DEBUG_INPUT_METHOD = false;
static final boolean DEBUG_VISIBILITY = false;
static final boolean DEBUG_WINDOW_MOVEMENT = false;
static final boolean DEBUG_ORIENTATION = false;
static final boolean DEBUG_APP_TRANSITIONS = false;
static final boolean DEBUG_STARTING_WINDOW = false;
static final boolean DEBUG_REORDER = false;
static final boolean DEBUG_WALLPAPER = false;
static final boolean SHOW_TRANSACTIONS = false;
static final boolean HIDE_STACK_CRAWLS = true;
static final boolean MEASURE_LATENCY = false;

Avec le code correspondant comme:

    if (DEBUG_FOCUS || DEBUG_WINDOW_MOVEMENT) Log.v(
        TAG, "Adding window " + window + " at "
        + (i+1) + " of " + mWindows.size() + " (after " + pos + ")");

La solution Proguard de Christopher est la meilleure, mais si pour une raison quelconque vous n'aimez pas Proguard, voici une solution très low-tech:

Journaux de commentaires:

find . -name "*\.java" | xargs grep -l 'Log\.' | xargs sed -i 's/Log\./;\/\/ Log\./g'

Décommenter les journaux:

find . -name "*\.java" | xargs grep -l 'Log\.' | xargs sed -i 's/;\/\/ Log\./Log\./g'

Une contrainte est que vos instructions de journalisation ne doivent pas s'étendre sur plusieurs lignes.

(Exécutez ces lignes dans un shell UNIX à la racine de votre projet. Si vous utilisez Windows, obtenez une couche UNIX ou utilisez des commandes Windows équivalentes)

Je voudrais ajouter quelques précisions sur l'utilisation de Proguard avec Android Studio et Gradle, car j'ai eu beaucoup de problèmes pour supprimer les lignes de journal du binaire final.

Afin de faire assumenosideeffectsdans Proguard fonctionne, il y a une condition préalable.

Dans votre fichier de notes, vous devez spécifier l'utilisation du proguard-android-optimize.txtfichier par défaut.

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

        // With the file below, it does not work!
        //proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

En fait, dans le proguard-android.txtfichier par défaut , l'optimisation est désactivée avec les deux drapeaux:

-dontoptimize
-dontpreverify

Le proguard-android-optimize.txtfichier n'ajoute pas ces lignes, il assumenosideeffectspeut donc maintenant fonctionner.

Ensuite, personnellement, j'utilise SLF4J , d'autant plus quand je développe des bibliothèques qui sont distribuées à d'autres. L'avantage est que par défaut il n'y a pas de sortie. Et si l'intégrateur veut des sorties de journal, il peut utiliser Logback pour Android et activer les journaux, afin que les journaux puissent être redirigés vers un fichier ou vers LogCat.

Si j'ai vraiment besoin de supprimer les journaux de la bibliothèque finale, j'ajoute ensuite à mon fichier Proguard (après avoir proguard-android-optimize.txtbien sûr activé le fichier):

-assumenosideeffects class * implements org.slf4j.Logger {
    public *** trace(...);
    public *** debug(...);
    public *** info(...);
    public *** warn(...);
    public *** error(...);
}

Je suggère fortement d'utiliser Timber de Jake Wharton

https://github.com/JakeWharton/timber

il résout votre problème d'activation / désactivation et ajoute automatiquement la classe de balises

juste

public class MyApp extends Application {

  public void onCreate() {
    super.onCreate();
    //Timber
    if (BuildConfig.DEBUG) {
      Timber.plant(new DebugTree());
    }
    ...

les journaux ne seront utilisés que dans votre ver de débogage, puis utiliser

Timber.d("lol");

ou

Timber.i("lol says %s","lol");

imprimer

"Votre classe / msg" sans spécifier la balise

J'ai utilisé une classe LogUtils comme dans l'exemple d'application Google IO. J'ai modifié cela pour utiliser une constante DEBUG spécifique à l'application au lieu de BuildConfig.DEBUG car BuildConfig.DEBUG n'est pas fiable . Ensuite, dans mes cours, j'ai ce qui suit.

import static my.app.util.LogUtils.makeLogTag;
import static my.app.util.LogUtils.LOGV;

public class MyActivity extends FragmentActivity {
  private static final String TAG = makeLogTag(MyActivity.class);

  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    LOGV(TAG, "my message");
  }
}

J'envisagerais d'utiliser la fonction de journalisation de roboguice au lieu du android.util.Log intégré

Leur fonction désactive automatiquement les journaux de débogage et détaillés pour les versions. De plus, vous obtenez gratuitement quelques fonctionnalités intéressantes (par exemple, un comportement de journalisation personnalisable, des données supplémentaires pour chaque journal et plus)

L'utilisation de proguard pourrait être assez compliquée et je ne passerais pas la peine de la configurer et de la faire fonctionner avec votre application à moins d'avoir une bonne raison à cela (la désactivation des journaux n'est pas une bonne)

Je publie cette solution qui s'applique spécifiquement aux utilisateurs d'Android Studio. J'ai également récemment découvert Timber et l'ai importé avec succès dans mon application en procédant comme suit:

Mettez la dernière version de la bibliothèque dans votre build.gradle:

compile 'com.jakewharton.timber:timber:4.1.1'

Ensuite, dans Android Studios, allez dans Edition -> Rechercher -> Remplacer dans le chemin ...

Tapez Log.e(TAG,ou comme vous avez défini vos messages de journal dans la "Text to find"zone de texte. Ensuite, il vous suffit de le remplacer parTimber.e(

Cliquez sur Rechercher, puis remplacez tout.

Les studios Android vont maintenant parcourir tous vos fichiers dans votre projet et remplacer tous les journaux par des bois.

Le seul problème que j'ai eu avec cette méthode est que gradle apparaît avec un million de messages d'erreur par la suite car il ne peut pas trouver "Timber" dans les importations pour chacun de vos fichiers java. Cliquez simplement sur les erreurs et Android Studios importera automatiquement "Timber" dans votre java. Une fois que vous l'avez fait pour tous vos fichiers d'erreurs, gradle se compilera à nouveau.

Vous devez également mettre ce morceau de code dans la onCreateméthode de votre Applicationclasse:

    if (BuildConfig.DEBUG) {
        Timber.plant(new Timber.DebugTree());
    }

Cela entraînera la journalisation de l'application uniquement lorsque vous êtes en mode développement et non en production. Vous pouvez également avoir BuildConfig.RELEASEpour vous connecter en mode de libération.

Per android.util.Log fournit un moyen d'activer / désactiver le journal:

public static native boolean isLoggable(String tag, int level);

Par défaut, la méthode isLoggable (...) retourne false, seulement après que vous définissez prop dans le périphérique comme ceci:

adb shell setprop log.tag.MyAppTag DEBUG

Cela signifie que tout journal au-dessus du niveau DEBUG peut être imprimé. Référence android doc:

Vérifie si un journal pour la balise spécifiée est enregistrable ou non au niveau spécifié. Le niveau par défaut de toute balise est défini sur INFO. Cela signifie que tout niveau supérieur et y compris INFO sera enregistré. Avant d'appeler une méthode de journalisation, vous devez vérifier si votre balise doit être journalisée. Vous pouvez modifier le niveau par défaut en définissant une propriété système: 'setprop log.tag. 'Où le niveau est VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT ou SUPPRESS. SUPPRESS désactivera toute journalisation de votre balise. Vous pouvez également créer un fichier local.prop contenant les éléments suivants: 'log.tag. =' Et le placer dans /data/local.prop.

Nous pourrions donc utiliser un journal personnalisé:

public final class Dlog 
{
    public static void v(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.VERBOSE))
            Log.v(tag, msg);
    }

    public static void d(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.DEBUG))
            Log.d(tag, msg);
    }

    public static void i(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.INFO))
            Log.i(tag, msg);
    }

    public static void w(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.WARN))
            Log.w(tag, msg);
    }

    public static void e(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.ERROR))
            Log.e(tag, msg);
    }
}

Si vous pouvez exécuter un remplacement global (une fois), et après cela conserver une convention de codage, vous pouvez suivre le modèle souvent utilisé dans le cadre Android .

Au lieu d'écrire

Log.d(TAG, string1 + string2 + arg3.toString());

avoir comme

if (BuildConfig.DEBUG) Log.d(TAG, string1 + String.format("%.2f", arg2) + arg3.toString());

Proguard peut maintenant supprimer StringBuilder et toutes les chaînes et méthodes qu'il utilise en cours de route, de la version optimisée DEX. Utilisez proguard-android-optimize.txtet vous n'avez pas à vous soucier de android.util.Log dans votre proguard-rules.pro:

android {
  …
  buildTypes {
    release {
      minifyEnabled true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
  }
}

Avec le plugin Android Studio Gradle, est assez fiable, vous n'avez donc pas besoin de constantes supplémentaires pour contrôler le stripage.BuildConfig.DEBUG

Ajoutez ce qui suit à votre fichier proguard-rules.txt

-assumenosideeffects class android.util.Log {
  public static *** d(...);
  public static *** w(...);
  public static *** v(...);
  public static *** i(...);
}

C'est ce que je faisais sur mes projets Android ..

Dans Android Studio, nous pouvons effectuer une opération similaire en appuyant sur Ctrl + Maj + F pour rechercher dans l'ensemble du projet (Commande + Maj + F dans MacOs) et Ctrl + Maj + R pour remplacer ((Commande + Maj + R dans MacOs))

J'ai une solution très simple. J'utilise IntelliJ pour le développement, donc les détails varient, mais l'idée devrait s'appliquer à tous les IDE.

Je choisis à la racine de mon arbre source, clique avec le bouton droit et sélectionne pour faire "remplacer". Je choisis alors de remplacer tous les "Log". avec "// Log.". Cela supprime toutes les instructions de journal. Pour les remettre plus tard, je répète le même remplacement, mais cette fois comme remplacer tous "// Log". avec "Journal".

Fonctionne très bien pour moi. N'oubliez pas de définir le remplacement comme sensible à la casse pour éviter les accidents tels que «Dialogue». Pour une assurance supplémentaire, vous pouvez également effectuer la première étape avec «Journal». comme chaîne à rechercher.

Brillant.

Comme le commentaire de zserge l'a suggéré,

Le bois est très agréable, mais si vous avez déjà un projet existant - vous pouvez essayer github.com/zserge/log. C'est un remplacement direct pour android.util.Log et possède la plupart des fonctionnalités de Timber et bien plus encore.

sa bibliothèque de journaux fournit un commutateur d'activation / désactivation simple d'impression de journaux comme ci-dessous.

De plus, il suffit de changer de importligne et rien n'a besoin de changer pour l' Log.d(...);instruction.

if (!BuildConfig.DEBUG)
    Log.usePrinter(Log.ANDROID, false); // from now on Log.d etc do nothing and is likely to be optimized with JIT

J'ai amélioré la solution ci-dessus en prenant en charge différents niveaux de journal et en modifiant automatiquement les niveaux de journal selon que le code est exécuté sur un appareil en direct ou sur l'émulateur.

public class Log {

final static int WARN = 1;
final static int INFO = 2;
final static int DEBUG = 3;
final static int VERB = 4;

static int LOG_LEVEL;

static
{
    if ("google_sdk".equals(Build.PRODUCT) || "sdk".equals(Build.PRODUCT)) {
        LOG_LEVEL = VERB;
    } else {
        LOG_LEVEL = INFO;
    }

}


/**
 *Error
 */
public static void e(String tag, String string)
{
        android.util.Log.e(tag, string);
}

/**
 * Warn
 */
public static void w(String tag, String string)
{
        android.util.Log.w(tag, string);
}

/**
 * Info
 */
public static void i(String tag, String string)
{
    if(LOG_LEVEL >= INFO)
    {
        android.util.Log.i(tag, string);
    }
}

/**
 * Debug
 */
public static void d(String tag, String string)
{
    if(LOG_LEVEL >= DEBUG)
    {
        android.util.Log.d(tag, string);
    }
}

/**
 * Verbose
 */
public static void v(String tag, String string)
{
    if(LOG_LEVEL >= VERB)
    {
        android.util.Log.v(tag, string);
    }
}


}

ProGuard le fera pour vous sur votre version de version et maintenant les bonnes nouvelles d'Android.com:

http://developer.android.com/tools/help/proguard.html

L'outil ProGuard réduit, optimise et obscurcit votre code en supprimant le code inutilisé et en renommant les classes, les champs et les méthodes avec des noms sémantiquement obscurs. Le résultat est un fichier .apk de plus petite taille qui est plus difficile à rétroconcevoir. Étant donné que ProGuard rend votre application plus difficile à rétroconcevoir, il est important que vous l'utilisiez lorsque votre application utilise des fonctionnalités sensibles à la sécurité, comme lorsque vous octroyez une licence à vos applications.

ProGuard est intégré au système de construction Android, vous n'avez donc pas à l'invoquer manuellement. ProGuard ne s'exécute que lorsque vous générez votre application en mode édition, vous n'avez donc pas à gérer le code obscurci lorsque vous générez votre application en mode débogage. L'exécution de ProGuard est entièrement facultative, mais fortement recommandée.

Ce document décrit comment activer et configurer ProGuard ainsi qu'utiliser l'outil de retrace pour décoder les traces de pile obscurcies

J'aime utiliser Log.d (TAG, une chaîne, souvent un String.format ()).

TAG est toujours le nom de la classe

Transform Log.d (TAG, -> Logd (dans le texte de votre classe

private void Logd(String str){
    if (MainClass.debug) Log.d(className, str);
}

De cette façon, lorsque vous êtes prêt à créer une version finale, définissez MainClass.debug sur false!

Les journaux peuvent être supprimés à l'aide de bash sous linux et sed:

find . -name "*\.java" | xargs sed -ri ':a; s%Log\.[ivdwe].*\);%;%; ta; /Log\.[ivdwe]/ !b; N; ba'

Fonctionne pour les journaux multilignes. Dans cette solution, vous pouvez être sûr que les journaux ne sont pas présents dans le code de production.

Je sais que c'est une vieille question, mais pourquoi n'avez-vous pas remplacé tous vos appels de journal par quelque chose comme Boolean logCallWasHere = true; // --- reste de votre log ici

C'est pourquoi vous saurez quand vous voulez les remettre, et ils n'affecteront pas votre appel de déclaration if :)

Pourquoi ne pas simplement faire

if(BuildConfig.DEBUG)
  Log.d("tag","msg");

? Aucune bibliothèque supplémentaire n'est nécessaire, aucune règle de proguard qui a tendance à bousiller le projet et le compilateur java laissera simplement de côté le bytecode pour cet appel lorsque vous effectuez la construction de la version.

Voici ma solution si vous ne voulez pas jouer avec des bibliothèques supplémentaires ou modifier votre code manuellement. J'ai créé ce bloc-notes Jupyter pour parcourir tous les fichiers java et commenter tous les messages du journal. Pas parfait mais ça a fait le boulot pour moi.

mon chemin:

1) activer le mode de sélection de colonne (alt + shift + insert)

2) sélectionnez sur un Log.d (TAG, "texte"); la partie «Journal».

3) puis faites shift + ctrl + alt + j

4) cliquez sur la flèche gauche

5) faire shift + end

6) appuyez sur supprimer.

cela supprime tous les appels LOG à la fois dans un fichier java.

Vous pouvez essayer d'utiliser cette méthode conventionnelle simple:

Ctrl+ Shift+R

remplacer

Log.e(

Avec

// Log.e(

Facile avec kotlin, déclarez simplement quelques fonctions de haut niveau

val isDebug: Boolean
    get() = BuildConfig.DEBUG

fun logE(tag: String, message: String) {
    if (isDebug) Log.e(tag, message)
}

fun logD(tag: String, message: String) {
    if (isDebug) Log.d(tag, message)
}

la manière la plus simple;

utilisation DebugLog

Tous les journaux sont désactivés par DebugLog lorsque l'application est publiée.

https://github.com/MustafaFerhan/DebugLog