Develop Reference

NDK on Android Studio keeps rebuilding all the time, takes forever

I have a big Android Studio project that has a separate module which contains native code.
The native build is defined with CMake and includes a bunch of source files of C++ code.
I noticed that since a very recent update (might be Android Studio 3.5), NDK rebuilds everything ALL THE TIME.
It can happen with a small change in Java code, switching flavor in an unrelated module in the project, incrementing version code, etc.
This is a major problem, since it can waste 10 minutes at a time for no reason.
I could not find a reasonable way to profile NDK builds in Android Studio and check what's causing the rebuild or what's taking so long.
Unfortunately the project's build files are too big to attach here. Any pointers for things to look after?

For the C/C++ code that you build with cmake, make sure you point cmake to a directory where it can keep its object files and binary outputs.
Let's say you have a dependency on Game in your top level CMakeLists.txt like so:
# dependency: Game
set ( game_src_DIR ../Game )
add_subdirectory( ${game_src_DIR} ${CMAKE_CURRENT_BINARY_DIR}/game )
Then the second parameter to add_subdirectory specified the place where AndroidStudio will keep the object files.
The debug and release object files will live in different subdirs, as will each dependency, so switching debug/release will not clash.

This appears to have been a regression in behavior from Android Studio 3.4 and has been fixed in Android Studio 4.1 Canary 4. Release notes are here.

Often, it helps to split the AS project such that the C++ part, possibly with its Java wrappers become a separate (library) module. This module will hopefully be more stable, not sensitive to increments of app version code.
Such module should not define many flavors, but have careful matching to the flavors of other modules. Sometimes, it makes sense even to disable "debug" variants for such library. There was an effort of the NDK team to better handle debug vs. release build switching, but this is still tricky.
But if after these improvements, insignificant changes to the project still cause massive rebuild, I would suggest to consider ccache.

What is the difference between Proguard and R8?

The new version of Android Studio (3.4) just came out and brings with it default support for R8 instead of Proguard. Could someone explain the key differences between the two and any apparent benefits to using R8?

The history of Android build process kept changing and the developers are constantly trying to make it more efficient concerning build time and generated .dex file sizes. So, throughout the history there has been many variation of the process of generating .dex files from .java files.
Before R8 or D8, the Android build process involved these four steps;
SourceCode(.java) ---javac---> Java Bytecode(.class) ---Proguard---> Optimized Java bytecode(.class) ---Dex---> Dalvik Optimized Bytecode(.dex)
Then, the Android developers decided to merge all the steps in between to 1 step called Jack&Jill for optimization. However, this was introduced in 2015 and abandoned in 2017 due to not being flexible enough to work with all the growing development tools.
Then, D8 was introduced, which is a reverting back to original 4 step build process, with an optimized Dex transform. This implementation produced better quality bytecode than dx, with fewer instructions and better register allocation.
Now to R8, which has a similar goal with Jack&Jill as a starting point, merging two of these build steps into one. The Proguard and Dex step. So, instead of first Proguard processing the .class file returning again .class files and Dex/D8 processor taking in .class and returning .dex files, R8 merges these two steps, and takes in .class files, returning .dex files. This tool is still getting better, trying to optimize the build process even more. So, it is smart to migrate your project to R8 now, as it is a still growing tool which will be the default build tool soon. (As can be seen by enabled by default in the upgrade of Android Studio(3.4))
Also, the developers in Google issue tracker are very fast in returning to the issues reported about R8, as they are hungry for feedback and want to perfect this tool.
It has been reported that using R8 produces smaller .dex files, and does a more efficient minification of removing unused classes. This is a plus and a minus in some way. It is a plus obviously because smaller size is always better(in programming!),it is a minus because you have to intricately go through your code, and detect your entry points and reimplement the keep rules in your proguard file accordingly, as R8 introduces a more aggressive minification than Proguard.
For more information you can look into this article which includes very detailed explanation on R8 vs. Proguard: https://www.guardsquare.com/en/blog/proguard-and-r8
Also, this official speech from Google I/O 2018 : https://www.youtube.com/watch?v=x9T5EYE-QWQ&t=1194s
Hope this helps,

ProGuard vs R8
History flow
ProGuard -> R8
// R8 is default optimizer of .class files from Android Studio v3.4
ProGuard[About] is open source product
R8 is a Google product
Target:
minify, shrinking
optimize
obfuscate, renaming
R8
R8 has better performance because convert .class directly into .dex without extra step (optimised .class)
R8 has better compatibility with Kotlin

Conversion to Dalvik format failed with error 1 in Android on export (adt 21)

