I want to use the recently introduced D8 compiler from Google to build a dex file.
Unfortunately, I didn't find the jar executable in the build-tools folder (like the dx tool).
Does anyone know where it's located instead?
Thanks in advance.
There is no D8.jar anywhere in build-tools. D8 is distributed as a maven artifact instead. It can be downloaded from https://maven.google.com. The artifact is named com.android.tools:r8 because D8 is a part of the R8 project. The jar contains both R8 and D8 commandline interfaces, so, in theory, it can be downloaded and used from a commandline like:
java -cp r8.jar:<...dependency jars> com.android.tools.r8.D8 <D8 arguments here>
java -cp r8.jar:<...dependency jars> com.android.tools.r8.R8 <R8 arguments here>
However this artifact jar has a lot of dependencies and if you want to use it outside of the gradle-based build then it is easier to build r8/d8.jar executable jars from the sources by yourself. The instruction how to do it is at https://r8.googlesource.com/r8/. The resulting jars are self-contained (all deps bundled in).
The Android Gradle plugin (and, therefore, Android Studio) doesn't depend on the com.android.tools:r8. R8/D8 classes are bundled into com.android.tools.build:builder (one of the libraries that gradle plugin consists of) instead.
D8 dexer has become the default compiler in #AndroidStudio 3.1
Expect faster and smarter app compilation
Faster, smarter app compilation is always a goal for the Android tools teams. That's why we previously announced D8, a next-generation dex compiler. D8 runs faster and produces smaller .dex files with equivalent or better runtime performance when compared to the historic compiler - DX
Please see comparition beetween DX vs D8 :
You can always revert to DX for now via this setting in your project's gradle.properties file:
android.enableD8=false
Related
I have added android.enableD8.desugaring to solve some issues.
However, the build speed slowed down too much. (3min -> 20min)
Question.
What is android.enableD8.desugaring?
What is the operating principle of android.enableD8.desugaring?
Is it a factor to slow down the build?
Self Answer
The meaning of "android.enableD8.desugaring=true" should be interpreted separately.
d8 : d8 is a command line tool that Android Studio and the Android Gradle Plugin use to compile your project's Java bytecode into DEX bytecode that runs on Android devices, and it allows you to use Java 8 language features in your app's code.
"desugaring = true" : You can use Java 8 language features. "Java 8 language features." It is understood as a lambda expression.
I guess d8 might be slower when compiling "Java 8 language features."
Reference
: d8 | Android Developers
As android studio introduced two new tools D8 and R8.
As per google documentation D8 is a dex tool and R8 is a progourd tool but as their explanation both are doing almost same thing like below:
D8 is a dexer that converts java byte code to dex code.
R8 is a java program shrinking and minification tool that converts java byte code to optimized dex code.
It seems both converts java byte code to dex code literally. So, Whats actually they are doing internally in case of converting dex code?
D8 dexer and R8 shrinker
D8->D8 is a dexer that converts java byte code to dex code.
R8->R8 is a java program shrinking and minification tool that converts java byte code to optimized dex code.
Android developers know that dex compilation is a key step in building an APK. This is the process of transforming .class bytecode into .dex bytecode for the Android Runtime (or Dalvik, for older versions of Android). The dex compiler mostly works under the hood in your day-to-day app development, but it directly impacts your app's build time, .dex file size, and runtime performance.
The R8 project uses depot_tools from the chromium project to manage dependencies. Install depot_tools and add it to your path before proceeding.
The R8 project uses Java 8 language features and requires a Java 8 compiler and runtime system.
New version number scheme following the SDK Tools revision number.
Support for true debug build. No need to change the value of debuggable in
the Android Manifest.
Incremental build will automatically insert debuggable==true while using
the "export signed/unsigned application package" will not.
If debuggable=true is set, then release builds will actually do a debug build.
Automatic Proguard support in release builds. Only need to have a proguard.config
property in default.properties that points to a proguard config file.
Completely rewritten Visual Layout Editor. This is very much a work in progress.
full drag and drop from palette to layout for all Layout classes.
Move widgets inside a Layout view, from one Layout view to another and from one layout file to another.
Contextual menu with enum/flag type properties.
New zoom controls.
I think the introduction of this blogpost is a great resource to answer that question: https://jakewharton.com/r8-optimization-staticization
R8 is a version of D8 that also performs optimization. It’s not a separate tool or codebase, just the same tool operating in a more advanced mode. Where D8 first parses Java bytecode into its own intermediate representation (IR) and then writes out the Dalvik bytecode, R8 adds optimization passes over the IR before its written out.
D8 processes each Java class file individually without looking at the entire program. This makes the conversion to DEX fast, since classes can be processed in parallel, and during development it allows fast recompilation when the code of a class is modified.
On the other hand, R8 (like ProGuard) reads in the entire application and makes changes and optimizations (e.g. inlining) that require knowing the entire class hierarchy. For instance, R8 will remove unused classes and methods ("tree shaking") and rename classes, methods and fields (except for the application's entry points).
In Android Studio 3.1, D8 has replaced DX as the tool that converts Java class files to DEX, but R8 has not been enabled yet.
I have to compile a library (library BPG from Bellard.org) to create a .so or a dll that I can use with android/iOS.
I'm working with Visual Studio. With some researches, I found the project "Visual C++ -> Cross Platform -> Shared Library (Android, iOS)". But I am totally lost and can't do anything.
The downloaded library is organised with some folders but Visual don't allow to make tree, all files are sorted by filters (one for header and one for sources). So I can't build, I have more than 300 errors, "can't open source file", "undefined variable"...
Secondly, the README file from project says :
The following packages need to be installed: mingw64-gcc mingw64-libpng mingw64-libjpeg-turbo mingw64-SDL mingw64-SDL_image yasm
I found installed for mingw 32 bits but no 64 bits so I don't know if build can perform. I don't know how to find the libraries.
So my question is, what is the best way to compile a C/C++ library for android/iOS ? And where can I find a tutorial for beginners ?
Thank you
I have worked as cross compiling engineer for several years. The most suitable IDE for you I think, is the CLion with CMake inside.
CMake is a tool which can cross-compile the C/C++ library into ios\android\linux\etc.. using only one config file: "CMakeList.txt".
The main task of CMake is to translate CMakeList.txt to Makefile on every platform and provide you the .a and .so files.
CLion is very powerful IDE in code editing and debugging.
Furthermore, Android needs JNI (or JNA if performance is not concerned) to wrap your c++ interfaces to java classes. Here I would recommend SWIG. SWIG is a tool to wrap C++ interfaces to other languages, that means, not only java on android you can support , other days your lib can also support python\tcl\Go\etc.
Which os are u using to build the lib? macOS or win ?
For iOS : .a file
For Android: .so file
First you should check the README file
Edit the Makefile to change the compile options (the default
compile options should be OK). Type 'make' to compile and 'make
install' to install the compiled binaries.
Use 'make -j N' where N is the number of CPU cores to compile faster.
The following packages must be installed: SDL-devel
SDL_image-devel yasm. It is recommended to use yasm version >= 1.3.0
to have a faster compilation.
Only a 64 bit target is supported because x265 needs it for bit
depths > 8.
check this to install SDL packages
https://wiki.libsdl.org/Installation
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.
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.