Is there some way to get the android SDK build process to do partial updates on the actual device? Whenever I make a change it has to rebuild the apk file and deploy it, which seems wasteful, and is slow (especially with the dex defect).
The copying to the device isn't an issue here, it is fast enough. So the emulator doesn't appear to solve my problem. Is there perhaps a way to test the code without producing the APK file for the emulator?
What you want is Test Driven Development (TDD). This article will start you off right :
http://pivotal.github.com/robolectric/
Is there some way to get the android SDK build process to do partial updates on the actual device?
Not presently. It's something they are considering for a future overhaul of the build system, though I think there are other capabilities that are considered to be higher priority..
Is there perhaps a way to test the code without producing the APK file for the emulator?
Not with standard Java-based Android development. Any sort of compiled environment pretty much needs the code to be compiled in order for it to be run.
Related
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
Is it possible to build an android application with rake? The only other question on this subject I saw was a while back and someone advised using Gradle.
So is there any way to do this on the command line, as I am sure under the hood eclipse just runs a lot of command line guff to get the apk file generated then spits it to the device, I just want to generate the apk file (there is alot of other things to be done but these are prior to the APK building).
Is it possible to build an android application with rake?
Yes, insofar as it is possible to build an Android application using Ant, and rake can in theory do everything Ant can.
If you are expecting to find an existing rake script, though, you will likely be disappointed. The Ant scripts necessary to build an Android app are rather substantial, and porting all of that to rake will take quite some time. And, then, they will perpetually be out of date, as those Ant scripts are often modified with Android tools releases.
Here's a small example project that's worth a look: https://github.com/jberkel/android-helloworld-rake
I've been meaning to try it out myself.
I have a feeling I know the answer to this question, but I figure I would see what SO had to say.
I'm hoping to create a console app that can take an .apk file and extract metadata (such as version name/version number). I'm able to use PackageManager.getPackageArchiveInfo() from my Android app just fine, but I'd need to be able to call it from the command line. However, the classes in the android.jar appear to just be stubs, so it doesn't end up working.
Does anyone know of a way to do that?
For apks for which you do not have the signing certificate, you cannot access the contents of the apk beyond seeing that the contents exist.
As you noted, the android.jar is stubs. This is because the android system relies on native code which is designed to run on ARM processors and (probably) wouldn't run on your system. So, they package stub versions of all the java code and the only way to 'run' the actual library is to be executing in a vm with a full version of the android.jar, which would be an ARM environment ( a real handset or a emulator).
There could be ways to setup a 'console' app to do this, but it would have to be communicating with an Android VM to get a working version of the android.jar. I'm guessing that might be more effort than you'd want to sink into this.
I was able to open the .apk file and view it's contents (including AndroidManifest.xml) with WinZip...
'Hope that helps...
Im pretty sure the answer is no, but im using the new IntelliJ EAP version and have a project i worked on a while back which was just written against JDK 1.6 for an applet based application.
However now i could see how it could be useful in an android app that im interested in creating.
Do i now have to re-write all the code/tests again targeting the android sdk or can i just drop in my existing JAR file and only use android for the UI layer.
Its just android seems to make testing WAY harder than it needs to be, and i have alot of existing tests written and working, if it wasnt so hard to just write a quick unit test (standard Junit #Test style) i wouldnt mind porting, however i just dont get the whole instrumentation thing, as i dont need a UI at the moment...
Anyway so back to the point, can i use my existing JDK built code in an android app?
No!
Android uses the "Dalvik" VM from project harmony which uses a different set of bytecodes which are incompatable with the standard Java JVM bytecodes.
This was done both to optimise the VM for opreration on mobile platforms, and, probably more importantly to try and avoid Copyright and patent disputes with Sun and now Oracle.
More info here
However there is a tool called "dx" which can perform the conversion in the dev environment.
Okay, let me clear up your confusion.
Jars are converted to dex Dalvik bytecode during the compiling process thus you can use 3rd party jar libs.
However, in your case because its applet which has a different application lifecycle yes you might have to re-do it to get it to work in android.
As far as testing instrumentation is used on all java mobile development even JavaMe. It basically means that the Junit tests are run in the emulator or device but in android's case you are using android mock objects to test android specific things.