Introduction

In Android development, "printing to the console" usually means sending messages to Logcat, not to a traditional terminal window. Android apps run inside the Android runtime, so the normal debugging surface is the Logcat pane in Android Studio. The recommended way to write messages there is the Log class, which lets you label and filter output by severity and tag.

Use The Android Log Class

The standard API is android.util.Log.

1import android.util.Log;
2
3public class MainActivity extends AppCompatActivity {
4    private static final String TAG = "MainActivity";
5
6    @Override
7    protected void onCreate(Bundle savedInstanceState) {
8        super.onCreate(savedInstanceState);
9        setContentView(R.layout.activity_main);
10
11        Log.d(TAG, "Activity created");
12        Log.i(TAG, "App started normally");
13        Log.e(TAG, "Example error message");
14    }
15}

The main logging levels are:

• 'Log.v for verbose'
• 'Log.d for debug'
• 'Log.i for info'
• 'Log.w for warning'
• 'Log.e for error'

These messages appear in Logcat, where you can filter by app process, tag, or severity level.

View The Output In Logcat

In Android Studio, open the Logcat tool window and choose your running device or emulator. Then filter by your application package or by the tag you used.

Using a consistent tag is important because Android logs include system noise from many processes. Without filtering, it is easy to lose your own messages in the stream.

Android Studio also lets you narrow the view by process, package, or text search. That makes good tag names worth the effort, especially in larger apps.

System.out.println Also Works, But It Is Not Ideal

You may also see this in sample code:

System.out.println("Hello from Android");

Android usually redirects standard output to Logcat, so the message can appear there. However, this is not the idiomatic Android debugging approach. Log.d and friends are better because they include severity levels and clear tags.

In Kotlin, the recommended approach is the same:

1import android.util.Log
2
3class MainActivity : AppCompatActivity() {
4    override fun onCreate(savedInstanceState: Bundle?) {
5        super.onCreate(savedInstanceState)
6        setContentView(R.layout.activity_main)
7
8        Log.d("MainActivity", "Activity created")
9    }
10}

Logging Exceptions Properly

When you have an exception, pass it directly so Logcat includes the stack trace.

1try {
2    int result = 10 / 0;
3} catch (Exception ex) {
4    Log.e("MathDemo", "Computation failed", ex);
5}

That is much more useful than printing only ex.getMessage(), because the stack trace shows where the failure happened.

Remove Or Limit Verbose Logs In Production

Logging is useful during development, but excessive debug output can clutter Logcat and leak information if you leave it everywhere.

A common pattern is to guard noisy logs with the build configuration:

if (BuildConfig.DEBUG) {
    Log.d("MainActivity", "Debug-only message");
}

That keeps development logs available while reducing unnecessary noise in release builds.

Common Pitfalls

The most common mistake is looking for a traditional console window instead of Logcat. Android Studio debugging output normally lives there.

Another issue is using inconsistent tags or no tags at all. Good tags make logs searchable and easy to filter.

It is also easy to overuse System.out.println. While it can work, the Log API is the proper Android tool and gives you much better control.

Finally, avoid logging sensitive data such as tokens, passwords, or personal information. Debugging output often survives longer than expected.

Summary

• In Android Studio, console-style output normally goes to Logcat.
• Use android.util.Log for tagged, level-based logging.
• Filter Logcat by app or tag so your messages are easy to find.
• 'System.out.println may work, but Log.d and related methods are the recommended approach.'
• Keep debug logging useful, structured, and free of sensitive data.