I know a form of this question is out there, but I can't find anything specifically that fits my scenario, so here it is.
My app compiles and runs perfectly when testing in the emulator, but when I try to export a signed apk I get the Conversion to Dalvik format failed with error 1. The Eclipse error log shows this stack trace:
com.android.ide.eclipse.adt.internal.build.DexException: Conversion to Dalvik format failed with error 1
at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeDx(BuildHelper.java:751)
at com.android.ide.eclipse.adt.internal.project.ExportHelper.exportReleaseApk(ExportHelper.java:269)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard.doExport(ExportWizard.java:296)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard.access$0(ExportWizard.java:233)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard$1.run(ExportWizard.java:218)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
I don't have the naming collisions that other people seem to have (at least it doesn't say so in the error), and I'm stumped as to why it runs in the emulator, but I can't export.
I'm not using ProGuard either, by the way.

It looks like ADT 21 adds a folder to your bin called dexedLibs which ought to speed up deployment by putting jars and libraries in precompiled dex code. I had two versions of the support library there, so I deleted all the files in the folder and built again and it worked. If I try to build with any files in there the build fails though, so I have to delete them before each export. I'm using ActionBar Sherlock and that may be conflicting with the dexedLibs thing because it won't show up there unless the folder is initially empty.
Edit: I had been using ActionBarSherlock when this problem first came up, but have recently switched to ActionBarCompat. Since the switch, I no longer have to delete the dexedLibs folder when exporting. Looks like maybe ActionBarSherlock was to blame, but I can't be certain.

Go to project and unselect Build Automatically.
Then Clean the project and Build all.
Worked for me to export signed application package

After a lot of attempts I managed to find out the reason why this issue occurs. In general, this is caused by ProGuard and specifically its optimization. At least in my case I had 4 corrupt projects with this error, but after I disabled the ProGuard optimization, all of them were built correctly.
So, in your ProGuard config comment the -optimizations and -optimizationpasses options and add -dontoptimize
# -optimizations ...
# -optimizationpasses 5
-dontoptimize
Hope this helps.

Optimize the project code

I have been working on one project which is too complex and contain very much space with so many images and Java files as well.
Somewhere I have read about the proguard which optimizes the code.
I have used it, but it's still does not have an effect on my final APK file.
It might be I have made a mistake somewhere. I have the following this like http://developer.android.com/guide/developing/tools/proguard.html.
How can I optimize my code?

You can add it to the default.properties. I've been adding manually without having a problem so far.
If you add the line:
proguard.config=proguard.cfg
As said it will only use ProGuard when exporting signed application (Android Tools => Export Signed Application)
If you start the project with the SDK before Android 2.3 the proguard.cfg file will not be created (next to default.properties as in 2.3>).
To enable automatic creation of it, just simply update to the SDK of Android 2.3 and create a new project with existing sources (which are the sources of the project you currently have).
Automagically the proguard.cfg fill will be created.
Without optimizations the compiler produces very dumb code - each command is compiled in a very straightforward manner, so that it does the intended thing.
The Debug builds have optimizations disabled by default, because without the optimizations the produced executable matches the source code in a straightforward manner.

Please refer this one
From documentation:
ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode.

Targeting Android with Scala 2.8 Trunk builds

The definitive reference for using Scala on android seems to be here: http://www.scala-lang.org/node/160
Unfortunately, all the references on using scala with android are based around Scala 2.7 and refer to a custom build android-library.jar, with a couple of cryptic references suggesting that this custom build isn't needed for later versions of android (I'm using 2.1 / API v7)
So... What are the steps needed to use Scala 2.8 in an android project? Preferably using eclipse and the Android tools that Google supplies for that IDE.

