With the advent of ASMDEX (ASM for dex files) and dexmaker, shouldn't it be possible to port Groovy to Android? Both frameworks allow the generation of dex bytecode at runtime.
As I understand it, it is impossible to modify dex classes from the APK in memory. But wouldn't it be possible to copy those classes to writable memory, modify those copies at runtime and use them?
What else needs to be ported to handle dex class files? CGLIB?
The original porting project is named discobot then some guys made a new project called discobot2 Afaik the first project had no runtime transformation of classes, but was able to run first Groovy programs on Android, with a very slow startup time. As for the second project the last to me known state is that they solved most issues and are now translating classes at runtime. But I never tried it out.
Update: since Groovy 2.4 a third version to run Groovy on Android is possible
Related
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.
I'm a kotlin and Java developer, and recently I started analyzing the bytecode generated by kotlin. And I found out a lot of wrapper code and other stuff that the compiler generates in order to translate what I have coded in Kotlin to Java.
So, my question is:
Imagine that I have an app that its code is 100% written in kotlin. Dependencies and the main app. All Kotlin.
Does this mean that a different compiler will be used in order to avoid Java compatible bytecode?
Or is there any optimization done by the compiler in this kind of scenarios?
Many Thanks.
I know about Kotlin Native but I think it will only be applied to Android in the future.
The only way you're going to avoid Java bytecode with Kotlin is to use Kotlin Native, and you won't be able to use the Android SDK in that case.
Kotlin JVM, as the name implies, compiles to JVM bytecode; it's one of the main draws of using it. If it compiled to something different, it would be Kotlin Native.
To answer your bullets:
No, the same compiler is used whether or not you have Java source files.
Probably not. Kotlin JVM is made to be almost completely interoperable with Java, and that's the same whether or not your project includes Java code.
Think about if you were creating an Android library in Kotlin. Would you really want it to automatically compile to something other than Java bytecode in that case? It wouldn't be able to be used in Java projects, defeating one of the main reasons Kotlin is so good as a Java alternative.
Also remember, you're using the Android SDK. Even if you have no dependencies in your build.gradle, you still reference the core SDK itself, which is Java. The SDK isn't included in your APK, but it's still used during compilation.
If you want something that avoids Java bytecode, use something like Flutter. It has its own SDK, and can bridge back to Java components. Of course, you can't completely avoid the JVM, because you still need some way for Android to install and open the app.
My server needs to keep building a large amount of Android projects. All of them are almost identical except for minor change on manifest.xml or any resource file (if it's better for the task) for each build. To reduce cost and improve efficiency, I try to implement incremental build. My planned procedures are:
after the first successful build, skip all the previous
procedures (aapt to generate R.java, adle to make java, etc.)
directly call aapt to make resource files, e.g., *.ap_
call apkbuilder to make classes.dex and usigned.apk
make signed.apk
So my question is whether the above solution is possible? And any clue about how to implement it?
This isn't necessarily a solution for your particular requirements but perhaps it will provide you with some useful pointers.
I have an Antlib that I use for building Android projects. You probably won't want to use it yourself as it has some drawbacks, but it should serve as an example of how to perform the various steps to build an Android app using Ant. In particular, it shows how to call the various Android SDK tools from Ant and how to use the Ant uptodate task and Ant's if and unless attributes to avoid processing files that haven't changed.
The source for the Android Ant macros is here (the Antlib documentation might help you to make sense of what it's doing).
So, I've got a handful of "Utility" style classes in some of my projects. I'm curious if I can move them to an Android Library Project that contains all or most of my non-app specific glue code (wrappers and interfaces, mostly).
So, my question is what happens to the files I don't need in that library. I know Android Library Projects basically just copy their code into the other project, so if I say use 25% of the code in my "general purpose" library, will my app actually contain the bytecode for all 100%, or does it properly strip it down to only the stuff I need.
I had some issues with unused classes in Proguard in the past, so I'm just once-bitten, twice shy with the ADT now...
Unfortunately, all your projects will grow when the library is getting bigger - even if most contents of that library are not used. I tested it myself by creating an app A and a library L. If L is a library used in A, the classes.dex file (and therefore the A.apk file) is growing if I add more classes - even if they are not used.
To sum up: Right now I would create a basic library for certain things that are small and that may be used by many projects, and create a new library for every new component that is going to be larger and only is used by some projects. A good candidate for a new library would be a new UI component with multiple images defined in the resources. A good candidate for the base library are commonly-used methods and things like file caches, for example. Compiled code is compressed quite heavily for Dalvik, which you can see here. (The whole presentation is actually fun to watch :-)
Edit: If ProGuard is activated, it will also remove unused code for you. The default proguard.cfg is sufficient. It will not run on the (default) debug built, but when the final .apk is compiled. So it actually is possible!
I have used 3 level deep Android library projects successfully though it is kind of a pain. The primary use-case is when there are a set of resources and classes that you want to share across a few projects. Since I use a version control system, I would rather not use symlinks.
Note that Android Library projects also suffer greatly when dealing with resources. ADT will rebuild R.java once for each library, and each R.java will contain a copy of all resource ids from all libraries. The core problem here is that resources are regenerated for the entire project as a whole, and there is no way to "build a jar" for a dependency as would be expected with normal "libraries". We tried integrating with OpenFeint, and had all kinds of hell dealing with libraries and dependencies. I think we ended up just merging all the OpenFeint source and resource files into our own project and ditching the "Library" project as it was offering little value.
Android Library projects are a clunky way of sharing code between projects and have a number of drawbacks. I've found that everything accomplished with a Library project can also be accomplished with symlinks (symlink source into two projects). I've yet to find a usecase where an Android Library project offered something that wasn't easy to replicate with other, less fragile means.
There are a few questions on SO about using .jar files in an Android project. But I am wondering if the reverse is possible - is it possible to use .apk files in a Java desktop project?
The reason for this is that I created a Java desktop app for object database management, but it needs the model classes from whichever application database it is looking at. With an object database, you need the model classes to define you database schemas. Side question - forgive me for my ignorance but can you run a runnable .apk in a desktop environment? something like this:
http://www.techday.in/how-to-run-android-apk-apps-on-computer/
Anyway, my goal is to kick off my personal object manager program from an individual android application. So in that case the .apk files would have to be able to talk with .jar files. If that fails, I could try just the opposite - kick off the jar file, and use the -vm argument as a location of the .apk files to put in the classpath. Either way. Which is easier? ---> .apk files in a Java program's classpath or .jar files in an Android program's path? Please, just expound away, I want all your thoughts.
APKs contain DEX files, not Java Classes so you would need to translate from one VM file format DEX Davlik to another. The link you provided is for Bluestack's Android VM which would run a APK as it is running the Android OS. If you want to look up how VirtualBox does things that would be the closest match.
The source for Android projects do use standard JAR files for libraries and class files are generated as part of the build process however once you start to package into something you can put on a Android device/emulator/environment you are in a different world.
However as the DEX file format is open-sourced, what you are trying to do isn't impossible, but it might be easier to use the intermediate class files instead.