Well, as an introduction to topic, you could read the following entry:
http://forum.xda-developers.com/showthread.php?t=1296186
So far, when using "-static" directive for compiler, the applications could be compiled without doing of these steps, so why do I try this? Well, a statically linked executable is embedding all the required libraries to itself, so it's generally too huge. Also, if you compile all the applications statically, you probably link the same library (like C library, for instance) twice or more for every application you compile. This is definitely unnecessary.
It's why, for a few days now, I'm trying to compile the whole GlibC suite for Android (ARM devices, to be precise). The motive behind it is simple: since all Linux applications rely on full-fledged C library (rather than trimmed version like Bionic), if I compile it for this device, I can run every application; given that its compiled for the device.
Since it's Linux kernel underneath, we don't have to worry about changing whole system from Android to native Linux (hopefully )
So far what I did was following (I'm going to write the steps more systematically once I've time, so don't worry if those steps are too vague for you ):
1- Make a toolchain for ARMv7 architecture (which Desire CPU rely on). You can use crosstool-ng etc. or (if you're masochistic enough ) try to make your own.
2- Compile GlibC with this new toolchain of yours, store the compiled libraries in a folder where you can easily access (I keep mine at Desktop/glibc-arm for instance)
3- Edit Ramdisk of the Kernel. To do this, first you must extract the boot.img; then extract the ramdisk, edit init.rc to accordingly, so the libraries can be searched in a folder other than /system/lib (say, /data/lib). You can tweak PATH env-variable while you're at it as well . This is necessary because /system partition isn't big enough to carry all GlibC lib in it, so we can copy the library to some other folder (like /data/lib) and then make the system search for libraries there as well. The point is, since I'm using Data2ext; my data is large enough for this. I'd recommend the same to you if you're willing to go on this road.
After the editing of init.rc, reconstruct ramdisk; make a boot.img with it and flash it to the device.
4- Copy the libraries to the folder of you picked.
5- Compile some test apps (like Hello world etc ) with your cross compiler and place them to your device as well.
6- Test if they're running.
What I've found so far, the cross compiled executable (like simple Hello world), when dynamically linked, gives "no such file or directory" error when tried to be run at the device (WTF, right ). However, when when I do run it with the cross-compiled ld-linux.so (the linker of C library) it runs perfectly. So what I should do to overcome this is, somehow inform the system that this ld-linux.so binary should be used.
I'll keep you updated as I try new things
Till next time, happy Android'ing
ADDENDUM 1:
EUREKA! Found the solution! It's as simple as symbolically linking the library folder of your GlibC as /lib to root file system. You can edit ramdisk accordingly to do this process automatically.
Another thing I'm going to try is finding a way to change the path of the dynamic-linker option of my cross compiler accordingly. Apparently, the cause of the problem was the compiler, telling the application to look for the dynamical linker at /lib/ld-linux.so.3; while it was at /data/lib (in my case). I can put ld-linux.so.3 to /system/lib and change compiler accordingly; but I don't know which way would be the best for flexibility: symbolic linking of /lib to library dir; or putting dynamic linker to /system/lib (the dynamic linker can look for libraries at the "custom" libdir already, since $LD_LIBRARY_PATH is already showing it).
Will try some tweaks now. If I can make it all work, I'll see if I can make a flashable zip or something (also will write whole process step by step
-------------------------------------
ADDENDUM 2!!
Well, I kept you waiting a lot, but wow, was this process head spinning. This was the first time I actually wrote a recovery script; first time I had to use AWK, SED or regex; and first time I wrote such a long scripts Well, whatever, we're done for now..
There are two zip files attached to the end of this thread: One is an installer and other is uninstaller. Just flash the recovery zip and reboot the phone. Your native C or C++ applications should run flawlessly (only added support for this two language for now) if all other dependencies are also met
Happy Android'ing guys; and well, I'd appreciate if you'd buy me a beer for that (or just click thanks, or just say thanks.. If you did all of those, you're my hero )
Here is the hero of the post :
Glibc for Android v0.9.5
Uninstaller for GlibC
NOTE: Uninstallers erase only files, not directories. Ergo, you might need to erase them yourself (had to do it for not to erase your own binaries and such).
HERE'S HOW YOU'RE GOING TO MAKE TOOLCHAIN YOURSELF (making a toolchain):
http://forum.xda-developers.com/showpost.php?p=18356849&postcount=5
CHANGELOG
Code:
Version 0.9.5:
* Ramdisk-boot image editing tools are included in the package, for some systems might not have it.
-------------------
Version 0.9.4:
* A bugfix for a script syntax error which causes GlibC to pass the installation checks but make binaries give "not found" error.
* A bugfix for Bash, not working well, so causing system to freeze at boot.
-------------------
Version 0.9.3:
* A major bugfix for the bug that was causing bootloops.
* A bugfix for scripting errors inside the recovery zip, causing half-installation
-------------------
Version 0.9.2:
* A small patch added that will allow GlibC to be installed with Apt-get without problems.
* Made compatible with the Sibere's new Data2SD solutions
-------------------
Version 0.9:
* Moved configuration files from /data/etc to /system/etc
-------------------
Version 0.8.1:
* Removed a symlink which may cause some Android apps use wrong version of library.
-------------------
Version 0.8:
* Complete recompilation.
-------------------
Version 0.7:
* Fixed a bug which causes Sibere's Data2sd unrecognized if Droidzone's flasher is not used
* Fixed a bug with the installation of locales.
* Included a basic busybox binary and flash_image to make library installation successfull in all recovery systems - was causing problems in some systems
-------------------
Version 0.6:
* Standart C++, MPRF, GMG and MPC libraries are added to the package
* Library profiling support is added
* All libraries are recompiled with PIC (position independent code) for better portability.
-------------------
Version 0.5:
* LibGD included in package - it's a picture manipulation library
* GlibC Version 2.14 - I'm sure even your Ubuntu-Debian machines have older versions now :)
* Locale support added. Your C/C++ programs can use it freely.
-------------------
Version 0.4:
* /tmp support added, necessary configurations are done
* Package manager support is implemented, allows users to install to both MTD and SD-ext in coexistent way (no more had to choose!).
* Developed a flexible structure, thus allowing libraries to be installed with a helper application (it's going to be shipped later)
-------------------
Version 0.3:
* Stripped libraries and binaries for make them smaller
-------------------
Version 0.2:
* Installs to the MTD Partition instead of sd-ext. Needed for inital-time programs to run correctly.
-------------------
Version 0.1:
* Initial version
-----------------------------------------------------
Thank you very much for donations of:
Mr. Brochard and Mr. Huemer
I really appreciate it.
Eureka! Found an overcome!
Well, forgot to say this: if you want the compiled applications to be installed to some place if possible, create a "defaultinstall" file under sd-card root and write "EXT" (for sd-card) or "MTD" (for internal MTD storage) to the file (note that all uppercase).
Install manager first checks this file and if not found, uses default setting found in package (which I wrote /sd-ext generally for not-so-essential stuff ). You can use this functionality to override this setting.
Note that, some libraries and stuff cannot be installed to a different location - package manager handles this and acts accordingly; so don't worry about it
PS: The stuff I keep calling Package Manager is actually just bunch of scripts, so it's not like I wrote a whole suit
Sounds Interesting
Some compiled applications!
Well, if we're not going to use it, then why did we compiled it, right?
NOTE: The following packages don't have any specific order of installation: you can install them at any order you wish. The only exception is APT - it should be installed after DPKG, or otherwise your system will think you didn't install it
For those who hates command-line interfaces: DesirAPT (the APT front-end for Android) is here DesirAPT v1.0.0
For those who would like to run Enlightenment WM in Desire - this is the mediator application for Android: LinuxInAndroid APK
Note that it requires APT and it's dependencies, along with super user privilages.
---------------------
PACKAGE: NCurses Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: It's a shell extension library which is used to format shell (or terminal output) like colorful texts, and such. Default shell might not use it (but it's definitely something necessary for new applications like nano, like "new" bash etc.)
HOW BIG IS IT: Approx. 3.4 Mb.
WHERE TO DOWNLOAD: NCurses Lib. 5.5.9
UNINSTALL?: Available at NCurses Uninstaller
CHANGELOG:
Code:
v 0.4.1 :
* Made Compatible with Sibere's new Data2SD solutions.
------------------------
v 0.4 :
* Complete recompilation with UTF-8 and wide-char support
------------------------
v 0.3 :
* Fixed the Sibere data2sd un-recognization bug
* Added flasher files into the binary for support of all recovery systems.
------------------------
v 0.2 :
* Adding package manager support
------------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Bash
DEPENDENCIES: GlibC Library, NCurses Library, Readline Library
WHAT DOES IT DO: It's the main command interpreter for a linux system (also Android). Normally, Android is also shipped with it, but it's a very lightweight and trimmed version (also annoying - it doesn't support tab completion!). This is 4.2 version (latest now).
HOW BIG IS IT: Approx. 3.8 Mb.
WHERE TO DOWNLOAD: Bash 4.2
UNINSTALL?: Available at Bash Uninstaller/reverter
EXAMPLE OF A COOLNESS: You can change your shell label (the one shows before $ or # sign) by assigning PS1 environment variable. For instance, this : PS1="[\w]\$ " (with quotes) will show your current working directory at every prompt
(More at: http://www.lifeaftercoffee.com/2006/10/31/customize-your-bash-prompt/ )
NOTES: The bash will run the commands that you write initially on /etc/profile automatically. You can define your PS1 values, environment variables (be careful to add "export" before them) there for whole system )
Code:
v 0.7.2 :
* Made Compatible with Sibere's new Data2SD solutions.
------------------------
v 0.7.1 :
* Included automatic bash_completion file (stolen from Ubuntu :D) into package - now even apt-get packages are auto completed!
-------------------------
v 0.7 :
* Recompiled with LibReadline for history and auto-completion abilities.
------------------------
v 0.6 :
* Added Locale support
------------------------
v 0.5 :
* Complete recompilation with new schematics
* HOME directory set to /data/home by default
------------------------
v 0.4 :
* Fixed the Sibere data2sd unregnization bug
* Added flasher files into the binary for support of all recovery systems.
------------------------
v 0.3 :
* Added package management support
---------------------
v 0.2.2:
* Added ENV variable, thus support for /etc/profile shell starter file. You can define new environment variables there which is valid for all system (you don't need to change ramdisk each time now!)
--------------------
v 0.2 :
* "Jobs" support fixed
---------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Busybox Binary
NOTE: Busybox with GlibC dependency is no longer supported, because package update mechanisms require some command interpreter independent of the updated package. In order to support GlibC Update, Busybox binary will no longer be updated with GlibC support. I recommend you to revert back to static, or Bionic-linked Busybox with the link below.
UNINSTALL: Available at Busybox old version reverter
---------------------
PACKAGE: Zlib Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: It's compression library that is used with various applications like Git, Apt, DPKG etc.. It's recommended to keep it there
HOW BIG IS IT: Approx. 350 Kb.
WHERE TO DOWNLOAD: ZLib 1.2.5
UNINSTALL?: Available at ZLib Uninstaller
CHANGELOG:
Code:
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Fixed a bug causing system library to clash with the installed one
* Fixed a bug causing Segmentation Faults in some cases
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: ReadLine Library
DEPENDENCIES: GlibC Library, NCurses Lib.
WHAT DOES IT DO: Readline is a command line and history manager library that's used in some command line tools like socat. I personally don't know what else uses it
HOW BIG IS IT: Approx. 1.4 Mb.
WHERE TO DOWNLOAD: Readline 6.2 - v0.1
UNINSTALL?: Available at Readline Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: OpenSSL Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: OpenSSL Library is Secure Socket Library that is used in various secure applications and web browsers.
HOW BIG IS IT: Approx. 5.9 Mb.
WHERE TO DOWNLOAD: OpenSSL 1.0.0e
UNINSTALL?: Available at OpenSSL Uninstaller
CHANGELOG:
Code:
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Fixed a bug causing system library to clash with the installed one
* Fixed a bug causing OpenSSL to do Segmentation Fault and crash
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: APT - Advanced Package Tool
DEPENDENCIES: GlibC Library, Curl Library, Zlib library
WHAT DOES IT DO: APT is a front-end for DPKG which installs, removes, updates etc. packages easily. APT also supports dependency tracking, and automatically removal of unneeded packages.
HOW BIG IS IT: Approx. 1.8 Mb.
WHERE TO DOWNLOAD: apt 0.8.10.3
UNINSTALL?: Available at apt Uninstaller
CHANGELOG:
Code:
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Apt now assumes required packages are pre-installed; thus doesn't re-download them unnecessarily ..
* Changed repo host - configuration in sources.list is changed.
--------------------
v 0.1.1 :
* Configuration files are added. Apt-is ready to use out-of-the-box now..
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Cryptography Package
DEPENDENCIES: GlibC Library , Zlib Library, PTH Library, Readline library
WHAT DOES IT DO: This package contains some cyrptographic libraries necessary for various applications. If you're to use APT, it's recommended to install this package, for since it also carries GPG package inside. Package includes
GnuPG (2.0.18), LibGPG-error (1.9), LibGcrypt 1.5.0, LibKSBA (1.2.0), LibAssuan (2.0.2)
HOW BIG IS IT: Approx. 8.2 Mb.
WHERE TO DOWNLOAD: crpyto package
UNINSTALL?: Available at crpyto Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: cUrl
DEPENDENCIES: GlibC Library, OpenSSL Library, Zlib library
WHAT DOES IT DO: cUrl is a secure web client that supports HTTPS protocol. Package includes also libcurl which provides secure web connection API
HOW BIG IS IT: Approx. 916 Kb.
WHERE TO DOWNLOAD: cUrl 7.23.1
UNINSTALL?: Available at cUrl Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Re-Initial Release
---------------------
PACKAGE: Dpkg - Debian Package Manager
DEPENDENCIES: GlibC Library, Zlib library, Tar binary, Linux Utils
WHAT DOES IT DO: Dpkg is the main package for Debian package managing structure. DPKG is the responsible application for installing, removing and updating packages. Using with Apt (or other front-end) DPKG allows users to install new packages easily.
HOW BIG IS IT: Approx. 7.5 Mb.
WHERE TO DOWNLOAD: dpkg 1.16.1.2
UNINSTALL?: Available at dpkg Uninstaller
CHANGELOG:
Code:
v 0.4 :
* Fixed a bug which was causing GlibC not to upgrade from APT.
--------------------
v 0.3 :
* Links renewed
--------------------
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Fixed a bug that causes some big archives not to install
* DPKG now informs system that GlibC, OpenSSL, Ncurses libraries are already installed (necessary for DPKG anyway)
---------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: PTH - Portable Threads Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: PTH is a POSIX compliant thread library that is used in some linux applications.
HOW BIG IS IT: Approx. 251 Kb.
WHERE TO DOWNLOAD: pth 2.70
UNINSTALL?: Available at pth Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Tar Archiver
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: TAR is and old and multi-purpose compression format used in various places. This tar suite is designed to be 100% compatible with the PC one (busybox one is not so good at this).
HOW BIG IS IT: Approx. 3.7 Mb (1 MB in System partition).
WHERE TO DOWNLOAD: Tar 1.23
UNINSTALL?: Available at Tar Reverter
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Linux Utilities
DEPENDENCIES: GlibC Library, Ncurses Library
WHAT DOES IT DO: This package includes low-level linux tools that is necessary for a system to run in well manner. Busybox do provide many of those, but they are quite crippled versions - so high level applications may crash using busybox ones (like DPKG).
HOW BIG IS IT: Approx. 5.6 Mb
WHERE TO DOWNLOAD: Linux Utils 2.20
UNINSTALL?: Available at Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
Where the hell is the other packages?
Since we know have an APT repository for our distributions, in order to follow all the packages from one source, they won't be published in zip form anymore. In order to obtain them, or update them if you have older versions, you can use apt :
Code:
apt-get install <packagename>
The packages distributed can be list with the following command:
Code:
apt-cache dumpavail | grep Package:
OR, you can use DesirAPT to do these works.
See you around!
NOTE
Before you start anything, don't forget to install build-essentials package. Under ubuntu, the command necessary for it is: sudo apt-get install build-essential - I don't know about other distros..
-------------------------
Well, as promised, now we should write the steps; right?... Now, before we begin, I should really warn that the process is really head spinning if you're to do all by yourself; so take heed to the warnings I give you (I learned the hard way)
Well, first thing is first, we need a Cross Compiler Toolchain, properly built that allows us to build applications, libraries etc. There is one toolchain that's already given to you with Android Native Development Kit (called NDK) but that one is quite restricted because it's built with support for Bionic (trimmed C library that is presented in Android), not Glibc or uGlibC. If you want to develop more native-like applications (especially linux programs) you need GlibC or uGlibC. You can try to build these libraries with that toolchain too, but don't do that, because it's going to fail as well. The reason is that some sort of Chicken-Egg problem is eminent in GlibC-GCC compilation
Let's put the steps to be followed first to build a nice toolchain. I assume you're using Linux - because the tools are developed for this platform only. If you're going to use them in Windows, you need Cygwin or such tools but I can't supply help about that, for since I didn't use them before at all. Google is your friend about this
(Note, the packages I wrote at this list are available at GNU's website www.gnu.org freely, open source)
1- We're going to build "binutils" first. This package includes some important stuff like assembler, linker, archiver (for libraries) etc..
2- We're going to build GCC's prerequisites. These are GMP, MPRF and MPC packages.
3- We're going to build a "bootstap" gcc (God, I hate that name. I like to call it "naked gcc" more ). This GCC just converts source codes to pure assemblies: thus cannot generate linkages or such. We're going to use it to build "actual" tools we're going to use.
4- We're going to extract Kernel source/headers - use Desire Kernel's here. There is some copying, and such to be done tho.
5- We're going to make GlibC headers installed, which will allow us to build more "complex" gcc, which can link applications with those libraries when the library binaries are given (so such thing is there yet, but we fool it )
6- We're going to build a very limited GlibC which will give us support for building more "complex" gcc.
7- We're going to build GCC again. This is called "Pass 1 GCC" or "GCC Stage 1". This GCC can link applications to libraries, with the information in Kernel headers and library headers (it's why we give it the headers, so it can create applications suitable with the Kernel architecture).
8- We're to build actual GlibC now. This glibC will be used for our compiled applications, statically or dynamically. You can, at the end of this step, copy the files to your devices and they would work, but picking files here is harder, so I'd recommend you to leave this alone for now
9- We're going to build "Pass 2 GCC" or "GCC Step 2" This is a full fledged GCC that can do anything we want
Complex isn't it? This is precisely why I recommend you to use Crostool-NG. The other tools (like Buildtools or Crosstool) (sadly) don't create GlibC based toolchains, or use old versions of them, so using this one is recommended. This package automatically will download, setup and link your all toolchain without you worrying about something (believe me, this is what you need. I gave 8 days without this to create a working GCC and Crosstool-NG made another one to me in 50 minutes. )
Well, however, Crosstool-NG won't create "nice" applications (they'll run allright, but they won't be optimized) without some settings done, so, let's go there. First, we need to install Crosstool-NG itself. To do that; go to http://crosstool-ng.org/ website, download and extract it to some place. Even though the steps are written in Crosstool website, you don't need all commands there (like setting PATH is unnecessary). The commands you should use is, after CD'ing to the Crosstool dir;
./configure --prefix="</some/place>"
make
make install
cd "</some/place/bin>"
./ct-ng menuconfig
I used prefix as /home/ahmet/crosstool for instance. Note that this is not going to be where your toolchain is, this is where your "toolchain creator" is .
---- NECESSARY KERNEL HEADER CHANGES ----
OK now, before we start compiling; we need to make some folder moving, copying etc. in Kernel directory. This is needed, because tree structure changed a tad in 2.6 kernels and unless you compiled this kernel before, some directories won't be in their correct place for our cross compiler. Switch to the directory which you extracted the kernel image. Now, from now on, I'm going to assume you're an Qualcomm/MSM board (like Desire, Nexus One etc.) user; but if you're not, change my descriptions accordingly:
1- Go to <kernel dir>/arch/arm/include folder. Copy "asm" directory and paste it into <kernel dir>/include directory.
2- Go to <kernel dir>/arch/arm/mach-msm/include folder. Copy "mach" directory and paste it to <kernel dir>/include/asm directory. It's going to complain that there is another mach folder there and will ask if you want to merge/overwrite. Say yes to all questions.
Now our kernel headers folder is showing a Desire device. Note that if you're not a Desire user, you should use your cpu folder instead of ARM and your board manufacturer in mach-xxxxx instead of mach-msm.
Note this kernel directory, we're going to use it to configure crosstool..
--- CONFIGURING CROSSTOOL ---
After issuing the commands, the crosstool-ng will give you a configuration menu. Most of the setting here are unchanged, but the ones you should change are given below.
1- Paths and misc options
a) Try features marked as EXPERIMENTAL (this is needed to build a toolchain with the latest GlibC support) -> Enabled
b) Local Tarballs directory -> The folder address that you want downloaded stuff to be kept. You might use them again (like for compiling GlibC again for device, you will use them
c) Save New Tarballs -> Enabled ( so that new downloaded files aren't erased )
d) Working Directory and Prefix directory -> Normally you don't have to change them, but you can if you want to install your toolchain to some other location. CT_TARGET signifies your target name (like arm-msm-linux-gnueabi - arm is cpu model, msm is vendor (can be anything), linux is showing the binaries are for linux system (you can use android, but then you'll get not GlibC but Bionic) and gnueabi shows you're going to use open-source EABI structure for your executables. The other option is ELF but EABI is more flexible (because also supports ELF).
e) Strip all toolchain executables -> do it if you don't want to debug GCC itself. this makes toolchain smaller of size, and a tad faster.
The other options can stay the way they are, or you can change them accordingly here. You can get help with ? key, and if you don't understand anything, just leave them default - there are very complex things there that you don't need to know if you're not planning to be a expert on subject
2- Target options
a) Target Architecture -> arm should be selected, cos Desire uses ARM. If you plan to make toolchain for, say, powerpc, pick that.
b) Endianness -> Should be little. ARM processors in Desire uses little endian system.
c) Architecture level -> "armv7-a" this is should be written. Desire uses ARMv7 based instructions and if you leave here empty, the applications will be built with armv5 support - they're still going to run but not use advanced v7 features.
d) Use Specific FPU -> "neon" . Desire uses NEON structure for floating point arithmetic, and if you leave here empty, the applications will not use Desire's FPU abilities (everything will be software based, which is slower)
e) Default instruction set mode -> arm . You can use thumb here for allegedly faster code but not every build system supports it. Leave it ARM.
f) Use EABI -> enabled. EABI is necessary for most flexible desing of binaries.
The other settings be as they were.
3- Toolchain options
a) Tuple's vendor string -> You can leave here empty if you don't want to; it's not necessary to use a string here. I used "msm" but you can write anything. This string here is used in toolchain name as arm-xxxxx-linux-gnueabi, so make it short, I recommend
b) Tuple's alias -> make it something short like "arm-linux" This alias string is used to make calls to your toolchain easier. Instead of writing arm-msm-linux-gnueabi-gcc everytime, you can use arm-linux-gcc to compile your applications. Can write anything here (like toolchain if you want to use toolchain-gcc to compile your applications)
The other settings can stay as they are, for since default values are the best in our case. You can tweak them only if you know Desire cpu like the back of your hand
4- Operating system
a) Target OS -> Use "linux" if you want the applications to run in Android and Linux; use "bare metal" if you're to compile low level applications which won't use linux headers. Default is linux.
b) Get Kernel headers from -> say "pre installed" because otherwise it's going to download standard Linux headers from internet. We needed some changes, so this option is compulsory to be "pre installed"
c) Path to custom headers directory/tarball -> Path to your kernel source folder - which you made changes above. WARNING: I say specifically extracted, because standart tarball won't work for us. We're going to make some changes in kernel directories, which is non-standart (Instructions were above).
d) This is a tarball -> No . We're going to use extracted folder.
e) Build shared libraries -> say "yes"; because we want dynamic linkage, not static one
f) Check kernel headers -> say "no" otherwise some unnecessary check causes compilation to stop.
5- Binary utilities
a) Binutils version - pick the latest one, 2.20.1a. If you use older versions with newer GCC/GlibC, it's not going to succeed.
Leave others as they are, they are not big deal..
6- C Compiler
a) GCC Version -> pick 4.6.1 for since it's the latest and most bug free. Just stay away from 4.5
b) Pick the languages you want support for. I've read online that Java is a tad troublesome in Android platform, for since Java in Android uses Dalvik, not Sun systems. You can try it at your second toolchain if you want Definitely pick C++ tho
c) Link libstdc++ statically -> say yes; it really saves you from big configure scripts later - apparently needed to avoid PPL problems as well
d) Compile lidmudflap/libgomp/libssp -> say no. These libraries are not the most suitable libraries for ARM platform (at least at cross-compiler level. You can compile them later, if you want, with your cross-toolchain.)
You can leave others as default
7- C library
a) C library -> gLibC (recommended). You can use other libraries which are eGlibC (embedded Glibc, like Bionic) and uGlibC (micro-glibc) too, but GlibC is the most spanning solution above those. The libraries are bigger, but they support more.
b) glibC version -> Use 2.13 (experimental) it compiles just fine, and you get a new version of GlibC. Not the newest, but that's ok
c) Threading implementation -> nptl (recommended) . You can use linuxthreads too, but nptl is more advanced ( like giving support to Thread-Local-Storage and such)
d) Force Unwind Support -> Enabled . If you don't use this option, for since we're making this toolchain from scratch, it's going to give you error during compiling that it couldn't find necessary headers (we're building them now, dumbass!)
Leave others default if you don't know what they're about
8- Companion Libraries
Well, go and pick the latest versions, even though when it says "Experimental", otherwise your GCC compilation will give you error about these libraries being old.
After setting these settings, press ESC key twice till it goes way back and ask if you want to save configuration; say yes.
--- STARTING COMPILATION ---
Now to start compilation write
./ct-ng build.
This is going to take approx. 45 minutes, so go watch some episodes of Big Bang Theory or something. Normally, there should be no errors but if there is; most probably either you made a wrong configuration, or didn't set your kernel folders well. Try again with other settings, google your problem etc..
After this process, you're going to have a cross-compiler at your use at /home/<username>/x-tool/arm-<vendor>-linux-gnueabi/bin folder. Note that Crosstool-NG automatically makes this folder read only to make you prevent screwing your toolchain You must edit your path variable to show "/home/<username>/x-tool/arm-<vendor>-linux-gnueabi/bin" folder as well for less headaches during compiling later
Whilst compiling other application, most used configure options you're going to use is "--host=arm-<vendor>-linux-gnueabi" and "--prefix=/some/folder/you/want/this/application/copied". After compilation, you can send binaries to your phone from prefix folder.
More options about GCC and Configure is available at GCC and Autoconf man pages; check them as well
Happy cross-compiling people
Woah, amazing work, congrats!
Sent from my HTC Desire using XDA App
Interesting..It answers some of my unanswered queries regarding cross compiling.. Thanks...Please keep documenting your progress.
THIS POST IS ONLY FOR THE BRAVE MAN
These are packages which are compiled; but not installed and/or tested by myself. Please test them and inform me if they work (PM me if they work or not; it's better that way ).
--------------
NO PACKAGES HERE! Frankly, I did test virtually all of them. They might not work as expected maybe, but at least they don't impede functions of device
Developer Log
Now while preparing a suitable (and as flexible as it can) recovery zip; I realized that instead of editing ramdisk, I can also use init.d script to link /lib to /data/lib. This also allows some flexibility to user (i.e. move library folder around -if needed- and edit init.d script accordingly and still have a running system).
What baffles me most is PATH env-variable. Apparently, if I set it at init.d level, it's not exported quite well - apparently, there is a user mode switch between init.d script run and ramdisk loading process (because PATH variables at Ramdisk are exported to all applications, whilst init.d ones are not) and the only way to set PATH variable for all processes is editing Ramdisk (AFAIK)...
And another point: what if kernel doesn't support init.d? (Go to hell if you're reading this post with a kernel which doesn't ) Ramdisk solution is quite general (i.e. works for everyone) but it's a little harder to edit with scripts and not as flexible as init.d method. I think it's safe to assume that there is init.d support at this level
Maybe I can create two versions (init.d one and ramdisk one) of recovery zip's.. Keep in touch guys..
theGanymedes said:
Now while preparing a suitable (and as flexible as it can) recovery zip; I realized that instead of editing ramdisk, I can also use init.d script to link /lib to /data/lib. This also allows some flexibility to user (i.e. move library folder around -if needed- and edit init.d script accordingly and still have a running system).
What baffles me most is PATH env-variable. Apparently, if I set it at init.d level, it's not exported quite well - apparently, there is a user mode switch between init.d script run and ramdisk loading process (because PATH variables at Ramdisk are exported to all applications, whilst init.d ones are not) and the only way to set PATH variable for all processes is editing Ramdisk (AFAIK)...
And another point: what if kernel doesn't support init.d? (Go to hell if you're reading this post with a kernel which doesn't ) Ramdisk solution is quite general (i.e. works for everyone) but it's a little harder to edit with scripts and not as flexible as init.d method. I think it's safe to assume that there is init.d support at this level
Maybe I can create two versions (init.d one and ramdisk one) of recovery zip's.. Keep in touch guys..
Click to expand...
Click to collapse
Well, what's the difference between init.d and ramdisk, when init.d support means running busybox runparts from ramdisk?
Droidzone said:
Well, what's the difference between init.d and ramdisk, when init.d support means running busybox runparts from ramdisk?
Click to expand...
Click to collapse
Well the difference is caused by Unix variable propagation.
Normally, when ramdisk is loaded and init.d scripts are starting to run (with run-parts binary) the exported variables are valid only for the scripts that run-parts do run. Since Linux only allows child processes to inherit variables from host, when runparts finishes job; defined variables within the scripts vanish.
When you add variables to Ramdisk (init.rc) directly, since variables become declared from init directly (and since init runs all the processes on boot) the variables automatically become available for all processes.
That's the difference I meant
Got it..So the variables from init.rc persist till shutdown..
Droidzone said:
Got it..So the variables from init.rc persist till shutdown..
Click to expand...
Click to collapse
Precisely. It's why the variables (even those which defined by export keyword) are vanished when the system booted up (unless defined in ramdisk)
Well, I've gotta learn RegEx one day anyways
Recovery zip is done! Now, I should test it on my device first
I'm also going to make a uninstaller script I think. It's really messy to clean this up otherwise
Android binaries and dependencies
I've examined the dependencies of all the binaries in /system/bin and /system/xbin in Android system. Too sad that the list contains some non-standart libraries (that's not that bad, sure you can find their sources).
Also, another problem is that you need to compile the binaries themselves from the source code as well (with the GlibC libraries) - which is near to the compiling the whole ROM itself - I'm not even sure if we can find source code (will check the Android source code itself when I've time)
The dependencies in my system, for instance, are as follows:
So that's a no-go for people with closed source system...
@theGanymedes, do you know if the system can mount ext4 at init.rc level (on early init) without using busybox?
Well, it can, but the kernel needs ext4 modules (or direct support). I checked the native mount source, it actually does nothing much more than simply calling kernel's ioctl or mount system call..
I think a simple tweak at ramdisk is all you need for that (and a supporting kernel, of course )
Weird thing about previous issue is, I have the source codes of most utilities, I can compile them too, but I don't have proper makefiles and I'm too lazy to write them myself - that's a lot of trial and error.
Well, apparently, we're not going to be able to switch from Bionic to Glibc completely. I think I can make them coexist tho.
theGanymedes said:
Well, it can, but the kernel needs ext4 modules (or direct support). I checked the native mount source, it actually does nothing much more than simply calling kernel's ioctl or mount system call..
I think a simple tweak at ramdisk is all you need for that (and a supporting kernel, of course )
Click to expand...
Click to collapse
Yup, my compiled kernel has direct support.
This is how mtd is mounted..
mount yaffs2 [email protected] /data nosuid nodev
And this is how I mount ext4 from init.d:
/system/xbin/busybox mount -t ext4 -o barrier=0,noatime,nodiratime,nosuid,nodev,nobh,nouser_xattr,noauto_da_alloc,commit=50 /dev/block/mmcblk0p2 /data
I need to change it to init.rc (init) language...
theGanymedes said:
Weird thing about previous issue is, I have the source codes of most utilities, I can compile them too, but I don't have proper makefiles and I'm too lazy to write them myself - that's a lot of trial and error.
Well, apparently, we're not going to be able to switch from Bionic to Glibc completely. I think I can make them coexist tho.
Click to expand...
Click to collapse
Earlier this month, I was trying to compile dosfstools for Android. But got stuck at static cross compile with ndk gcc
Droidzone said:
Earlier this month, I was trying to compile dosfstools for Android. But got stuck at static cross compile with ndk gcc
Click to expand...
Click to collapse
So, I'm not barking for the hollow tree here.. That's a relief. Seeing that this post is not that active, I was starting to think I'm working in vain..
Well, now, apparently init version of mount is quite restricted about options. The ones it supports are given in mount.c as:
Code:
"async", "atime", "bind", "dev", "diratime", "dirsync", "exec", "move", "recurse", "remount", "ro", "rw", "suid", "sync", "verbose"
I'm checking the mount.c source as we speak. I'm going to inform you if I can find something.
EDIT: BTW, also "no"+options are recognized (like noatime)
ADDENDUM:
The internal mount is exactly the same as the mount we use at busybox. So, most probably, it's the same was in init script.
Try this line
Code:
mount ext4 /dev/block/mmcblk0p2 /data noatime,nodiratime,nosuid,nodev,nobh
Notice that I erased some flags. You might also try to add them, but check if this line works first.
Zip Builder is a stand-alone Windows exe (ZipBuild.exe) that can be used to build and sign Android zip-based installers from Windows folders. All required components to build and sign a zip installer are included - no additional files or software are required. The only requirement is that you have a current version of Java installed on your system. Zip Builder can be used on both shell-script and edify-script based installers and performs the proper build and signing methods, accordingly.
Although it's highly recommended to install the software using the Windows Installer (see below), the stand-alone exe is all that's required to use the program. The program command line options are as follows:
ZipBuild.exe <option1> <option2...> <*Folder Name>
Valid options are as follows:
'm' or '-manual': Manually select folder to be processed
's' or '-signed': Append '-signed' to the output file name
'5' or '-md5': Generate corresponding MD5 checksum file
'c' or '-confirm': Confirm options before building
'g' or '-gitinclude': include .git folders and related files
* Ignored when using manual selection mode
OPTIONS EXPLAINED
'm' or '-manual': In Manual mode you will be presented with a dialog box where you can manually select the folder containing the files to be processed. *When using Manual mode, the folder name will be ignored if it was provided in the command line
's' or '-signed': This option will append '-signed' to the output file name. For example: Folder name 'UPDATE-adb.Installer.v1.0.36' would produce a signed zip file named 'UPDATE-adb.Installer.v1.0.36-signed.zip'.
'5' or '-md5': This option will create a separate, corresponding MD5 checksum file that can be used to verify file integrity in TWRP or with other Windows checksum utilities.
'c' or '-confirm': When this option is used, you will be presented with a dialog box where you can confirm (or change) the 2 options above. If either (or both) options above have been specified on the command line, the checkboxes will be pre-selected accordingly. Once you're satisfied with your selections, click the 'Build Zip File' button to begin the zip building and signing process.
'g' or '-gitinclude': This option will include any .git folders and related files (.git, .gitignore, and .gitattributes) that are excluded from the zip file by default. [Should rarely be needed, if ever]​
ZIP BUILDER SETTINGS MANAGER
Zip Builder Settings Manager (ZipBuildSettings.exe) is an optional companion app that can be used to manage the settings and options (shown below) for Zip Builder:
You can choose to create Windows Context (Right-Click) menus that will allow you to build a signed zip installer simply by right-clicking on a folder name. Folder names that end in '20YYMMDD' or '20YYxxxx' as well as folder names that begin with 'UPDATE' are supported in Windows 7 and above. You can also enable the option to build from any folder by holding the SHIFT key while selecting the folder.
You can choose when to display the confirmation dialog
You can choose when to append '-signed' to output file names
You can choose when to create md5 checksum files
You can choose to include all .git folders and related files (see above)
DATE CODE FEATURE
If you're building from a Windows folder name that ends in '20YYMMDD' or '20YYxxxx', Zip Builder will give you the option to change or update the date code portion of the file name before building the zip (it will also suggest the current date's date code - YYYYMMDD). And, if you're building a zip installer that includes a g.prop file (found in many GApps packages), the installer will read the date code from the 'ro.addon.*_version=' property and automatically use it in place of the date code from the Windows folder name.​
WINDOWS INSTALLER
As mentioned above, you'll have the best user experience if you install Zip Builder using the Windows installer. It runs in standard user mode (no Admin access required or requested) and installs the Zip Builder and Zip Builder Settings exe's in: 'C:Users<user>AppDataRoamingZip Builder'. The installer will create a program group and shortcuts in the Windows start menu (and optionally on the desktop) that can be used to launch Zip Builder in 'manual selection mode', where the user can manually select the folder they wish to build. The installer will automatically run Zip Builder Settings Manager at the conclusion of the install where you can configure the settings and options to your personal preference.
Uninstalling Zip Builder from the Windows Uninstall menu will remove all traces of the software from your system. And, since Zip Builder, Zip Builder Settings Manager, or its installer will NEVER prompt for UAC access, you can be confident that it's not touching the Windows operating system. Of course, all source code is available if you want to check for yourself - you can even build it for yourself, if you want!​
TECHNICAL NOTES
Version 4.3+ of Zip Builder includes the new ZipSigner 2.1 Java executable that was rewritten from the ground up by @topjohnwu for use in his Magisk root management software. This change will allow you to build the largest zip installer on even the smallest 32-bit machine. I was able to build a 1.0+GB shell-script based installed on a 32-bit Windows XP machine with only 1GB of RAM.
If you have had java heap size issues building zip installers in the past, version 4.3+ of Zip Builder should completely eliminate these problems.​
XDA:DevDB Information
Zip Builder, Tool/Utility for all devices (see above for details)
Contributors
TKruzze
Version Information
Status: Stable
Current Stable Version: 4.5.2
Stable Release Date: 2020-09-06
Created 2018-01-23
Last Updated 2020-09-06
Anti-Virus False-Positives
ANTI-VIRUS FALSE-POSITIVES
There have been reports of false-positive flaggings of Zip Builder and/or the Windows installer. While I can, personally, assure you that there's no malware included in Zip Builder or its installer, I also understand that there may be some concern with using software that's been flagged on your machine.
To allay your concerns as best as possible, I have included 100% of the original source code for you to inspect and/or build the software yourself. Again, there is no possibility of malware as I do all of my compiling on a clean machine that is not connected to the internet. I have also submitted all 4 Windows executables to the major AV inspection service on the net. Below are the results of these inspections:
VirusTotal.com
ZipBuild.exe (32 bit) 7/68
ZipBuild.exe (64 bit) 2/68
ZipBuildSettings.exe 4/67
Zip Builder_4.5.2_Setup.exe 1/69
Sources & Acknowledgements / Recent Changes
SOURCES AND ACKNOWLEDGEMENTS
Zip Builder has existed for me since way back in 2013 when I started developing GApps packages. I've added features here and there and finally decided to share it. After privately sharing with @osm0sis, I received a lot of very constructive feedback and based on this, I polished the interface and added some new features. A big thank you to @osm0sis for this feedback. Without his input, it would look a lot clunkier than it does today.
All source code is provided, however, it's only appropriate for me to publicly acknowledge that this work includes code and binaries from several third party sources. Below is a complete list of these sources. You will also find this list as well as the actual code and binaries in the Source Code Zip file available for download.
Zip Builder
------------
Zip Builder is Copyright (c) 2013-2020 by @TKruzze
Original source code and compiled executables can be found on
XDA Developers. Zip Builder also includes code and compiled
executables from the sources listed below:
ZipSigner
---------------
ZipSigner is Copyright (c) 2016-2020, John Wu @topjohnwu)
Original source code and license can be found at:
https://github.com/topjohnwu/Magisk
The version of ZipSigner used in Zip Builder was built by @topjohnwu using the source code above and optimized using ProGuard optimizations
Info-ZIP
----------
Info-ZIP is Copyright (c) 1990-2007 Info-ZIP
Original License can be found at:
http://www.info-zip.org/license.html
Downloads can be found at:
ftp://ftp.info-zip.org/pub/infozip/win32/
Original source code can be found at:
https://sourceforge.net/projects/infozip/
Hashutils
----------
The MD5 Checksum code and executable are from code.kliu.org
Original source code and compiled executables can be found at:
http://code.kliu.org/misc/hashutils/
SUMMARY OF RECENT CHANGES
SEPTEMBER 6, 2020 - v4.5.2
Fixed RegEx bug (oversight) that only supported automatic folder renaming through the year 2019. Now we're good through the year 2029.
As always, the best and easiest way to update is to simply install the new version using the Windows installer without uninstalling the previous version. All of your settings and options will be retained
NOVEMBER 1, 2018 - v4.5.1
Updated the cleanup function to also include removal of the SignAPK*.tmp files that are created in the %TEMP% folder during the signing process.
- Thanks to @osm0sis for reporting
MARCH 26, 2018 - v4.4.0
Updated the ZipSigner java executable to v2.1-min. This version is significantly smaller than v2.1 (458K vs 4.0MB) and was built by @topjohnwu, himself, using using ProGuard optimizations
Recompiled Zip Builder Settings Manager (ZipBuildSettings.exe) without UPX compression to try and further minimize AV false-positives
Windows installer now built using lzma2/max compression and no longer uses solid compression. This was done to optimize installation speed and further minimize AV false-positives
MARCH 25, 2018 - v4.3.0
Updated signing code with the new ZipSigner 2.1 Java executable that was rewritten from the ground up by @topjohnwu for use in his Magisk root management software. This change will allow you to build the largest zip installer on even the smallest 32-bit machine. I was able to build a 1.0+GB shell-script based installer on a 32-bit Windows XP machine with only 1GB of RAM.
- Thanks, of course, to @topjohnwu, but also to @osm0sis for the heads up on its existence
- Thanks to @jenslody for building it for inclusion here.
Since memory and java heap size issues are now resolved with the above change, I have removed all memory and java heap size checks from Zip Builder. The above change also allowed me to remove the separate test key files (testkey.pk8 and testkey.x509.pem), signapk.jar, zipadjust, and minsignapk.jar executables as their functions are all now contained in the new ZipSigner 2.1 Java executable mentioned above.
Installer will now clean up its 'temp folder' files before displaying the 'COMPLETED' message. On slower systems this should reduce the delay when selecting the 'Close' button after Zip Builder completes the signing process.
- Thanks to @osm0sis for reporting and helping track down the issue
Zip Builder is now built without UPX compression on the Windows exe's. This was done to try and reduce false-positives that may be reported by your AV software. If you're still having AV hits, please read the ANTI-VIRUS FALSE-POSITIVES section on the OP.
Fixed bug in installer that would corrupt the context (right-click) menu settings on an update (not initial) installation.
- Thanks to @osm0sis for reporting and helping track down the issue
Excellent! Glad to see a public release! I was using Zip Builder all day to prepare my latest round of updates for my Odds and Ends thread, and it couldn't be easier!
It's been great working with you again @TKruzze, I knew you couldn't stay away from contributing awesome things to the community for too long.
Looks very cool! You're inspiring me to clean up and release a tool that I built which has no current equivalent.
Seeing as this uses Java, what would it take to make it work under linux? As a staunch Linux/osx user who only runs a windows VM for flashing his Samsung with odin, I would love to integrate this into my workflow, but without linux or Mac support for me personally that will be difficult ?
This is an incredible contribution. Thank you for making this public and for your hard work!
partcyborg said:
Seeing as this uses Java, what would it take to make it work under linux?
Click to expand...
Click to collapse
The only thing I'm actually using Java for is the signing portion of the process. There's no real way I can think of to easily port the rest of it to Linux. Thanks for the feedback!
wow thanks @TKruzze :good:
this will be really helpful for my future firmware updates ✌
Ok im very very new to all this but does this make zips that are flashable in twrp? Im wanting to learn how to do that if you guys could point me in the right direction id be thankful.
papasmurf879 said:
Ok im very very new to all this but does this make zips that are flashable in twrp? Im wanting to learn how to do that if you guys could point me in the right direction id be thankful.
Click to expand...
Click to collapse
yes
you need update-script and update-binary along other files
TKruzze said:
The only thing I'm actually using Java for is the signing portion of the process. There's no real way I can think of to easily port the rest of it to Linux. Thanks for the feedback!
Click to expand...
Click to collapse
My mistake. Thanks for the explanation! I'm sure then that this will run in wine however, I may give it a shot at some point. If I do I will let you know.
kamilmirza said:
yes
you need update-script and update-binary along other files
Click to expand...
Click to collapse
Thank you for replying im doing searches right now trying to figure it out.
papasmurf879 said:
Thank you for replying im doing searches right now trying to figure it out.
Click to expand...
Click to collapse
Advanced, but check out my thread here and the linked resources: [DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
The EDIFY references/resources are the place to start. :good:
Can i create flashable zips of my apks. I Flash custom roms very often and some apps are needed as my daily driver so can i make a flashable zip of those apk file and flash via this tool
Ash225 said:
Can i create flashable zips of my apks. I Flash custom roms very often and some apps are needed as my daily driver so can i make a flashable zip of those apk file and flash via this tool
Click to expand...
Click to collapse
Have you tried this?
This tool in this thread is for making a zip if you already have the components (updater script and binary).
madbat99 said:
Have you tried this?
This tool in this thread is for making a zip if you already have the components (updater script and binary).
Click to expand...
Click to collapse
Thanks but i knew about this app i want to creat zips from my computer and not from my phone thats why i asked the question thanks for your prompt reply
This looks like this tool that will, hopefully, be helpful for one of my other little projects that I had to put aside till I finish catching up with some other projects/developments that's already on my plate.
I already have a working set of script commands for safely disabling the Google Play Protect but, i will need a medium/delivery system before I can release it and this looks promising to help with this.
~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Djentist said:
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Click to expand...
Click to collapse
Yeah, I'm sure one of the most respected developers on XDA would do that. I'd be more worried about those antivirus softwares you're using than anything.
Djentist said:
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Click to expand...
Click to collapse
Definitely not a very responsible post to make. There's nothing wrong about reporting your findings, but to make an accusation like this is a bit irresponsible. I also seriously doubt that Microsoft Defender identified this as a virus (as you claim).
Anyways, here are the facts: There is no virus or malicious behavior. Below are the actual results of scans by VirusTotal and VirScan
Zip Builder_4.2.1_Setup.exe
VirusTotal.com (0/65)
VirScan.org (1/39)
ZipBuildSettings.exe
VirusTotal.com (2/66)
VirScan.org (2/39)
ZipBuild.exe (32 bit)
VirusTotal.com (2/66)
VirScan.org (2/39)
ZipBuild.exe (64 bit)
VirusTotal.com (1/65)
VirScan.org (1/39)
Based on personal experience, ANY file that is not signed with a Microsoft Root Certificate and/or uses UPX compression is going to produce false positives with the heuristics deployed by some of these 'so called' anti-virus software products in the marketplace. I'm actually surprised the numbers are as low as they are.
All that said, if you are not comfortable using the software, fine. But please exercise responsible reporting if you have questions or concerns. A big part of the reason for me releasing all the source code is to avoid having to defend myself from people making exactly this type of assertion.
APK Toolkit is a native Windows GUI app for Reverse Engineering Android apps. It provides multiple tools & options for decompiling, compiling, extracting and zipping various Android file formats as well as displaying app permissions, metadata and much more
It was written from scratch when APK Easy Tool was discontinued. It has similar features to APK Easy Tool as well as a lot more updated features
Light Skin
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Dark Skin
Features
Decompile / Compile / Extract / Zip xapk, apk, jar
ZipAlign / Check align xapk, apk
Check Align xapk, apk
Sign / Verify signature apk
Assemble / Disassemble dex, odex, oat (Baksmali / Smali)
Convert xapk / split xapk to single apk
Drag & drop support for single or multiple files
Pin window so it's always on top
JumpList and toolbar shortcuts
View / Remove app permissions
View app info including if app includes native 32bit / 64bit libs and/or global-metadata.dat and libil2cpp.so
il2cppdumper & dnspy built in, also supporting single / multiple file drag & drop (Dump directly without decompiling from xapk & apk and then view instantly in dnspy)
Install compiled Apk via Adb (Android Debug Bridge) or drag & drop Apk to install
Automate adding mod-menu to xapk or apk with single mouse click
Automate adding patched libs to xapk or apk
Automate adding toast message to app on startup
Decode / Rebuild to API level
Regex Search & Replace decompiled smali code
Remove Ads from Apps / Games via Regex Search & Replace
Requirements
Windows (APK Toolkit is a native windows app)
Java for additional tools
.net framework for additional tools
Updated to v1.2
Regex Search & Replace decompiled smali code
Remove Ads from Apps / Games via Regex Search & Replace
Added Light or Dark Skin setting
Bug fixes
Download
https://www.mediafire.com/file/uv86qhvwm7q5wg8/APK_Toolkit_v1.2_by_0xd00d.zip/file
Mirror
http://e.pc.cd/qj9otalK
ooh, useful idea, but what a sloppy init release -
VolBob said:
ooh, useful idea, but what a sloppy init release -
Click to expand...
Click to collapse
You realise that this app is a GUI for ApkTool and other command line apps right?
Are you using Aapt2 in the settings?
The error in your screenshot shows it is an error with ApkTool and not ApkToolkit and there are plenty of topics relating to this ApkTool error, maybe search next time before insulting someone who is providing a free app
but what a sloppy init release
Click to expand...
Click to collapse
If you wanted help then this is the wrong way to go about it. I suggest you delete ApkToolkit and use something else
0xd00d said:
View attachment 5881817
View attachment 5881821
ApkToolkit is a native windows GUI app for multiple tools for Reverse Engineering Android apps
It was written from scratch when APK Easy Tool was discontinued. It has similar features to APK Easy Tool as well as a lot more updated features
Features
Decompile / Compile / Extract / Zip xapk, apk, jar
ZipAlign / Check align xapk, apk
Check Align xapk, apk
Sign / Verify signature apk
Assemble / Disassemble dex, odex, oat (Baksmali / Smali)
Convert xapk / split xapk to single apk
Drag & drop support for single or multiple files
Pin window so it's always on top
JumpList and toolbar shortcuts
View / Remove app permissions
View app info including if app includes native 32bit / 64bit libs and/or global-metadata.dat and libil2cpp.so
il2cppdumper & dnspy built in, also supporting single / multiple file drag & drop (Dump directly without decompiling from xapk & apk and then view instantly in dnspy)
Automate adding mod-menu to xapk or apk with single mouse click
Automate adding patched libs to xapk or apk
Automate adding toast message to app on startup
Requirements
Windows (ApkToolkit is a native windows app)
Java for additional tools
.net framework for additional tools
Download
https://www.mediafire.com/file/eryd3c7jd2w591t/ApkToolkit+v1.0+by+0xd00d.rar/file
Mirror
https://mega.nz/file/wXoiEZCb#lK2ylis3EcK0n8UPUc5gmdfMoPKrVn34hNq0LvDFtvc
Click to expand...
Click to collapse
I'm enjoying Apk Tool Kit, but it would be great if you could add a feature to install APKs using ADB. Currently, the only way to install APKs while using scrcpy is to use Apk Easy Tool. However, Apk Easy Tool kills the ADB server scrcpy spawns, which closes the mirrored window on the computer. If you could add a way to install APKs using ADB directly in Apk Tool Kit, that would be a great improvement. Thanks for your consideration!
Ives Gunther said:
If you could add a way to install APKs using ADB directly in Apk Tool Kit, that would be a great improvement.
Click to expand...
Click to collapse
I'll add that into the next release, thanks for the suggestion
@0xd00d Sir when i made clone,its not launch on android 12
Its launch perfectly with android 11
Help please
Leftrand said:
@0xd00d Sir when i made clone,its not launch on android 12
Its launch perfectly with android 11
Help please
Click to expand...
Click to collapse
It's hard to say for sure because a lot has changed in Android 12, especially access permissions
For example if app uses data folder then android 12 will not access it due to new access permissions
Does it install ok?
Do you get any error messages?
There are a few things you can try...
Disable google play protect
To disable Google Play Protect. Open "Play Store" application -> tap on Menu button -> select "Play Protect" option -> Disable the options "Scan device for security threats"
Some permissions like overlay permissions cause problems with android 12, you can try removing permissions in the AndroidManifest.xml and then trying again
Check your manifest for the mainactivity and check if you have
android:exported="false"> and if you have then set to true not false
make sure you have no duplicates in your manifest such as a duplicate mainactivity
you can also try signing with different signing versions in APK Toolkit settings
you can check your android logs via adb logcat
I don't use android 12 so have no way of testing sorry, please try the above and try and narrow down the problem
0xd00d said:
It's hard to say for sure because a lot has changed in Android 12, especially access permissions
For example if app uses data folder then android 12 will not access it due to new access permissions
Does it install ok?
Do you get any error messages?
There are a few things you can try...
Disable google play protect
To disable Google Play Protect. Open "Play Store" application -> tap on Menu button -> select "Play Protect" option -> Disable the options "Scan device for security threats"
Some permissions like overlay permissions cause problems with android 12, you can try removing permissions in the AndroidManifest.xml and then trying again
Check your manifest for the mainactivity and check if you have
android:exported="false"> and if you have then set to true not false
make sure you have no duplicates in your manifest such as a duplicate mainactivity
you can also try signing with different signing versions in APK Toolkit settings
you can check your android logs via adb logcat
I don't use android 12 so have no way of testing sorry, please try the above and try and narrow down the problem
Click to expand...
Click to collapse
Thank you for your reply sir
Install oke sir without error.
I did disable play protect all the time,my manifest also true
Recently i use np manager to remove signature verification using Modex3.0 to sign apk before i modified using apktool or apk editor,it will launch on a11 below but not a12 up
If no remove signature verification,it will not launch for both a11 and a12 after installed.
I also try sign v1 v2 v3 v4 yet no luck,only black screen and closed
Viet guy did also modified same apk but their apk lauch for a11 a12 and a13 perfectly,don't know they did
Wish i could find solution for this because your tool very handy and simple to use
Leftrand said:
Thank you for your reply sir
Install oke sir without error.
I did disable play protect all the time,my manifest also true
Recently i use np manager to remove signature verification using Modex3.0 to sign apk before i modified using apktool or apk editor,it will launch on a11 below but not a12 up
If no remove signature verification,it will not launch for both a11 and a12 after installed.
I also try sign v1 v2 v3 v4 yet no luck,only black screen and closed
Viet guy did also modified same apk but their apk lauch for a11 a12 and a13 perfectly,don't know they did
Wish i could find solution for this because your tool very handy and simple to use
Click to expand...
Click to collapse
Can you message me with a link to your APK and a link to the other modded APK which works for a11,a12 amd a13
I can't promise anything but I can try to see whats wrong using a12 emulator as soon as I get time
0xd00d said:
Can you message me with a link to your APK and a link to the other modded APK which works for a11,a12 amd a13
I can't promise anything but I can try to see whats wrong using a12 emulator as soon as I get time
Click to expand...
Click to collapse
Yess i send you both link in pm,thank you
Updated to v1.1 with some small bug fixes and additions...
0xd00d said:
Updated to v1.1 with some small bug fixes and additions...
Click to expand...
Click to collapse
Pushing Thanks button for you...
Amazing tool i like it it's so useful thanks for your great work could you please add support for dark mode in next relesae.
Updated to v1.2 with some small bug fixes and additions...
Hi guys, I'm trying to modify a system apk on my head Unit (PX5). Specifically HCT4Music.apk. I just want to modify the colours of the screen, so that it fits the inside lighting of my car. I have no problem with the modifications. But I can't get it installed by the signature. How can I keep the same signature of the original apk.
I have also tried to copy the modified apk to /system/app and the result is that it works but it does not allow me to access the music files because it denies me access to the file system.
Do you have any solution?. Thanks
Translated with www.DeepL.com/Translator (free version)
ivexsa said:
How can I keep the same signature of the original apk
Click to expand...
Click to collapse
Only if you have a rooted device, you can use original sig in apk with disable signature with magisk / xposed framework
If no rooted device then you can try one of the signature killers which hook / replace new sig with original sig
0xd00d said:
Only if you have a rooted device, you can use original sig in apk with disable signature with magisk / xposed framework
If no rooted device then you can try one of the signature killers which hook / replace new sig with original sig
Click to expand...
Click to collapse
Thank you very much 0xd00d. I have installed the magisk module and installed the system apk (music apk). But android 10 denies me access to storage devices.
Any more help?
thank you
By the way. excellent application
Looks like a great piece of kit , just wish I knew how to use it to to moddify a app, and re-sign it well done.
Nice tool, tried to decompile the apk and make change on smali file. Hit the compile button and generate the APK. But it looks like no changes which I had made with the new APK in `2 - Compiled` directory
If it compiled without error then your new changes should be in there
Are you editing the right smali file?
If you are editing libs then make sure you are editing the correct one for the architecture you are installing / testing the APK ( armeabi-v7a or arm64-v8a )