Develop Reference

AOSP Build System Library (jar) as pure JAR. Not dexed

I have a Java Library project in my AOSP build which creates a jar file and hosts it in system/framework
Everything works as expected, however I now wish to create a JAR file from the same library to allow and application to link and compile against it. Goal is to be able to create APKs against this lib (compileOnly) so that the APK can run and use the library on the ROM.
The problem is that Jack seems to be generating only dexed jar files which cannot be used in Android Studio as libraries.
Is there a way to disable DEXing in the Android.mk ?
I know there is an option in Android.bp (cannot recall it) which gives the option for the build to generate normal jar (with .class files).
Note: I cannot use BUILD_DROIDDOC with stubs due to enviroment issues (custom ROM) assuming BUILD_DROIDDOC is only executed with lunch sdk-eng
This is for a custom ROM with Android 8.1 base. I think the custom option of not dexing in Android.dp file is not supported in this version anyway.

Verify DexGuard configuration with a signed APK

I integrated with DexGuard and ProGuard, generated a signed APK and now I want to verify that the configuration worked as configured:
Use dex2jar (or similar tools) to decompile the app and verify for obfuscation/encryption
Verify the signed APK's size is smaller
Of course, ensure that the app functions as expected (especially for encrypted resources)
Are there any other steps folks here use?

In the past I've confirmed the String/class encryption is working by decompiling/unpacking the .apk (I use Apktool) and then grepping/searching the output files for known secrets/API keys etc. In fact this could be automated.

Here are the various tools one can use (copied straight from DexGuard docs when you get their JAR/License):
dexdump (Android SDK): disassembles Dalvik bytecode to a readable
text format.
aapt (Android SDK): disassembles binary resource XML
files to a readable text format.
baksmali (open source): disassembles Dalvik bytecode to a readable
source format.
smali (open source): assembles this source format
to Dalvik bytecode again.
apktool (open source): disassembles and
assembles entire applications: bytecode, Android manifest files,
resource files, and assets.
dex2jar (open source): converts
Dalvik byte code to Java bytecode.
jad (free): decompiles Java bytecode to Java source code.
As they always say, read the docs!

How and what converts the Java bytecode to Android dex files?

How and what exactly converts the java byte-code to dex file in Android ?
I know that the only part Android people have done to save them from licensing issues, making the system fast for execution, low memory need and other more features as it is register based VM.
But what name I can tell to the part it doing so?

Go through bellow url and read all details
Detail URL
The general process for a typical build is outlined below:
The Android Asset Packaging Tool (aapt) takes your application resource files, such as the AndroidManifest.xml file and the XML files for your Activities, and compiles them. An R.java is also produced so you can reference your resources from your Java code.
The aidl tool converts any .aidl interfaces that you have into Java interfaces.
All of your Java code, including the R.java and .aidl files, are
compiled by the Java compiler and .class files are output.
The dex tool converts the .class files to Dalvik byte code. Any 3rd party libraries and .class files that you have included in your project are also converted into .dex files so that they can be packaged into the final .apk file.
All non-compiled resources (such as images), compiled resources, and
the .dex files are sent to the apkbuilder tool to be packaged into
an .apk file.
Once the .apk is built, it must be signed with either a debug or release key before it
can be installed to a device.
Finally, if the application is being signed in release mode, you
must align the .apk with the zipalign tool. Aligning the final .apk
decreases memory usage when the application is running on a device.

Role of classes.dex file in an apk file [duplicate]

This question already has answers here:
What are .dex files in Android?
(3 answers)
Closed 7 months ago.
When opening an APK file with WinRar (software to open compressed files). I got a bunch of files packed inside the APK. Among them classes.dex is one. My question is what is the role of this file and if we modify/delete the same file will it affect the APK?

.dex file
Compiled Android application code file.
From Android API GUIDES
Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
And yes if you will delete those files it will effect APK.

classes.dex is essentially all of the application logic. Code of the given application is written in java and then compiled to class files, then these class files are cross compiled (with many optimisations) to dalvik VM format. Note that there also might be some .so files which are also application code but these are generated when NDK is used.
You can not delete this file. You could however change it by first running this utility https://github.com/JesusFreke/smali which will generate smali code from this compiled dex which is somewhat similar to java and could be understood. You could also use tools ApkOneClick or ApkMultiTool to get Java source from the smali files but these would probably not be perfect and will require further fixing. When you change the code you want you should build the classes.dex again and put them into existing zip/apk file you have. Note that then existing certificate files (META-INF) will not be valid anymore and you will need to delete this folder and resign the apk package in order to instal it on the phone or emulator.
For more info you could check this question too What are .dex files in Android?
Also this is a great tutorial on disassembling dex files using existing tools http://blog.vogella.com/2011/02/14/disassemble-android-dex

What is the role of this file?
The role of classes.dex in Android is similar to that of JAR files in plain Java. It's a file containing bytecodes. In Android case, the bytecode is Dalvik bytecode, which is different from Java bytecode.
If we modify/delete the same file will it effect the apk?
If you modify classes.dex, you are modifying the programs behavior, which may or may not work after a repackage. If you delete classes.dex, then your application doesn't have code and you shouldn't expect it to work.

.dex file in the apk is the compress file which is made up of all the java classes in the application code. Its different than jar file. A jar file is a collection of .class files which are isolated. If we unzip .jar, we get all the classes separately. On the other side, .dex file is a single file made up with all .class file from application code.
Code compilation flow :
multiple .java files --> multiple .classes files --> a single .dex file
.dex files are the executables which are executed by the DVM...Dalvik Virtual Machine, which is a Runtime for Android.
.dex will never include resources. Resources are separately maintained in the /res folder in .apk

Android dx usage

I have a jar file created out of an android application, because I marked it as "Is library" in eclipse at creation time. Now the DexClassLoader is not able to load this file because it doesn't have an entry marked classes.dex. This looks like a standard jar. How can I convert such a jar into a dexed jar with dx that DexClassLoader can load? Any help appreciated!

You can use the dx tool from the sdk, from the command line. Something like:
dx --dex --output=dexed.jar hello.jar
Works for me. Integrating such things into your build process is something of a black art, largely involving hacking up the ant buildscripts provided by the SDK. If your library is only occasionally updated it might be viable to do it manually.
In my case, I keep the dexed.jar in my resources/raw folder. At runtime, I copy it from there into the filesystem, then pass the filesystem path to the DexClassLoader. It's... a little bumpy.

Android Libraries are not meant to be started on device. They only can be included as part of Android Projects, which will convert all referenced Android Library .jar files into single shared .dex file and package them to .apk file.
If you want to test your Android Library and it's manifest actually has some entry points for that, then the only way to do so is temporarily change Android Library to Android Project (by checking off that check bar in settings).