Disabling logs and their associated views for production

One of the things I have added to my box of tools for app development is a some code to allow application logs to be placed in a database (instead of a normal file) for viewing from within the app on a phone. This is obviously not something I would release to production, but is very handy for troubleshooting directly on my development release on the phone.
In fact there are a number of development features that a person would not want to get out into the wild. I configure these in this way.

First I created file called config.xml and placed it in my values folder. I put entries like this in there:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <bool name="db_logging_on">false</bool>
    <bool name="db_log_viewer_on">false</bool>
</resources>

Then I created a Java class called Log. This contains methods which mirror those in the android.util.Log class. Stuff like Log.d(TAG, "log string"); These methods do however take a context object to allow them to write to a database and get access to resources etc.
So this is the part of the Log class which checks the config.xml to see whether or not to log to db:

if (!LOGGING_SET_UP) {
Resources res = CONTEXT.getResources();
LOG_TO_DB = res.getBoolean(R.bool.db_logging_on);
LOGGING_SET_UP = true;
}
android.util.Log.d(tag, in);
if (LOG_TO_DB) {
if (HELPER == null) {
HELPER = new FlowHelper(ctx);
}
HELPER.insertAppLog(tag, in);
}

In terms of performance, none of this is a good idea! But I reckon that the 'feel' it gives me for the apps operation on a real device, maybe while I am on the bus, or otherwise not distracted by anything else, is well worth it. I can always strip this stuff out prior to production release if TraceView shows it to be a bad idea.

To make this logged info in the db visible I also have a list view for displaying the values. The list view incorporates a filter mechanism and  a way to clear the log down in case it gets too big to work with comfortably. Even if the logging to db is switched off though, this view being visible is a very bad thing in production. It confuses me, I can only imagine what it would mean to Joe User :)

To prevent any surprising moments when menu is clicked I have this code in the View from which I launch the LogViewer:

@Override public boolean onCreateOptionsMenu(Menu menu) { Resources res = getResources(); boolean logViewerOn = res.getBoolean(R.bool.db_log_viewer_on); if (logViewerOn) { MenuInflater inflater = getMenuInflater(); inflater.inflate(R.menu.dashboard_menu, menu); }
return super.onCreateOptionsMenu(menu); }

Here I am concerned with logs, but this method of storing boolean resources could be used for any non-production feature.