I'm using Intellij14. I am using a Project artifact to produce a release version of the android app. The name appears to be based on the name of the Module under Project Settings.
What I'd like to do is use the android:versionName defined in my AndroidManifest.xml as a part of the APK file name. I'm not sure if there's anything in the IntelliJ build file to allow me to do this that I can see. I'm not sure what I can do short of having a post build script parse the android manifest and rename the file
I use TeamCity as my build server. If this dynamic renaming is a feature that is available only in TeamCity for some reason, that is OK.
Note: I am using an intellij project file, not a gradle build.
Related
New to android development. When we distribute the .apk file, can the receiver extract the google-services.json and use our database or authentication database.
I looked
I have apk file, Is it possible to get android studio project from apk?
and Is google-services.json confidential?
and Is it possible to decompile an Android .apk file?
but don't directly relate
I tried to extract an apk of mine which has google-services.json file and I couldn't find the google-services.json file in extracted folder .
Edit : Here is more info I found
The google-services plugin has two main functions:
1 - Process the google-services.json file and produce Android resources that can be used in your application's code. See Adding the
JSON File more information.
2 - Add dependencies for basic libraries required for the services you have enabled. This step requires that the apply plugin:
'com.google.gms.google-services' line be at the bottom of your
app/build.gradle file so that no dependency collisions are introduced.
You can see the result of this step by running ./gradlew
:app:dependencies.
This means that the google-services.json file will be converted to android resources by google-services plugin during build process .
You can find how google-services.json works over here
can the receiver extract the google-services.json and use our database or authentication database.
Even if the receiver extracts credentials from apk , he cannot access database as the SHA-1 will be different .
I use them often when configuring my project but mostly add snippers as instructed. I have absolutely no clue which file is for what exactly. Can anyone give a clear picture what each file is for.
So far I think
local.properties for environment paths like sdk/ndk location
settings.gradle for including all modules in project where each module has it's own build.gradle
gradle.properties ?
gradle-wrapper.properties ?
gradle.properties
Using gradle.properties to create universal variables
This solution is limited to Android projects as far as I know. In /gradle.properties you can define your universal or project level variables as such: Link
myBuildToolsVersion=20.0.0
myMinSdkVersion=10
myTargetSdkVersion=22
myCompileSdkVersion=22
gradle-wrapper.properties
Internally, Android Studio uses the version of Gradle that is defined in the wrapper configuration. That configuration can be found in gradle/wrapper/gradle-wrapper.properties. When Google decides that it is time to use a new version of Gradle, Android Studio will display a message nudging you to upgrade. All you need to do then is click the message and Android Studio will edit the properties file and synchronize the Gradle installation for you. Link
local.properties
The local.properties file goes in the project's root level.
This file should not be included in source control. After (incorrectly) including this in source control, then deleting the file locally, Android Studio re-created the file for me automatically.
Here is the example content of this file:
## This file is automatically generated by Android Studio.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must *NOT* be checked into Version Control Systems,
# as it contains information specific to your local configuration.
#
# Location of the SDK. This is only used by Gradle.
# For customization when using a Version Control System, please read the
# header note.
#Thu Aug 14 14:49:26 PDT 2014
sdk.dir=C\:\\Program Files (x86)\\Android\\android-studio\\sdk
Note the sdk.dir= reference to the location of the Android Studio SDK installation (which may be different on different machines).
Link
settings.gradle
':lib' is a logical project path, which gets mapped to a physical path based on information provided in settings.gradle.
A multi-project build can have an arbitrary directory structure, which is configured in settings.gradle. No need to move directories around, unless you want to. Link
For more and more info about gradle you need to check below links which help you more know about gradle and gradle system. Gradle makes developer life easy for not taking to much headache about library updation , apk generation , import lib easily , product flavors and many more.
http://www.vogella.com/tutorials/Gradle/article.html
https://developer.android.com/studio/build/gradle-tips.html
Gradle includes two properties files, located in your root project directory, that you can use to specify settings for the Gradle build toolkit itself:
gradle.properties
This is where you can configure project-wide Gradle settings, such as the Gradle daemon's maximum heap size.
local.properties
Configures local environment properties for the build system, such as the path to the SDK installation. Because the content of this file is automatically generated by Android Studio and is specific to the local developer environment, you should not modify this file manually or check it into your version control system.
So,
We are using Dagger 2 in our Android application.
Code generated by
Dagger 2 is located in build/generated/source/apt.
In the documentation of apt-plugin it states that :"Using this plugin Android Studio will be configured to place the generated sources on the build path, preventing errors in the IDE"
If I remove apt-plugin from my build.gradle file, in a place where I use generated code I see compilation error. (Which is reasonable, generated code is not my source).
The questions are:
What does it mean that apt-plugin configures Android Studio so that it places generated code to build path ?
From what I know final dex file is generated from source folder that is specified in build.gradle, how do these generated files become the source ?
Thanks.
The apt-plguin is a gradle plugin and as such it runs with your build script.
This plugin configures apt to be run with your build and sources to be generated. It further adds the path of the generated files to your source sets, which is why the build succeeds and Android Studio recognizes the files as well.
For further information you could always have a look on the gradle documentation on Gradle Plugins.
I created a test project to understand how to build and run the tests using command line tool. I managed to create a project, updated it with
android update project -p .
and debug with
ant debug
When I added a library project to this test project, the ant debug started to fail because it couldn't find the build.xml of the library. The only solution I found atm is to update the library project as well (found here). Is this the correct way? I see pom.xml files in many of the libraries that I use. I know it is used by Maven (although I know nothing about it) and it might help me with another solution.
Ant is the official way to build android apk. Maven is an alternative way of doing it (not officially supported, but it works very well).
There are few differences regarding default project layout when working with maven or ant, but it's possible to have both build system working on the same source code if you do some additionnal configuration work (i.e. some information will be duplicated).
Default project layout with maven
java source files are under `/src/main/java``
dependencies are defined in the pom.xml (using the maven way of defining dependencies, with type apklib for android libraries)
Default project layout with ant (and eclipse ADT plugin)
java source files are under /src
dependencies are defined in /project.properties and are specified using relative path.
Here is an example of project.properties (it's a typical example of a library project referencing 2 other library project):
target=android-15
android.library=true
android.library.reference.1=../somelib
android.library.reference.2=../someOtherLib
(as you can see some additionnal information are stored in this file : the android target and the fact that the project is an library or an app. When you use maven, this information is in the pom.xml)
How to build a maven android lib with ant ?
The problems (when you need to build a maven-layout-android-library with ant) are the following:
having a proper /build.xml (it can be done through android update library-project ... here is the official doc about this command)
having a proper /project.properties (it is partially done by the android update ... command, but you may need to add some android.library.reference by hand or with eclipse ADT plugin)
telling ant that the java source files aren't at the default location, but are under /src/main/java
For this last point, here is how to do it:
create a file /ant.properties (in your maven-layout-android-library)
put the following entry in it:
source.dir=src/main/java
(Important : it is not always required because sometimes the java source files are already under /src in the maven-layout-project and in this case, the pom.xml contains the information that the source dir is /src)
And that's all. Now, your maven-layout-android-library can be build with ant debug
I have two Android projects, one shared library and the app. Now I want to compile the app with dependency to the library. In Eclipse, it works very well. After that, I upload it via git to my repository and trigger Jenkins to build both projects.
My problem is, that the error occurs: "sdk/android-sdk-linux/tools/ant/build.xml:440: ../shared-lib resolve to a path with no project.properties file for project". That's clear, because in Jenkins the jobs are stored different than under Eclipse.
Another problem is, that Eclipse compiled the shared to ".jar" and Ant compiled it to "classes.jar" (is named in sdk/android-sdk-linux/tools/ant/build.xml).
Ant scripts should allow you to include whatever files you need. In your case I will suggest you move the reference to the shared-lib to local.properties file (this file should also be read by the ant script generated by update-project. Keep the adequate path for jenkins in the repository and modify the file locally for the local built. In the file in the repository you will need to have something like:
android.library.reference.1=../classes.jar
EDIT By the way the suggestion of the second properties file is just because this file is really meant to store location-specific properties.
I fixed it with copy files. The first project builds my shared-lib.jar. The other projects (phone and tablet) copy this file (shared-lib.jar) to there libs-folder and build correctly. But now I have different projects.propertieson the server and my dev-client. This one is not checked in into git.