You can develop Android applications using Java, including projects built with the Android Views system. Use 4 foundations: a suitable project, a view layout, an Activity that connects behaviour and an understanding of lifecycle changes. Android now recommends Kotlin for new development, but that recommendation does not mean existing Java applications should be treated as unusable.
For a beginner or a business maintaining a Java codebase, the first goal is a small understandable app rather than an elaborate production claim. This guide explains a Views-based starting workflow and the handover questions it creates. It does not present a Kotlin-only tutorial as evidence for Java or claim that a snippet is a complete released application.
What should you know before starting a Java Android app?
Android’s Kotlin-first explanation describes the platform’s current language direction and continued Java API support. Its Views layout guide explains View and ViewGroup structures. Those are different subjects: language choice concerns implementation, while the layout system describes how an interface is structured.
Use a currently supported Android Studio setup and a project configuration appropriate to Java and Views. Templates and labels can change between releases, so inspect what the project actually generates. A Compose-focused template may not provide the Views-based structure assumed by an older Java tutorial.
Identify the application module, source directory, resources and manifest. Java code supplies behaviour, resources can supply layouts and strings, and the manifest declares relevant components. Understand that separation before copying code into a file whose role is unclear.
| Project part | Purpose | Initial check |
|---|---|---|
| Java source | Application behaviour | Package and class match the project |
| Layout resource | View hierarchy | Resource is in the intended layout directory |
| String resources | User-facing text | Displayed wording is not scattered unnecessarily |
| Manifest | Declared application components | Intended entry Activity is correctly configured |
| Build configuration | Dependencies and platform settings | Project builds under its recorded toolchain |
| Device or emulator | Runtime test environment | The actual app opens and behaves as expected |
The table is an original orientation aid. It is not a replacement for the current project setup instructions or a promise that every existing project uses identical file organisation.
How do you connect a layout to Java behaviour?
In a Views-based app, a layout can be described in XML and loaded by the Activity. The official layout guide describes this separation and shows how view resources are referenced. Start with a simple screen containing a text element and a button rather than introducing several dependencies at once.
The following is an illustrative fragment inside an already configured Activity. It assumes that the project contains the named layout and view resources; it is not a complete project or a claim of a compiled acceptance test.
setContentView(R.layout.activity_main);
TextView status = findViewById(R.id.status);
Button action = findViewById(R.id.action);
action.setOnClickListener(view -> status.setText(R.string.action_recorded));
The exercise is to understand the relationship: the layout defines the controls, resource identifiers locate them and the listener responds to an action. Create the matching resources and required imports in the actual project. Do not replace an unresolved resource reference with an arbitrary number to make an error disappear.
Run the small example before adding network requests, accounts or storage. Confirm that the button changes the intended text and that the interface remains understandable after ordinary navigation. This isolates basic wiring problems from the more complex behaviour introduced later.
Why does the Activity lifecycle matter?
Android’s Activity lifecycle guide explains that an Activity moves through states as users leave and return or the system changes its process state. Code should not assume that a screen exists unchanged forever merely because it worked during the first uninterrupted test.
Distinguish temporary interface state from information that must be retained. A label changed for demonstration is different from a customer’s entered order details. Decide what should survive rotation, backgrounding or recreation, then use the appropriate architecture and state mechanisms for that requirement.
Avoid placing every responsibility inside an Activity. The lifecycle is one reason that a large screen class becomes difficult to reason about. Separate interface handling from business rules and data operations as the app grows, and document the dependencies a later maintainer needs to understand.
Use this original first-app test record:
| Scenario | Action | Question to answer |
|---|---|---|
| Initial launch | Open the app from its intended entry point | Does the right screen appear? |
| View wiring | Trigger the sample action | Does the intended control update? |
| Content variation | Use longer real text | Is important information still visible? |
| Orientation | Change the supported orientation | Is the expected state retained or restored? |
| Background | Leave and return through an ordinary route | Does the app resume coherently? |
| Invalid input | Exercise a relevant validation case once added | Is correction possible without losing context? |
| Rebuild | Build from a clean checked-out copy | Are dependencies and setup reproducible? |
The record contains requirements to verify, not results already obtained. Keep the actual project version and test environment with any findings. A copied tutorial screenshot cannot establish that your implementation passed the same scenarios.
When is Java a reasonable project choice?
An established Java codebase, available team expertise or a defined integration can support continuing with Java. A new project should also consider Android’s Kotlin recommendation and the libraries and UI approach being selected. Decide from the actual maintenance and platform requirements rather than a claim that one language always costs less.
Record where Java and any Kotlin code meet. Mixed-language projects need understandable boundaries and a build that a maintainer can reproduce. A successful local run on one developer’s machine is not a complete handover.
Keep signing material, account ownership and release responsibilities under authorised business control. These concerns are separate from the source language and cannot be solved by a tutorial’s sample Activity.
Supply the resources the Java fragment expects
Inside the existing project’s layout resource directory, a minimal illustrative activity_main.xml can contain:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<TextView android:id="@+id/status"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/ready" />
<Button android:id="@+id/action"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/record_action" />
</LinearLayout>
Define ready, record_action and action_recorded in the project’s string resources with the illustrative values “Ready”, “Record action” and “Action recorded”. Import android.widget.TextView and android.widget.Button. Put the Java wiring after super.onCreate(savedInstanceState) in the configured Activity’s onCreate method, using the project’s actual package and base class. Build and run it in that project, select the button, then rotate and observe that this transient text change has no implemented persistence. This is a source-backed exercise, not a claimed compiled test.
See web development for related application requirements. To discuss an Android Java project, get started with the existing codebase, target workflow and evidence of the behaviour that needs changing.
Before extending the sample, have another developer explain the resource references and callback behaviour. If the explanation depends on guessing what a copied line does, simplify the exercise and consult the corresponding platform reference. Understanding the first screen is a better foundation than accumulating unexplained snippets.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.