In order to build different versions of my app, I added the applicationPackage property to the build file:
jfxmobile {
javafxportsVersion = '8.60.6'
android {
manifest = 'src/android/AndroidManifest.xml'
applicationPackage = 'com.myapp.lite'
}
}
But the generated apk file is still named after the package property in the AndroidManifest:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.myapp"
android:versionCode="1"
android:versionName="1.0.0" >
What's the proper way to change the package name if you want to build different flavors of your app like "Lite" and "Full" ?
Currently, when you use the Gluon plugin to create a Mobile project, the jfxmobile plugin builds the default AndroidManifest.xml file, based on your input (main class, package name). After that, any modification you make on your project (like refactoring the main class name or the package name) won't be updated on the Android manifest file, so you have to do it manually yourself.
If you have a look at the source code of the plugin, there is a way to force recreating the manifest every time you run the android task: Just delete the file under src/android/AndroidManifest.xml, and remove the manifest property in the build.gradle file. When you run android or androidIntall, a new default Android manifest will be created under build/javafxports/tmp/android, taking into account your applicationPackage property.
Notice this won't allow any custom change in the manifest, like adding or removing permissions or changing the version numbers. So clearly it is not a complete solution.
Another approach will be creating a custom task that recreates the AndroidManifest file based on your own settings, based on the way the plugin does it itself.
You can file an issue under javafxports repo if you think a more dynamic solution is required to build the apk. For instance, allowing the use of the same approach as in Android, where a strings.xml file is used to set some metadata (#string).
Related
Do we really need to include android:versionCode and android:versionName in AndroidManifest.xml?
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.my.application"
android:versionCode="1"
android:versionName="1.0.0">
These values are indicated in my App/build.gradle under defaultConfig. I see no value in putting them in AndroidManifest. The argument I received from colleague was, this value will be shown later in AppInfo when user tap into it.
According to Android docs, I don't see any highlight about settings these in Android Manifest either.
As described in the official doc:
To define the version information for your app, set values for the version settings in the Gradle build files. These values are then merged into your app's manifest file during the build process.
Note: If your app defines the app version directly in the <manifest> element, the version values in the Gradle build file will override the settings in the manifest. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the <manifest> element and define your version settings in the Gradle build files instead.
The docs state:
As mentioned previously, next to the main sourceSet is the androidTest sourceSet, located by default in src/androidTest/
....
The sourceSet should not contain an AndroidManifest.xml as it is automatically generated.
So, if I want to add extra permissions for the tests, what is the correct way to do it?
As of version 0.13.0 (released 2014/09/18) of the Android Gradle plugin it is now possible to have a custom manifest for Android tests.
It is now possible to provide a manifest for test apps (src/androidTest/AndroidManifest.xml)
Source: https://sites.google.com/a/android.com/tools/tech-docs/new-build-system
For more information see the sample "gradle_examples_0.14.4/tree/master/androidManifestInTest" - although it seems to me that there's no special configuration needed.
I'd like to know if there is a way to add certain permissions (or anything) to an android manifest file, but so that its only used during test runs - not production. I'm looking for something programmatic, not cutting and pasting when I'm testing.
Here's the context:
I'm reading this article: http://developer.android.com/training/location/location-testing.html, the best practice for test running an app used to be creating a 'test-app' however with android studio we now are not meant to create a new app - all testing should be done through the app. (Thank you gradle)
The issue is that this article is written with a testing permission (ACCESS_MOCK_LOCATION) in it, and I don't want that sitting in my app - and if there's a good way of doing it, I'd like to do that.
UPDATE: The reason I had this problem was because of a misunderstanding of the set up of android studio architecture since the migration to Gradle.
I didn't realize that the build types shared the 'androidTest' and 'main' source folders. And so when testing or running the unfinished app, it takes the debug files (if any) and adds all the production stuff to it. So in my case, I added a empty manifest file in debug and simply added the two permissions to it. When I run or test, gradle adds all of my apps things from its other manifest to it this skeletal file (or vice versa, I'm uncertain).
So in the end we don't need to modify the androidTest folder (in fact I don't think we are allowed to add a manifest here) as its completely generated based off of whether a user is running on debug or deployment. Cheers! :-)
Let's say you use the default debug and release build types and you run your tests against the debug build type.
In this case you can create a src/debug/AndroidManifest.xml and add the additional permissions you need in your debug builds:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="your.package">
<uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION"/>
</manifest>
If your project does not follow the default folder hierarchy and you want to add permissions to the debug build add the following block.
sourceSets {
debug {
manifest.srcFile '<your folder>/AndroidManifest.xml'
}
}
I have an application that supports different domains. My code is developed under the package: com.example. I would like to publish multiple application under different packages like:
com.example.domain1, com.example.domain2, etc.
In the manifest I define:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.domain1"
....
and for domain2:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.domain2"
The problem I am facing is that once I change the base package name from domain1 to domain2 I need to rename all my packages in the src folder as well as layouts. What I am looking for is to keep the same base packaging com.example and distribute the different apps under its sub-domains.
Is there a better way?
Clarification:
When changing the package name, the resources file changes from com.example.R to com.example.domain2.R. This means that I have to go into all src java classes and layouts etc. and update the generated R file location. That is not handy.
I ended up marking my main project as a library and then creating a project for each domain and linking to the library.
No need to play around with the manifest or the R.java file.
Thanks to #Tenfour04 for pointing me in the right direction!
In your manifest, each Activity, Service, Provider and Receiver has a name attribute. By default they use a shortcut like ".MainActivity" The leading . is a shortcut for the package name at the top level of the manifest.
So if you don't want to rename all those packages in the src folder, just type out explicit names for the Activities, Services, Providers, and Receivers in your manifest, for example, android:name="com.example.sharedmultiprojectdomainname.MainActivity".
If you are using Gradle as your build system, you might want to incorporate build variants into your build, which will solve package problems. More on this can be found in this Google I/O speech
Hope this helps.
I have already published an app called com.mycompany.mygame on google play.
I then decided to publish an ad free version of it. I did not change the package name in eclipse because I noticed that in the "export" process you have the opportunity to have the final apk set as anything you like. So I set it there as com.mycompany.mygameaf - note the additional "af" on the end. But then when tried to upload it to the market, google said:
You need to use a different package name because "com.mycompany.mygame" is already used by one of your other applications
So now I'm confused. Is the complaint because I'm not allowed to have an apk that is a name which is and extension of a previous app? Or does the final apk somehow have knowledge of what the original name was?
What is the easiest way to resolve this?
Apart from correcting app name in the Manifest I also had to change applicationId in the app's gradle.build file.
defaultConfig {
applicationId "com.example.changednameofmyapp"
...
}
Also, if you're using ProGuard, do not forget to change appropriate rules in your proguard-rules.pro
Just search the old package name in the whole project and change it.
Regardless of the name of the .apk file, the package name of the Application contents inside it must be unique.
You can use refactor-rename to change this, though make sure that the change penetrates to the manifest file, proguard configuration, etc.
The name of the APK doesn't matter, its the package name within the AndroidManifest file that counts.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.yourcompany.yourapp"
There can only be one app on the market with that package name so in order to publish your ad free version you would have to change the package name in the manifest file, e.g. add the af onto the end of the package name within your manifest.
As mentioned in other answers, you're development would be simpler if you put all the shared code and assets a common library project that is a dependency of your paid and free versions.
You may also wish to play with the new Gradle build system (in Android Studio) which allows you to dynamically set things like the package name at runtime. It also allows you to switch resources during build time, which is extremely convenient; You could have a boolean resource that represents whether the current app is the paid version. This allows you to enable/disable app features based on a check to that value.
The filename of the APK is irrelevant, the package name of your app is used as a unique identifier - it is in the root element in the AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.packagename"
android:versionCode="1"
android:versionName="1.0" >
When you initially create your project in Eclipse it creates an actual package structure which matches this package name for you to put your source files in.
You can actually chnage your package name by modifiying this manifest value and you can just keep the folder/package structure as is - it does not need to match your actual application package name.
Alternatively, right click your project in Eclipse, go to "Android Tools" and then select "Rename Application Package"
After you do this you should be able to submit your binary
The package name in the manifest is used to identify the application within Android and within Google Play. So different apps need different names.
The easiest workaround might be to just create a new package, with no code in it, and use that as the app's package name in the manifest.
What I've done to solve my many-apps-from-one-codebase problem is put all the apps' code in a library project, and then I have several app projects that use that library. The app projects contain no code, just a manifest and custom resources.