I have seen that there are decompilers that works pretty well to show on fly code and resources of compiled APK.
I'm wondering if there is a way to edit and rebuild APK classes without export all sources and resources recreating a new project manually adding all libraries resources code etc. Since the APK already contains all the needed dependencies and resources configured to work together should be possible.
Often there are apps that have small bugs that would be easy to fix if only was possible edit and rebuild APK on fly
You can use Virtuous Ten Studio that allows you to import an APK edit smali code and resources and rebuild the edited version of the APK.
(You can also configure it to show Java code but since uses a "smali to Java" approach the generated code is imperfect.)
https://ibotpeaches.github.io/Apktool/
You can use Apktools to extract and compress APK-files
It is possible to manage/edit Smali files. They are similar to Java-files.
Related
I wrote an Android app that uses no dependencies or modules, has a single activity, and has a single layout file.
How can I build an apk file of my app on the command line without using Gradle (or other "build systems" or "dependency management" software)?
Use the following steps to build your apk manually, if you don't want use ant/gralde to build. But you must have Android SDK installed at least.
create R.java from aapt
use javac to compile all java source to *.class
use dx to convert all *.class to dex file, e.g output is classes.dex
create initial version of APK from assets, resources and AndroidManfiest.mk, e.g output is MyApplication.apk.unaligned
use aapt to add classes.dex generated in step 3 to MyApplication.apk.unaligned
use jarsigner to sign MyApplication.apk.unaligned with debug or release key
use zipalign to align the final APK, e.g output is MyApplication-debug.apk or MyApplication-release.apk if signing with release key
Done
I have created a sample script to do all the stuffs above, see here
Actually, Some articles have discussed this topic, see the following links.
https://www.apriorit.com/dev-blog/233-how-to-build-apk-file-from-command-line
https://spin.atomicobject.com/2011/08/22/building-android-application-bundles-apks-by-hand/
Try this for building apps with support libraries from command line. https://github.com/HemanthJabalpuri/AndroidExplorer
alijandro gave a perfect answer. I managed to write simple ANT script that builds production APK with AdMob and without gradle usage. A couple useful comments:
If you want to obfuscate classes you have to jar the compiled classes (between javac and dx steps) and run proguard on it
For AdMob you have to extract the following jars from zip archives (like
C:\Users\<User>\AppData\Local\Android\sdk\extras\google\m2repository\com\google\android\gms\play-services-ads\10.2.6\play-services-ads-10.2.6.aar):
play-services-ads-10.2.6.jar
play-services-ads-lite-10.2.6.jar
play-services-base-10.2.6.jar
play-services-basement-10.2.6.jar
play-services-clearcut-10.2.6.jar
play-services-gass-10.2.6.jar
play-services-tasks-10.2.6.jar
These archives should be passed in javac and dx
For AdMob there are several additional simple config steps as well
Gradle does a lot of mess with android projects, so own script looks like a singular solution for projects that are going to go into production
A while back I stumbled across this thread after getting frustrated with both Android Studio and Gradle. Inspired by the answer from alijandro and this template from authmane512, I wrote a series of scripts to compile an Android app (including with dependencies/packages) in Java or Kotlin without any external build system.
Link: https://github.com/jbendtsen/tiny-android-template
There is a little bit of DIY involved here, but given that it's the sort of stuff that something like Gradle would do for you, I would argue that it's useful to know. Besides, it's like wayyyy less slow, and you have a lot more control how your app gets assembled.
I have been trying to import a file to android studio that I decompiled using apktool. But when I try to import the file to Android studio it does not show anything on the "Project" browser. While in the import process, in the first step, I chose "Create project from existing sources". Is there anyway to fix this problem? Also, is there anyway to use in android studio a file from notepad++?
Thanks.
As Daniel Souza replied, apktool is just a tools to help you to extract the class and manifest. If you look into the detail and the flow of the Android build process (https://source.android.com/source/jack.html),
you will know every class will be obfuscated, packed and put it into the .dex file(include your own classes, android support library and other 3-party libraries).
Normally, the .apk file only included the following types of file.
.dex files (it might be not only one if the problem of 65K methods exists)
manifest( Android permission and features meta-data)
asset (Drawable, asset folders, layout and R)
Therefore, when you used apktools and some other tools(j-soup) to do some reverse-engineering. You can only have the source files only. And as Daniel method, you can import the project to the android studio but many errors might be existed into your project.
R.java cannot be generated (since all the custom id value will be converted to be a unqiue integer in the apk., this cannot be reversed as human-readable meaning even you use the apktool)
Obfuscated class and variable name. As I mentioned the process of how the apk built, the class and variable name will be obfuscated after building. Reverse engineering will be difficult to findout the logic inside the application since almost all the name are renamed as (a,b,c,d,e...)
Proguard problem, some application might use advanced technologies to compile the source code using more complex logic flow ( like Dexguard did). After you finish reverse engineering, it will be more difficult to findout the inside logic in the application.
If it is a "Simple" application, you might be able to find out what happen in the obfuscated code.
If it is a "Complex" application including a lot of libraries, it will be disaster if you are trying to dig out the logic inside it.
apktool is a reverse engineering tool that generates the source, but not the gradle build scripts, which is why it does not show up as a project you can open. You have to "import from existing sources" because apktool only generates the source files and Android Studio will attempt to fill in the gradle build files.
Once you import the project, you can add any files you like to your project's directory. This includes ones that you generate from other programs including Notepad++. You can do this in Android Studio with from Project View (Alt+1) with Copy/Paste or Drag/Drop .
As a new android developer, I just know how to import the third dependencies made by other android developers.But now ,I write a simple custom view ,including a class : enter image description here and a declare-styleable:enter image description here,for convenience for the future,I want make it to a dependency or a jar.I don't know how to do it.Thanks for your help!
A .jar is a compiled Java bitcode for the jvm. Google android Java compiles into dex and it packed into a .apk. I would be utterly shocked if you could ever use a jar file. In general android apks files contain everything needed to run the app they don't tend to depend on anything else.
You can setup intents to pass things around throughout the larger environment but in general if you need the code for several projects, just include the source to be recompiled. You might be able to directly include a .dex but it would certainly not be preferred.
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
I am definitely a noob at understanding this as of now, I noticed usually that the apk file is much smaller than my Android Projects. How is that happening? Is it always like this? I got this doubt while I was compressing an entire project to zip file, it was showing that the disk size is 128MB...(noticed it then the first time) whereas the actual apk is only 22.4 MB. why is this difference?
An APK is an Android application package file. Each Android application is compiled and packaged in a single file that includes all of the application’s code (.dex files), resources, assets, and manifest file. The APK file is basically a .zip file
Your project contains all of your source files and files used only by the IDE. The apk only contains compiled files which are smaller.
Also, images/resources etc are compressed in the apk.
Android projects (in general) contain source code, which gets compiled to class files that end up in the APK.
Compiled files are smaller than the source code - for example they strip all the comments out of the file (you do include comments in your source files don't you!)
In addition to the other answers, you're probably using something called ProGuard which further compresses your project by shortening field names, removing dead (unused) code, merging classes, and dozens of other tricks.
Check out the FAQ for more about ProGuard.
It has to do with how Android compiles your project. It basically dumps the bulk, compresses the resources, and compiles everything into a simple binary. It will happen with almost every type of programming, your final build will usually be smaller than your total project (unless you include outside sources in your build). There is a lot of bulk in code that get's stripped during compilation.