[EOL] [KITCHEN] ArchiKitchen - Android Kitchen [Linux]

Search This thread

stang5litre

Senior Member
Sep 11, 2012
4,302
2,889
Columbus
This kitchen is no longer supported --- see the link in the post above yours.
Ya if you go to that threadi found a bug for that kitchen and he just know fixed it. Was just asking archi bevause I used his for so long. But I habe superR and built a rom for my s7e but it wasn't including cache now it's fixed on superR. But as said. Love archi. [emoji106].

Sent from my SM-G935V using Tapatalk
 

XxTeXx07xX

Account currently disabled
Nov 22, 2013
198
99
Usa
meettomy.site
will Archi Kitchen root my samsung galaxy j727p..... we got the newest firmware update and i want to make a rooted stock firmware.... The new QE4 build ( sm -j727p ) need a rooted stock rom so bad! will or can Archi Kitchen do this??? Please help and if possible help create a rooted stock firmware to help me alot. Im not sure of my rom skills. I have and can get all the needed files. I can extract and send the boot, recovery.img and any needed files i already extracted n found to root. just cant get the kitchen to work correctly for me. PLEASE HELP !!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 283
    kitchen.png


    ArchiKitchen - Brand new Android Kitchen

    Commits/Changes -> https://github.com/JustArchi/ArchiKitchen/commits/master
    Source -> https://github.com/JustArchi/ArchiKitchen
    TODO list -> https://github.com/JustArchi/ArchiKitchen/issues?state=open

    Download. Of course you can also clone my repository to stay up to date.
    109
    [SIZE="+1"]Features:[/SIZE]
    • Compatible with every Linux, which provides bash shell (every available distro nowadays)
    • Full ARM/X86 support for all included android binaries (Root, Busybox)
    • Dynamic permissions - A generic list of all available permissions, with proper filter for your local build and device
    • Dynamic symlinks - A generic list of all available symlinks, with proper filter for your local build and device. Additionaly if you're building from stock image, support for including symlinks from image itself, which results in best 1:1 copy
    • FS-friendly method of flashing - ROMs created with ArchiKitchen are fully compatible with every available partition, which means that they don't reformat /system partition during flashing. This is extremely important for dual-FS support for example for EXT4 and F2FS on SGS3.
    • Kernel repacking - Powered by mkbootimg, repacking a kernel never was easier. With one click you're extracting the kernel along with ramdisk to the proper folder, and with the second you repack it back
    • Deodexing - With one click you can easily deodex your whole ROM. With multi-threaded process and automatic API detection, this never was easier as well.
    • ArchiDroid Init.d - Forget about relying on kernel's ramdisk. Implement init.d in your ROM, not the kernel!
    • Latest [Bak]smali
    • Latest SuperSU
    • Latest Busybox
    • Latest Zipalign
    • And many more in the unique shell ktichen

    [SIZE="+1"]Credits:[/SIZE]
    @osm0sis - For mkbootimg
    @Chainfire - For SuperSU
    @Stericson - For BusyBox
    @JesusFreke - For [Bak]smali
    @bgcngm - For MTK-Tools
    AOSP - For Zipalign
    64
    ArchiKitchen Tutorial

    Part 1 - Setting up Linux & ArchiKitchen on Windows

    By watching above step-by-step video, you'll learn:
    1. How to install Debian on your VirtualBox machine
    2. How to connect Windows with Linux through a shared VBox folder
    3. How to install ArchiKitchen
    4. How to create your first custom ROM, with built-in Root and Busybox

    Extra information:
    - You can use any virtualization method you want. I suggest using VirtualBox, as it's very easy, flexible and free virtualization solution.
    - You can use nearly any Linux distro. I suggest either Debian or Ubuntu, as both of them have excellent support and are very easy to install and use, compared to some other ones. However if you feel fine in Linux environment, you can install nearly any distro you like.

    Mini.iso link
    Weekly Debian Testing.iso link
    Installing virtualbox additions: apt-get install virtualbox-guest-dkms
    Installing required tools: apt-get install zip unzip openjdk-7-jdk
    Mounting a shared VBox folder: mount -t vboxsf yourName /path/to/yourFolder


    Tutorials made by other developers: @bigrammy
    Part 1. Prepare for linux Installation https://www.youtube.com/watch?v=aDsQTcDvSMY
    Part 2. Install Linux (Ubuntu/Zorin) https://www.youtube.com/watch?v=KwnIjCXXM5Y
    Part 2.5. Edit Winows bootloader to boot Linux: https://www.youtube.com/watch?v=gNpQucQxcFQ
    Part 3. Work as Root Mod & Install ArchiKitchen https://www.youtube.com/watch?v=T_ad7uML8QM
    Part 4. How to add your device locally to the Kitchen: http://youtu.be/YXNDcmf6GhI


    ArchiKitchen Questions & Answers

    Q: What is this "ArchiKitchen"?
    A: A Linux-based kitchen, with a main objective of converting stock ROM drops in .img, .tar.md5 or similar formats to CWM-flashable .zip.

    Q: So I can create my own custom ROM based on stock ROM with it?
    A: Exactly.

    Q: Is it for Linux only? Why windows is not supported?
    A: Let's face it, Android is based on Linux kernel and we could call it a mobile UNIX fork. It's hard to work with Linux-based things on Windows, in fact, Windows doesn't even offer Bash (Bourne-again shell), which is absolutely core for ArchiKitchen. Working with windows is painful, for example - .img mounting. I can very easily mount any filesystem image on Linux with just one command, while doing so on Windows usually requires a massive convertion of whole image to .zip file, then extracting a single files. Also, Windows doesn't support symbolic links, and this makes it impossible to create 1:1 copy of the image "translated" to zip file. Therefore, making a Windows port would require lots of more work and solving issues, and even with that it would still cause some core features to be unavailable. However, launching Linux on Windows is very easy thanks to VirtualBox and other virtualization software, so you don't need to reformat your PC or stick purely with Linux. In fact, this is the proposed way of using ArchiKitchen - Installing a native Linux distro (suggested: Debian or Ubuntu) and then installing ArchiKitchen on it. Take a look at tutorial to see how easily you can install and run ArchiKitchen in Linux VBox.

    Q: Is Cygwin supported?
    A: No. Cygwin IS NOT supported and it's not planned to add such support. Reason is nearly the same as above one. However, ArchiKitchen is open-source project and I'm open for all pull requests, so perhaps somebody will add support for Cygwin in the future. Until then, ArchiKitchen is compatible ONLY with Linux, and if you use it on Cygwin you're on your own with the issues that may happen.

    Q: Which phones are supported?
    A: ArchiKitchen contains a local "database" of devices, which includes a kernel/modem blocks to be used. However, as long as you know the partition layour of your device (kernel block), ArchiKitchen works with every phone and every Android variant. I'm trying to make it as universal as possible, so even if your device does not exist in our local database, it should work.

    Q: How can I add my own phone to the local database?
    A: If it doesn't exist yet, take a look at "product" folder. Inside you can notice various devices with name based on their models. ArchiKitchen will detect your ROM's model and check inside if it exists, if it does, then some properties for this model will be loaded, if it doesn't exist, then ArchiKitchen will ask user for them. Probably the best idea is to copy one of the already available models (for example "m0" - Samsung Galaxy S3), then rename new copied folder to your model name and finally edit files inside.

    Q: What is "NULL" text found for example in some MODEM files in the database?
    A: Some phones have a possibility to flash modem directly from CWM, others don't. "NULL" text indicates that this model does not support flashing modem.bin, so even if ArchiKitchen finds and recognizes it, it will pop up an error telling you that it unfortunately can't be used.

    Q: Where is SYSTEM block?
    A: System block is not being used at all, as it's a valid partition and should be located in "fstab" file in recovery already. ArchiKitchen mounts system automatically through "mount" binary, with automatic filesystem and /system path. I consider providing a system block as something obsolete, because it's only required when you're formatting a partition, and even during flashing, a wipe - delete_recursive() function is enough. Therefore, ArchiKitchen does NOT require providing a /system block.


    ArchiKitchen Troubleshooting

    Q: It looks like something is wrong with zipalign command. I can notice errors like "./zipalign: No such file or directory"
    A: This is because zipalign is x86 binary (32-bit), while you have amd64 (64-bit) Linux. Therefore, we must install some missing core packages to properly support x86 binaries. This will do the trick:
    Code:
    apt-get install lib32stdc++6 lib32z1
    42
    [SIZE="+1"]ArchiDroid Init.d[/SIZE]
    ArchiDroid Init.d is an innovative method for including init.d support in the ROM itself, and not in the kernel. ArchiKitchen supports adding ArchiDroid Init.d to any Android ROM.

    ArchiDroid Init.d is based on two files. A core - debuggerd hook, and a check part - simple init.d script.

    Init.d script is named 00ARCHIDROID_INITD, and it only creates a special file to notify the core that init.d has been already executed, therefore it can't conflict with anything and it's completely safe.

    The core is a hook for special /system/bin/debuggerd binary, which is normally called once during initial boot. Therefore, when it's called, ArchiDroid Init.d firstly waits a specified amount of time (default: 5 seconds), in case if user has already a kernel with init.d support. This is required because otherwise all init.d scripts would be executed twice - by kernel and our init.d. After specified time, if init.d is still not executed, our hook executes all scripts in alfabetical order. Lastly, when we're done, hook is executing original debuggerd binary (default: debuggerd.real) and shares the environment, arguments and everything. This is a perfect method for implementing init.d in the ROM itself, because we don't need to trust the kernel that it supports and executes init.d properly. We give it a 5 seconds to execute it, and eventually we do the job if kernel is not interested in that. This way we can support both custom kernels with native init.d support (we wait initial delay, if kernel executes init.d, all is fine and we don't have to do so), and also pure stock kernels without init.d support (we wait initial delay, kernel doesn't care about init.d, so we're executing it).

    I think that such hook works far better than relying on the kernel and modyfing stock ramdisks. Also we're sure that even if user changes kernel to any custom one, we still have reliable init.d support, regardless if custom kernel supports init.d or not.