IssueTracker

I am not sure what is the desired behaviour. applicationPackage is usually set with AndroidModuleModel.getApplicationId() and it returns "one.name.debug" in this case. Is this correct behaviour? If not, shall this method return something else or should we call something else instead? We use applicationPackage in a few places, for example we add "import ${applicationPackage}.R;" to the main fragment code file. Is seems that using applicationPackage is correct here?

Also, sometimes we use applicationPackage when we have no known package, i.e. we create something in a module, not inside some specific package. Usually it is used for package name suggestion but in some cases we use suggested package implicitly, without rendering it in UI. Is it an okay thing to do or should we use some other default?

So let us say the the default package is one.name. This is the name we are shipping to production with.

The compiler generates the R file with the name of one.name.R. This makes sense since that is the correct name for compilation as it needs to match and be consistent regardless of if an applicationIdSuffix was specified so that developers don't have to change the import headers for each variant.

The bug is the template is filling in with import one.name.debug.R which doesn't exist if an applicationIdSuffix = ".debug" was specified.

I had long given up on this bug and just not use templates or grumble about removing the incorrect ".debug" addition to the import path when I do. I originally raised this issue 4 years ago: https://issuetracker.google.com/issues/37078543

Please use org.jetbrains.android.dom.manifest.AndroidManifestUtils.getPackageName which returns the so-called resource package name (the Java package name of the R class) and it does not depend on the currently selected build variant.

applicationId also called (in APKs and Android OS it is also called packageName) is not the same as the resource package name. It is used to as an ID when the app is deployed and might differ from the R class package name.

Unfortunately the JavaDocs to this and related methods are not helpful and contradict what I said above. We need to fix them and I'm adding tests to avoid any future ambiguity.

The method itself always returns the package name from the main manifest which is the R class Java package name and I'm adding a test to ensure this behaviour and avoid any ambiguity.