I have created a demo application with the sbt android-plugin.
The app is very simple.
I have placed a MainActivity.java file under /src/main/java/my/package/ and when a button is pressed it takes you to a second Activity but done in Scala.
Everything is working fine but the build times are killing me.
When I modify something I run in my device using:
> android:package-debug
> android:start-device
My issue is that it takes almost a complete minute to build a two activities project.
Is there another way to compile and run?
This is my output of android:package-debug
> android:package-debug [info] Wrote
/Users/macarse/Documents/demo/target/src_managed/main/scala/my/package/TR.scala
[info] Compiling 1 Scala source to
/Users/macarse/Documents/demo/target/scala-2.9.0-1/classes...
ProGuard, version 4.6 ProGuard is released under the GNU General
Public License. You therefore must ensure that programs that link to
it (scala, ...) carry the GNU General Public License as well.
Alternatively, you can apply for an exception with the author of
ProGuard. Reading program directory
[/Users/macarse/Documents/demo/target/scala-2.9.0-1/classes] Reading
program jar
[/Users/macarse/.sbt/boot/scala-2.9.0-1/lib/scala-library.jar]
(filtered) Reading library jar
[/Users/macarse/Documents/android-sdk-mac_86/platforms/android-4/android.jar]
Note: You're ignoring all warnings! Preparing output jar
[/Users/macarse/Documents/demo/target/classes.min.jar] Copying
resources from program directory
[/Users/macarse/Documents/demo/target/scala-2.9.0-1/classes] Copying
resources from program jar
[/Users/macarse/.sbt/boot/scala-2.9.0-1/lib/scala-library.jar]
(filtered) [info] Dexing
/Users/macarse/Documents/demo/target/classes.dex [info] Packaging
/Users/macarse/Documents/demo/target/demo-0.1.apk [success] Total
time: 56 s, completed Oct 29, 2011 4:22:54 PM
There are a couple of options:
preinstall scala on the phone/emulator
Include predexed scala as a library
There is also a project called treeshaker for Eclipse which is a lot faster than proguard, but it is not integrated w/ the sbt plugin yet.
It takes long time because proguard need to process Scala standard library to minimize the .apk file you get, and Scala standard library is huge.
I will suggest you switch to Scala 2.8 if you didn't use features of Scala 2.9, because 2.8 has a smaller standard library.
In the other hand, don't use android:package-debug when not necessary. compile will compile your source code, it is sufficient if you only want to make sure your program could be compiled.
Only use android:package-debug when you are about to test it on the Android device, this will save your time.
Related
I work on a small Android application project that comprises of ~5k lines of code and a handful of resources. It also has a few library dependencies in the lib/ folder. The problem is that my compile time is very slow. Suppose I perform the following:
ant clean debug
This takes about 28 seconds. Performing a subsequent:
ant debug
Still takes 9 seconds even though I've made not changes to the source between compilation.
It seems like the majority of the slowness happens during the '-dex' target.
How can I improve the speed performance of my Android builds?
Please take a look at this link for my edited 'ant clean debug' output: http://pastebin.com/XY08mr5G
I'm using:
Apache Ant(TM) version 1.8.4, Android Debug Bridge version 1.0.31, Android SDK Tools 22.01,
Android SDK Platform-tools 17, Android SDK Build-tools 17
Thanks.
28 seconds that's not so much for an Ant build script. Compiling to a dex format does take a while. I don't know when you run the ant build script but while you are developing you better use an IDE with compiler such as Eclipse and it will compile in background. Use the Ant build script when you create a build for testing or releasing.
In hindsight, my core issue is that I don't trust Ant to correctly track which sources have been modified since last build. I often find myself running 'ant clean debug' every time I compile simply because I've been burned too many times with botched builds.
If only I had a target to perform a fresh compile of my sources without actually redexing all of my dependency libraries each time!
Here's a proposed solution to my problem. Add this Ant target to my project's build.xml:
<target name="cl">
<delete file="bin/classes.dex" />
<delete file="bin/classes.dex.d" />
<delete dir="bin/classes" />
</target>
Now running 'ant cl debug' takes considerably less time, clocking in at 5 seconds. All of my Java source files are recompiled, but the libraries are not re-dexed each time. (which the 'clean' target requires every time)
I'm content with this solution and will await Android's future Gradle based build system. With any luck, it will provide more versatile targets than this Ant based system.
Every time I add a library to my Android project the compilation process gets slower. Is there a way to cache the (library) dex files so only the application gets recompiled every time? Ideally the build process should check whether the library JAR has changed, if it hasn't it should reuse the prexisting dex file.
I am using nbandroid but I assume the Eclipse build suffers from the same problem.
The Build process (especially at dex step) in Android SDK (regardless of which IDE is in used) is quite inflexible. The only command usage of dx.jar AFAIK is something like below:
[INFO] C:\Program Files\Java\jdk1.6.0_21\jre\bin\java -Xmx1024M, -jar, C:\Program Files\Android\android-sdk\platform-tools\lib\dx.jar, --dex, --output=C:\workspace\myproject\target\classes.dex, C:\workspace\myproject\target\classes, C:\workspace\myproject\libs\common-lib.jar, ... ...
From here you can see that compiled classes with external jar libraries are dexed at project build time.
Is there a way to cache the (library) dex files so only the application gets recompiled every time?
Jar libraries get dexed, not recompiled by Android SDK every time you build your project. I don't think Android SDK provide another command usage of dx.jar which you can use to dex only the complied class without external jar libraries then merged into the pre-existing classes.dex (perhaps generated from last time).
It is not possible at project build time, however, it is probably off topic but you may interested in this blog talked about dynamically loading jar libraries at runtime, worth to check it out.
I'm using Eclipse and have a few projects with 2-3MB of libraries, did not notice any slowdown except when compiling and signing final APK with proguard. Looks like Eclipse does not recompile libraries every time.
In my Android appliction in eclipse I get the following error:
[2011-11-03 19:39:12 - MiniPauker 1.0] Dx
trouble processing "java/crcis/pauker/AddCardActivity$1.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
[2011-11-03 19:39:12 - MiniPauker 1.0] Dx 1 error; aborting
[2011-11-03 19:39:12 - MiniPauker 1.0] Conversion to Dalvik format failed with error 1
this error only appears when run my project. I search long time to the right solution but all possible solutions don't work. I use android 4.0 and Eclipse 3.6,now
by the way, this project worked in Android 2.1 but in Android 4.0 No!!!
Your package name starts with java, which is reserved for core Java packages. You should rename your package if at all possible.
I was getting this because I had manually added android.jar to the build libraries because it was saying it wasn't finding the android libraries. The fix was to...
Remove android.jar from the build libraries
Right click on the project, go to "Android Tools", and select "Fix Project Properties"
Hope this helps.
You have to check that your project (or dependencies libraries) doesn't contain android.jar in build path (Project>Properties>Java Build Path>Order and Export).
If your main project contains android.jar in Android Private Libraries then you have to check build path for all libraries which were added to your project and remove android.jar from build path.
Modify the error caused by the jar package's scope attribute, from compile-> provided, this operation can be modified in File-> Project Structure-> Dependencies or in the project view app folder in the build.gradle file there dependencies , The corresponding jar package compile modified
like this:
enter image description here
Hi i'm new android. i'm working through the samples and have an error when running the HelloGridView app. Eclipse is giving the following error. Has anyone had the following error? Thanks.
[2010-12-06 14:38:16 - HelloGridView]
trouble processing "javax/net/ServerSocketFactory.class":
[2010-12-06 14:38:16 - HelloGridView]
Attempt to include a core class (java.* or javax.*) in something other
than a core library. It is likely that you have attempted to include
in an application the core library (or a part thereof) from a desktop
virtual machine. This will most assuredly not work. At a minimum, it
jeopardizes the compatibility of your app with future versions of the
platform. It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine distribution,
as opposed to compiling an application -- then use the
"--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact building an
application, then be forewarned that your application will still fail
to build or run, at some point. Please be prepared for angry customers
who find, for example, that your application ceases to function once
they upgrade their operating system. You will be to blame for this
problem.
If you are legitimately using some code that happens to be in a core
package, then the easiest safe alternative you have is to repackage
that code. That is, move the classes in question into your own package
namespace. This means that they will never be in conflict with core
system classes. If you find that you cannot do this, then that is an
indication that the path you are on will ultimately lead to pain,
suffering, grief, and lamentation.
[2010-12-06 14:38:16 - HelloGridView] 1 error; aborting
[2010-12-06 14:38:16 - HelloGridView] Conversion to Dalvik format failed with error 1
Android framework do not allow addition of JAVA core libraries in your project as external jars.
Heres how you can add libraries to your application:
Open project properties by right clicking project and selecting properties
Select JAVA build path on the left pane
Select Libraries tab from right side
Click add Library button
Select JRE system library and add required package.
I was facing the same problem, and noticed that I had added the system JRE library as one of the build path dependencies. However, the problem did not go after removing it.
I then removed the android.jar file as build path dependency, and it started working. Might be it was conflicting with an include from one of the other project dependencies, since the project was dependent on other android projects.
For people not working in english, it could also be your project name containing special characters (éàè...). I had the same problem, renamed my projects (with F2) and it worked.
I got rid of this error by checking the project dependencies and removing the Android dependencies.
In Eclipse:
Right click on the project -> properties->Java Build Path -> Libraries and there I removed the android dependencies
Check the box of System Library when you add the external jar files through Build Path--Add Libraries--User Library--User Libraries--new
I had same problem and after a couple of day of search and fight i found this thread. It does not solved my problems but helps me to find the solution.
I do this steps mentioned above:
Open project properties by right clicking project and selecting
properties.
I saw I had Android 2.1 library and Android 1.6 library.
Removed all libraries.
Changed the Android version of my project from 1.6 to 2.2.1
Clean the project
This solved my problem. The application now is working.
BTW, the application I was trying is an Android auto-answer (http://code.google.com/p/auto-answer/source/browse#svn%2Ftrunk%2Fres%2Fdrawable-hdpi)
Removing SPACES from an imported project name fixed the problem for me.
I have a project that I would like to add external libraries to (and have them packaged with the application) but I am not sure it is happening. I read on this link:
https://developer.android.com/guide/appendix/faq/commontasks.html
how to, but they do not show up in any of the /data/data/project directories. Does anyone know how I can confirm that the libraries were in fact added to the project for use at runtime? Thanks.
If you include jars as External Jars under your project's Java Build Path, then the classes will be converted to Dalvik format and be made available in your project's classes.dex file, packaged into the .apk.
To confirm they are available, attempt to use something from the jar (Eclipse should suggest the relevant import when you first supply a class name) build and run the app and see if it works? If it works in development (e.g. from 'run' in Eclipse) then it will also work when the app is built in release and distributed as an APK.
You can also place jar under one of your source folders (perhaps creating special "libs" one) and adding it to build path.
Be warned - external libraries (which are compiled against some version or other of the libraries in a Java JDK) may sometimes have problems when running under android. This is because the Dalvik runtime has its own Java framework libraries, which provide most (but not all) of the Java APIs in the standard JDK Java framework libraries.
You should really recompile any external library against the android libraries so that you can see any missing APIs at compile time - and fix the issues there and then. Otherwise you run the risk of runtime errors under Dalvik when you call the external library from your Android app. See http://geekswithblogs.net/cyberycon/archive/2011/05/17/using-external-libraries-with-android.aspx
for more details.