程式幾乎行行都可以出錯。要看程式中的哪一部分可能會出錯，實在是門很深的學問。要是沒有線索，光靠我們的腦袋來追蹤判斷，或是靠直覺東試試、西改改，這種作法就跟使用巫毒術扎娃娃一樣，直到被扎的人哪天身體疼了，就算巫毒作法有效。這樣實在不是一種好的除錯方式。
「Log」函式的作用，就像是色筆一樣，協助我們在程式碼中「作記號」，這些數位記號，會在稍後就介紹到的「LogCat」工具中顯示。
依據訊息的類型，我們有五種 Log 訊息形式可以用作記錄。
Log.v (VERBOSE) 詳細訊息
Log.d (DEBUG) 除錯訊息
Log.i (INFO) 通知訊息
Log.w (WARN) 警告訊息
Log.e (ERROR) 錯誤訊息
一般較常用的是 Log.d(除錯訊息) 、Log.w (警告訊息)，和 Log.e (錯誤訊息)。範例中多使用 Log.d(除錯訊息) 。
//-[Code]------------------------------------------------------------------
Log.d(TAG, "find Views");
private static final String TAG = "ecAndroid";
catch(Exception err)
{
Log.e(TAG, "error: " + err.toString());
Toast.makeText(Bmi.this, getString(R.string.input_error), Toast.LENGTH_SHORT).show();
}
//-[Code]------------------------------------------------------------------
如果是程式碼語法格式上的問題，我們可以在編譯前，就透過開發工具提供的預先編譯警示，得到提醒並及早改正。在我們改正好這些語法格式上的問題後，開發工具才允許我們實際編譯應用程式。接著，才能將編譯好的應用程式上傳至模擬器，再開始進一步的測試。
除了程式碼語法格式上的問題，絕大部分會造成大麻煩的，是隱藏在程式邏輯中的問題。這些問題只有在模擬器甚至在實際機器上運行時才會出現。為了解決這些問題，我們需要一些協助工具。在 Android 平台上，我們可以透過「Log」函式，來達到自行在程式碼中加入一個個自訂的「記錄點」或「檢查點」。並可以透過開發環境中的「LogCat」工具來查看記錄。當程式流程每次運作到「記錄點」時，相應的「記錄點」就會在開發工具記錄中輸出一筆偵錯用的訊息。開發者透過這份記錄，來檢查程式執行的過程、使用到的參數，是否與我們期望的結果符合。並依此來辨別程式碼中可能出錯的區域，好能對症根治造成問題的程式碼。
其實Android 有二種Debugging 方法，筆者已介紹其一，如要詳細可到以下website 或email給我
http://developer.android.com/guide/developing/debug-tasks.html
