Android Studio using a library and project with the same package name

Question

I have a library I use as a base for all my android apps and has the following manifest file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.android"
    xmlns:tools="http://schemas.android.com/tools"
    android:versionCode="36"
    android:versionName="1.b" >

    <uses-sdk
        android:minSdkVersion="5"
        android:targetSdkVersion="21"

        tools:overrideLibrary="com.facebook.android"/>

I then try to use it in one of my projects which has the following manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.android"
    xmlns:tools="http://schemas.android.com/tools"
    android:versionCode="36"
    android:versionName="1.6" >

    <uses-library
        android:name="com.example.android"
        android:required="true"/>

    <uses-sdk
        android:minSdkVersion="5"
        android:targetSdkVersion="21"

        tools:overrideLibrary="com.facebook.android"/>

Note that the package name used is the same: com.example.android. Since the app is published under com.example.android, I cannot change it for the app. As for the library, for historical reasons, it has the same pacakge name. When I build the project, I get the following error:

FAILURE: Build failed with an exception.

• What went wrong: Execution failed for task ':exampleCom:processDebugResources'.

  Error: A library uses the same package as this project: com.example.android You can temporarily disable this error with android.enforceUniquePackageName=false However, this is temporary and will be enforced in 1.0

I do not want to change the package name of either library or app. I am not sure where to add the "android.enforceUniquePackageName=false" . Any ideas? Also, how to solve beyond 1.0 (which I am already using)?

Answer 1

You can add enforceUniquePackageName=false in the app modules build.gradle file under android:

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"
    enforceUniquePackageName = false
    ...
}

Unfortunately this results in another problem with an unfixed bug from the build tools.

Error:Execution failed for task ':app:packageAllDebugClassesForMultiDex'. java.util.zip.ZipException: duplicate entry: ... BuildConfig.class

See https://stackoverflow.com/a/27310034/668400

Answer 2

An ounce of prevention is worth a pound of cure. It may not help this particular situation, but for future developers to avoid getting into this situation, please note the JLS recommendation in Chapter 6. Names which addresses this very problem:

Package Names

Developers should take steps to avoid the possibility of two published packages having the same name by choosing unique package names for packages that are widely distributed. This allows packages to be easily and automatically installed and catalogued. This section specifies a suggested convention for generating such unique package names. Implementations of the Java SE platform are encouraged to provide automatic support for converting a set of packages from local and casual package names to the unique name format described here.

If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create a situation that is difficult or impossible for the user or programmer to resolve. The class ClassLoader can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a naïve program.

You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as oracle.com. You then reverse this name, component by component, to obtain, in this example, com.oracle, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names. Such a convention might specify that certain package name components be division, department, project, machine, or login names.