This is a hierarchy issue.
Consider this:
Root .
|
+- package
+ sub
+ SubClass.java
+ other
+ OtherClass.java
+ SubOtherClass.java
+ Main.java
+ MainKotlin.kt
Those can be Kotlin files, Java files, anything, it doesn't matter.
Main.java can access classes, interfaces, etc. in the same package without needing to import it.
Which means, if either of Main.java or MainKotlin.kt wants to access classes in:
- Other packages
- Sub packages
- Parent packages (not applicable in this case, but the same rules apply)
It needs to import them explicitly. So this Main.java:
public class Main {
private SubClass subClassInstance;
private MainKotlin kotlinInstance;
// Content
}
Only needs to import SubClass. If you explicitly add an import for MainKotlin, IntelliJ/Android Studio will say it's not used.
On to your problem:
Your package is just called ui, which lies in the root. However, your package ID is info.dodata.clipboard. As a result, it will generate the R file in there. You can change the package, but you'll still need to import it for files outside that package.
As a result, any Activities not in the info.dodata.clipboard package, which means sub-packages, parent packages, or entirely separate packages, need to explicitly import it.
So, you have two options:
The first one is relatively simple: move your activities to the info.dodata.clipboard package
The second one is the one you're currently using; import it.
Most modern IDEs and editors have autocomplete, so you don't need to copy-paste the import statement everywhere you need it. Put the caret on R in a new file (when it shows an unresolved reference), and use Alt+Enter.
Like I said, one way to fix this is changing the app ID. This isn't necessarily feasible though, and would also change the way it shows up if you post it to an app store. This post explains that pretty well.
However, if you're absolutely not in the mood for adding the import (which, IMO, is easier), you can add type aliases.
Before I get on with this, I do want to mention why this would work, but also limitations.
You'd place any applicable ones in the same package as your activities. As I've already mentioned, you don't need explicit imports when it's in the same package.
However, if you have multiple packages with activities, you'd need to repeat these for each of those, which is a weakness.
Also, you can't just typealias R = com.package.R;, because it doesn't allow you to access subclasses. You can, however, do this:
typealias id = com.example.R.id;
typealias layout = com.example.R.layout;
typealias anim = com.example.R.anim;
// ... and so on
// Optionally importing it for this and just using `R.layout` instead of `com.package.R.layout`
Like I said though, this prevents you from using R.type.name. But it does allow you to i.e. write layout.activity_main. When it's compiled, it will still reference the same field.
Although it is easier just importing it, this is an option if you absolutely don't want to do that. But even the type aliases end up importing it, so you won't get around imports/qualified class names
