Hi,
I'm trying to change the Phone.apk application from google GIT java source code. but when i import the application to Eclipse, I'm getting a lot of errors even after loading the correct android.jar file (tried to clean the project) .
1) what is the right way to change application from google source code?
2) How can I know which libraries am i missing?
Thanks a lot,
Idan
I'm not sure if phone will work, i know that other aosp apps work with this method though.
http://iserveandroid.blogspot.com/2010/12/how-to-compile-launcher-calendar-or-any.html
When trying to compile Android from source for a particular device, what files are usually pulled from the device to inject into the build? I'm very familiar with compiling applications from source, but compiling a complete system is new territory for me.
myersn024 said:
When trying to compile Android from source for a particular device, what files are usually pulled from the device to inject into the build? I'm very familiar with compiling applications from source, but compiling a complete system is new territory for me.
Click to expand...
Click to collapse
Check the cyanogen source tree at github. If you i.e. check under:
/android/system/device/htc/bravo
you will find a file called: extract-files.sh
In that file is all the proprietary files needed for the build.
Hi,
I have rooted my nook touch and I am trying to install an ssh server on it. I found a document on github (I can't post links but if you google "github dropbear sft android" you should see it) which describes how to cross compile dropbear ssh on debian for Android.
But when I start the cross compiled dropbear on the Nook it tells me :
FATAL: kernel too old
[1] Segmentation fault ./dropbearmulti
What does this mean or has anyone managed to get an ssh server running without some sort of UI thingy like sshdroid?
Thanks,
Ralph.
Ok, I found out the libc I am using for cross compiling (from emdebian) is compiled for Linux kernel 2.6.32 while the nook is using Linux 2.6.18. That is why my cross compiled dropbear does not work.
Any ideas on an easy way of getting a dropbear executable for the Nook without recompiling everything?
NookManager has dropbear in its uRamdisk. You could extract it from there.
straygecko said:
NookManager has dropbear in its uRamdisk. You could extract it from there.
Click to expand...
Click to collapse
Ah, great idea. I tried to run it but it does not work (it says 'not found')
I even installed all the shared libraries dropbear requires from the uRamdisk to the nook but that did not help either...
I found an easier way:
On the nookdevs.com wiki there is a page called DropNook and it contains a compiled version of dropbear for the Classic. After some tinkering it also works for the Nook Touch.
DexPatcher
A toolchain for modifying Android APK files at source-level using Java, graphical resource editors, and the full power of Android Studio in all major platforms.
Fully integrated with Android Studio and the Gradle build system.
Includes support for coding assistance and on-demand class decompilation.
Patch Java code in Java using declarative syntax provided by the DexPatcher tool.
Manifest merging enables piece-wise changes to the original app manifest.
Modify existing resources or create new ones using Android Studio's standard resource editors.
Use Android Studio's code template wizards for creating activities, etc.
Pull in Android libraries (a.k.a. '.aar' Android archives) and have their manifests, code and resources automatically merged into the patched app.
And enjoy debugging support.
All in your favorite platform: Linux, Windows or macOS.
DexPatcher tool (Dalvik bytecode patcher)
Release notes: https://github.com/DexPatcher/dexpatcher-tool/releases
Sources: https://github.com/DexPatcher/dexpatcher-tool
DexPatcher Gradle plugins (Android build system and Android Studio integration)
Release notes: https://github.com/DexPatcher/dexpatcher-gradle/releases
Artifacts: https://plugins.gradle.org/search?term=dexpatcher
Sources: https://github.com/DexPatcher/dexpatcher-gradle
Samples: https://github.com/DexPatcher/dexpatcher-gradle-samples
Deprecated tools
Release notes for DexPatcher Gradle v1 plugins: https://github.com/DexPatcher/dexpatcher-gradle/releases?after=v2.0.0-alpha1
Support tools for DexPatcher Gradle v1 plugins: https://github.com/DexPatcher/dexpatcher-gradle-tools
Workflow automation scripts (Linux-only): https://github.com/DexPatcher/dexpatcher-tool-scripts
License
GPL v3 (or later)
THANK YOU ! - The DexPatcher tool uses JesusFreke's dexlib2 (part of smali) to read and write dex files. Many thanks to him for repeatedly helping me in #smali on freenode. When creating apk libraries, the DexPatcher Gradle plugin uses iBotPeaches' Apktool to decode compiled resources and pxb1988's dex2jar to translate Dalvik bytecode. DexPatcher could not exist without the invaluable work of these guys.
Documentation
PATCHING JAVA CODE IN JAVA
The DexPatcher tool uses declarative semantics based on Java annotations to patch the bytecode of the source application. There is no formal definition but hopefully you will find everything you need in this sample:
The sample code being patched.
The patch itself with explanatory comments.
The output of DexPatcher and test runs of the original and patched code.
START HERE !
With the new DexPatcher Gradle v2 plugins
Get the sample code working, here is how:
Clone the samples.
Start with the 'patched-app' sample: open the project with Android Studio, disable instant run, and run or debug your patched app!
Please review the release notes of recent versions of the Gradle plugins for more information on tool compatibility and environment setup.
In the 'patched-app' sample, browse the two 'build.gradle' files (main and app) to get an idea of what is happening. The plugins used are briefly described here. Next get inside the 'app' subproject and take a look at its manifest and resource files. These files are merged with the ones coming from the source app, which is located in the 'apk' directory. Finally look into the 'MainActivity.java' file to see how the compiled code of the app is patched using Java. This is handled by the DexPatcher tool, a key piece of the DexPatcher toolchain. See the section 'Patching Java code in Java' above for more details on this tool, and please review its recent release notes.
The DexPatcher Gradle plugins use Apktool to decode applications and optionally create APK libraries. They optionally use dex2jar to display decompiled application code and to import application code symbols into patch projects. They use the DexPatcher tool to patch the Dalvik bytecode of applications. And finally they use the Andoird build system to merge manifests, code, resources, assets, and extra files, and to repackage applications.
With the old DexPatcher Gradle v1 plugins
To get the old sample code working:
Install the support tools by cloning the repo anywhere you like.
Clone the 'v1' branch of the samples.
Set the 'dexpatcher.dir=<support-tool-dir>' property in identical files named 'local.properties' in the root directory of each sample so that it points to your local clone of the support tools. Create the files if necessary, or have Android Studio create them for you by opening the samples.
Start with the 'patched-app' sample: open the project with Android Studio, disable instant run, and run or debug your patched app!
Please review the old release notes of the Gradle v1 plugins for more information on tool compatibility and environment setup.
OLD NEWS: DexPatcher Featured On XDA Portal !
GermainZ wrote an excellent introductory article for XDA that walks you though the complete process of modding an app using the old deprecated Linux-only workflow automation scripts. This only covers the DexPatcher tool itself, ie: only patching of code, not resources. The workflow is deprecated, but the Java patch code and accompanying explanations are very valuable and continue to be current. I am grateful to him for having taken the time to do this. Please make sure you give it a read:
DexPatcher: Patch Android APKs Using Java.
Also available: [WARNING: Deprecated, Linux-only]
A how-to that will help you get started with the workflow automation scripts.
LICENSING UPDATE:
tl;dr: DexPatcher patches are no longer forcefully covered by the GPL.
Recent versions of DexPatcher no longer require that users bundle the DexPatcher annotations with every patch (although continuing to do so has no ill effects). The DexPatcher licensing terms no longer impose licensing restrictions on patches, as long as users refrain from bundling the DexPatcher annotations with them. In particular, DexPatcher patches are no longer considered to be derivative works of DexPatcher and thus are no longer automatically covered by the GPL. Legals aside, the DexPatcher project urges you not to use copyright laws to introduce artificial scarcity in the world. Please give back to the community: share your work.
XDA:DevDB Information
DexPatcher, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Source Code: https://github.com/DexPatcher
Version Information
Status: Stable
Created 2015-03-21
Last Updated 2019-11-09
DEPRECATED: Workflow Automation Scripts HOW-TO
DEPRECATED: Workflow Automation Scripts HOW-TO
These scripts bundle several tools (including DexPatcher) and automate boilerplate actions that are part of a typical workflow. They are available only for Linux. Take the leap today, get yourself free, get Linux Mint Cinnamon 64-bit.
Installation
Code:
# cd to a suitable install dir such as '~/opt' or '~/android/tools'.
git clone [url]https://github.com/Lanchon/DexPatcher-scripts.git[/url] dexpatcher
cd dexpatcher
chmod +x dxp-*
# edit 'dxp.config':
# -set the path to android sdk (defaults to '~/android/sdk').
# -disable bundled tools to use the ones in $PATH if desired.
# add 'dxp-*' scripts to $PATH:
# -symlink the 'dxp-*' scripts in a suitable dir in the $PATH such as '~/bin'.
# -or add the 'dexpatcher' dir to $PATH.
Sample Workflow
Code:
# cd to a suitable workspace dir.
dxp-setup-for-apk path/to/TheApk.apk
cd TheApk
dxp-create-keystore
# in 'src-cfr' you will find decompilation of the app to Java (with errors).
# you can use these files to plan your changes.
# in 'src-cfr-nocode' you will find decompilation of empty method stubs.
# you can use selected files as a basis for your patch.
# create your patch as Java files in 'src'.
# the symbols of the original app will be accessible to your patch code.
dxp-make
adb install -r patched.apk
The Big TO-DO List
The Big TO-DO List
...of things I would like done in this project, but that I will probably not have the time to implement myself.
DexPatcher-tool
Moved here: https://github.com/Lanchon/DexPatcher-tool/issues
DexPatcher-gadle
Moved here: https://github.com/Lanchon/DexPatcher-gradle/issues
DexPatcher and javac
Modify javac so that all source symbols -even those defined inside edited classes- are available during compilation. This could produce a patched javac executable, or the standard javac could be patched in-memory using java agents, or its in-memory data structures hacked from an annotation processor (a la Project Lombok).
Decide if dex2jar and jar2dex/dx are transparent and mature enough to move DexPatcher 2.0 to the java bytecode realm, and stop operating at the dalvik bytecode level. [UPDATE: It is not.] Or a VM abstraction could be implemented as a backend to DexPatcher so that the same font end could be used for both dex and class files.
If the project is moved to the java bytecode realm, decide if the new DexPatcher should be a standalone tool like it is today, or a java agent/annotation processor that modifies javac to do the patching during compile time. This would make the tool very easy to integrate into most build systems.
just added the documentation section
I checked docs and wow, massive Maybe you can make some easier examples how to use it (some small patches).
there is a lot of docs missing, especially regarding the workflow, how to extract and use symbols from the source apk, etc. for now im working on 0.2
UPDATE: version 0.2.0 released!
UPDATE: version 0.3.0 released!
Looks good
I will look at it more deeply when I found time.
I'm surprised there isn't so much feedback… May be could you add some examples / details in the OP?
PerfectSlayer said:
Looks good
I will look at it more deeply when I found time.
I'm surprised there isn't so much feedback… May be could you add some examples / details in the OP?
Click to expand...
Click to collapse
i still need to evolve the tool a little with respect to handling of fields, and then it's mostly done. but i need to document a full workflow, including obtaining symbols against which to build the patch (you want your patch code to be able to use all of the source app's code).
Very interested in seeing how this tool progresses. :good:
I still have no idea how to use this tool
UPDATE: version 0.4.0 released!
laura almeida said:
I still have no idea how to use this tool
Click to expand...
Click to collapse
take a look a the test run and samples. docs are very incomplete, but i guess you should understand them if you have experience patching apks in smali.
Lanchon said:
UPDATE: version 0.4.0 released!
Click to expand...
Click to collapse
Sorry for the small change; this beaks patches and so I wanted to push it out ASAP.
Click to expand...
Click to collapse
Don't worry for breaking patches.. Focus on making the better API / usage you can while you are in development. We will thanks you later
UPDATE: version 1.0.0-beta1 released!
An explanation of the workflow and some helper scripts should follow soon.
UPDATE: added Workflow Automation Scripts and HOW-TO
Lanchon said:
UPDATE: added Workflow Automation Scripts and HOW-TO
Click to expand...
Click to collapse
Tips: you could use the 2nd argument of git clone instead of running mv command
Lanchon said:
UPDATE: added Workflow Automation Scripts and HOW-TO
Click to expand...
Click to collapse
The speed of development is atonishing...
Keep up the good work!
UPDATE: DexPatcher featured on XDA portal !
includes full sample, please see the OP for details.
edited (solution): I forgot I had another thread on this same basic topic. You have to merge AOSP + Device Sources + Hardware Drives and set it up to build the sources.
https://forum.xda-developers.com/android/software/toolbox-c-struct-define-toolname-tool-s-t3568409
If I try to compile my own customize 'toolbox' binary for example, I can't find the headers anywhere in the toolchains or included headers. I can search them down from Google sources but I gave up after tools.h. I have a feeling this is NOT the way I am supposed to be doing it.
Is there a shared library on my device that I pull off to get these headers? (lib?????.so).. Where do I get headers for Android/log.h and cutils properties.h and selinux.h ??? Or are we not supposed to compile these binaries on a Ubuntu machine? (do I compile them on the device itself?)
ediit: (here's compiling it another way, obviously I can make a hack easily but working with Android is so much harder.)
arm-linux-gnueabi-gcc -static -march=armv8-a toolbox.c -o toolbox
toolbox.c:6:25: fatal error: android/log.h: No such file or directory
compilation terminated.
edit, solved i think
I think it's stand alone toolchain not defined. If that's not the answer, it's a fun answer so I'm playing with that. If I don't have the answer I will pass the question up, download sources and start trying to compile Android proper. (which is my new goal now, I want open source phone and I want to compile my own OS 100%, besides the closed sources, it's so exciting!!) ~so much for sleep