Edit:
My new way of doing this is to use my Eclipse plugin: https://github.com/banshee/AndroidProguardScala (the readme has instructions for installing and a pointer to a normal Eclipse update site).
The old answer still works, but the new way is just better.
[The old way]
My approach:
Use the normal Android/eclipse tools for creating a Java project.
Add a second project containing the Scala code. That way I get to keep the generated code for future reference (I'm new at both Android and Scala). This project can reference android.jar.
The scala project produces a jar file that's used in the java project
Use proguard to strip the library. I believe this avoids the need for the scala-android.jar that was used in 2.7
I haven't used this for anything more ambitious than hello, world though, so take it as more of a set of hints.
In the scala project, I add a builder (Builder > New) that's just a shell script called pguard in the root directory of the project containing:
#!/bin/sh
cd $1
PROGUARD=$HOME/dev/proguard/lib/proguard.jar
LIBS=
OUTPUT=lib/proguard.jar
rm -f $OUTPUT
AJAR=/Users/jamesmoore/dev/android-sdk-mac_86/platforms/android-7/android.jar
# java -jar $PROGUARD -injars 'bin:lib/scala-library.jar(!META-INF/MANIFEST.MF,!library.properties)' -outjar $OUTPUT -libraryjars #proguard.txt
java -Xmx1g -jar $PROGUARD -injars 'bin:lib/scala-library.jar(!META-INF/MANIFEST.MF,!library.properties)' -outjar $OUTPUT -libraryjars $AJAR #proguard.txt
The builder has Location set to:
${build_project}/pguard
And both working directory and arguments set to
${build_project}
Also in the root of the scala project, there's a proguard arguments file #proguard.txt:
-dontwarn
-dontoptimize
-dontobfuscate
-dontskipnonpubliclibraryclasses
-dontskipnonpubliclibraryclassmembers
-keepattributes Exceptions,InnerClasses,Signature,Deprecated,
SourceFile,LineNumberTable,*Annotation*,EnclosingMethod
-keep public class com.banshee.** {
public protected *;
}
You'll want to change the -keep arguments to keep your own code, of course.
In the java project, I add the jar file that's produced by the scala project (I use lib/proguard.jar in the script above).
Don't add the scala project as a required project in the java project's build path, though. That will add the scala class files in addition to the jar file and confuse dex (since it'll get both the .class files and the same things in the jar). As far as I can tell, Eclipse will build everything in the workspace, so when you hit the go button, both projects get built.

After much investigation, it really does look like Proguard is essential to keep the size and speed of deploying the application to reasonable levels.
Sadly, there is no suitable way to embed proguard as a build step. Using scripts might be a possibility, but I also need to support Windows, Linux and OSX environments.
I was also unsure about the twin-project solution, as it prevented Scala code from using the generated resources file R.java, which I wanted to be able to do.
In the end, I was able to make both SBT and Ant build an android 2.1 application using Scala 2.8. Ant was the favourite final solution as it works with the same file organisation as Android's eclipse plugin. I've written up the solution here: http://scala-ide.assembla.com/wiki/show/ae55a-oWSr36hpeJe5avMc/Developing_for_Android
Eclipse then launches Ant as an external tool to package and install the application.

I'm now using a modification of my previous answer to run on Windows: just move everything into #proguard_windows.txt so you don't have to worry about running as a script.
My new #proguard_windows.txt looks like:
-injars bin;lib/scala-library.jar(!META-INF/MANIFEST.MF,!library.properties)
-outjar gen/scandroid.jar
-libraryjars lib/android.jar
-dontwarn
-dontoptimize
-dontobfuscate
-dontskipnonpubliclibraryclasses
-dontskipnonpubliclibraryclassmembers
-keepattributes Exceptions,InnerClasses,Signature,Deprecated,
SourceFile,LineNumberTable,*Annotation*,EnclosingMethod
-keep public class com.banshee.** { public protected *; }
-keep public class org.xml.sax.EntityResolver { public protected *; }
And note that in windows, you need to use a semicolon for -injars. Nasty.
The builder looks like this:
(running cygwin here, so the cat option path takes a slash)
James#Greine:/cygdrive/c/Users/james/workspace/Scala2$ cat .externalToolBuilders/proguard.launch
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.ui.externaltools.ProgramBuilderLaunchConfigurationType">
<booleanAttribute key="org.eclipse.debug.ui.ATTR_LAUNCH_IN_BACKGROUND" value="false"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="C:\Windows\System32\java.exe"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_RUN_BUILD_KINDS" value="full,incremental,auto,"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="-Xmx1g -jar lib/proguard.jar #proguard_windows.txt"/>
<booleanAttribute key="org.eclipse.ui.externaltools.ATTR_TRIGGERS_CONFIGURED" value="true"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY" value="${build_project}"/>
</launchConfiguration>
You'll want to put this in .externalToolBuilders/proguard.launch.
The interesting thing here is that it's just a java command, not any kind of shell script, so it's fairly easy to port between Windows/Mac (and I'm assuming Linux, but haven't done that yet), since you're just changing the location of the actual java binary.
(Submitting this as a new answer because it's a bit different than the one that got marked as the correct(ish) answer)

I have been using Proguard to treeshake the Scala library in Eclipse/ADT builds, but it leaves a lot to be desired. It's slow and it messes up the other .class files, so you have to rebuild the project more often than not.
Inspired by these questions and some of the issues in the Android issue tracker, I have made another tool (based on Jar Jar Links) which I now use to treeshake the scala library. With this build step I'm actually fairly happy with the whole Eclipse+ADT Scala on Android situation. Maybe it'll work for you too, give it a spin, it's available from http://code.google.com/p/treeshaker/

If you are comfortable using the Gradle build tool, then the Android plugin for Gradle makes this whole process extremely simple. See: https://github.com/jvoegele/gradle-android-plugin/wiki