I have flashed it on my Note, it works well.
I in no way created this, just thought it may be worth while.
The operation of this template is based on the VillainTheme System for the ROM VillainROM.
Link: http://www.villainrom.co.uk/forum/sh...inTheme-System
Credits and thanks to all XDA team that collaborated on the original script: Doctorcete, Stericson, Matt and Seshy​
What is Universal Flasher Tool?
is a complete template that is used to create the simplest possible way a subject flashable from recovery without the need to include or edit files. apk.
This new method uses the file system implementation metamorph (just have to put files and folders on their respective routes), with the advantage that the system identifies and injected into their applications without the need for external application. The subjects are flashed directly from recovery.
What are the advantages of this method compared to metamorph or traditional flasheables issues?
Do not include. Apk complete, only the files you want to include in the subject.
A theme created with this template is valid for any rom, even among different phone roms (the tests have been performed with SGS2 and Nexus one).
Optionally, the template can include complete files if desired, can even be used to install applications not system.
Does not depend on external applications like metamorph because it flashes directly from recovery.
Operation of the template
at the end of the post are attached a number of considerations to take into account, but basically works like this:
Identify the applications that want to thematize and checks that exist in the rom. Once the check, the system compares folders that will be introduced as well as files and injects them into the apk as long as the new file exists within the apk. This has been thought well to avoid filling an apk with files that do not belong because they are from another rom or because you made a mistake when typing the name, for example.
Once injected the files takes a zipalign the apk to optimize RAM usage.
Alternatively, if the topic includes external files or copy them to install applications on your path.
At the same time to be using the item, the system will generate a backup of changed files and automatically creates a file. Zip flashable from recovery, in case something goes wrong or do not like changes to previous state.
Finally, it also generates a small log with the outcome of the whole process is recorded in SD to verify that all changes are properly implemented.
How to create and edit your own theme
Download the template from the attachment in this post or the link below.
Recommended Tools: 7zip to include files and browse the file system (you can also use winzip or winrar without problems) and Notepad + + or any other plain text editor to edit the name of the mod.
Once downloaded, open the template double-click will observe and folders inside a file in the root. Here's that are in each folder and how to create the theme.
MOD.config file: (new from version 3.0) is an editable text file (recommend Notepad + +) where in addition to establishing the name of the MOD to set different parameters of the template.
MOD_VERSION= Name (name of the mod to be displayed in the system properties after the name of the rom. Are cautioned not to put a name too long and try to avoid as far as possible in the blanks.
CLEAN_MORPHING = not (compare the new files before injection into the apk, only enter if the file already exists. Turning the option dramatically reduces speed)
V4_MORPHING = yes (support to manage compatibility with existing folders-v4 system in some applications).
DO_BACKUP = yes (enable or disable the creation of the flashable backup from recovery to restore the existing theme).
LOG_ENABLED = yes (enable or disable the creation of a log file with the results of the process).
SCREEN_LOG = yes (shows the process of recovery on the screen or not. important notices are always shown even if the option is disabled).
Optionally, you can set a different path for memory cards (no need to touch these lines in most cases, you should not touch):
default_internal_sdcard = / EMMC
default_external_sdcard = / sdcard
Optionally, you can add special commands to mount partitions (no need to modify these lines in most cases, you should not touch):
mount_system = mount / system
mount_data = mount / data
README.txt:
Includes some additional instructions on the operation and the license. Please read before using the template to create a theme (in English). Carteta / tools: is the folder where you have placed the scripts and binary files necessary to flash the issue and make subsequent restoration. You do not need to touch anything in this folder to edit the theme. From version 3.0 has been deleted because busybox binary is no longer involved in the process. folder / META-INF folder system which includes the signature file and the script to launch from recovery. It is recommended not to touch. Folder / MORPH: This is the template folder where files should be included with the theme. In turn, the folder is divided into two subfolders called / data (for applications theming system NO) and / system (for theming system and applications framework). In the / MORPH / system / app files are included for the applications and / MORPH / system / framework for the framework files. NOTE: NO application theming system in / MORPH / data / app / myapp.apk supposed to change the digital signature, so from that time can not be updated from the market or will you installed in the market (like if it had been installed by 'other means' non-statutory ...). Therefore, we do not recommend any downloaded application thematize the market. You are advised that the complaints do not come then ... For each application you want to thematize must open a new folder called / nombre.apk (eg / Contacts.apk if you want to change the system application Contacts.apk) . It is necessary to respect the use of upper / lower case. Within each of these folders you have to respect that there are logical paths within applications, so that the files would have to place them in folders named / res / drawable, res / drawable-hdpi, etc ... It is the same structure metamorph an issue, so any item is readily convertible metamorph simply dragging folders.
No need to create any control file or anything like . The system is responsible for reviewing the folders to see what applications you want tematitar.
Folder / Xtras / system:
in this folder is where, if desired, can include files or complete applications that you wish to flash in conjunction with the subject. For example, sound files, bootanimation, scripts, complete applications, etc ... Folder / Xtras / data: in this folder is where, if desired, can not add applications to be installed system during flashing. Folder / Xtras / sdcard: in this folder you can add files to make copied to the SD card, as packs of icons, sounds, videos, etc ... to take into account considerations
Always respect the use of uppercase / lowercase letters in the names of files or folders and logical paths located within the apps.
With this system the themes may be universal, although depending on the type of files a user input may cease to be:
If you only include image files theme is compatible with any rom from any phone.
If you also include. xml may only operate in one rom, but can still work on future updates of it.
If resources are included for translations (resources.arsc) the issue would only be valid for a particular rom.
The. Zip with the issue is not necessary for you to sign flashearse, and is valid for CW-Recovery and Recorevy-RA. If you do not have to remember signing off signature checking before flashing.
Original Thread:http://http://www.htcmania.com/showthread.php?t=258333
Also:http://forum.xda-developers.com/showthread.php?t=1474686
On the galaxy s 3 us version most of the recoverys are not reading the external sd so should I changed the mounts on the script?
Sent from my SGH-T999 using Tapatalk 2
Related
Premise is that there are many backup utilities that will backup/restore either dirs or the whole ROM, but not just for a specific apps settings. There are many ways that dev could use to store their settings for a given app, but getting them all to do the same way is "difficult". However, if program A had it's settings in a settings.ini (or whatever name) and that specific file could be backed up and restored later after a hard reset or new ROM installed, it would make the flashing a ROM even easier since UC came out.
My idea is for an app that works sort of like AppToDate, in that it will parse a collection of ini files in a directory to determine what a given progam uses for it's configuation (files or reg keys) and will backup/restore them.
Basically all that someone needs to do is:
- Extract the UMCe2.zip to a folder on their Storage Card
- Register Mortscript (just click on it once, from this point on you can just click on a script and it will run.)
- Place the INI files that define the files or keys of the app that you'd like to backup/restore into the \Storage Card\UCMe2\ini folder. I have posted a small collection of some INI files as examples
- If you'd like startmenu shortcuts, I attached a few dummy.exe files that you can put into the UCMe2 folder so you can make shortcuts.
- Run the UCMe2_Backup and it will read every INI file in the ini folder and store the backup files in \Storage Card\UCMe2\Backup
- Run the UCMe2_Restore and it will read every INI file in the ini folder are restore the backups
I want the app do do a few things:
* to run start to finish unattended... start the program and it just runs, with no questions asked. (for scheduling purposes)
* the config ini for apps need to be simple to read/edit, so user community can post/share them, or be created by the original app devs
Feel free to create your own INI files and post them here for others to share
I have updated the scripts to include the SDConfigCE tool, to create a new SDConfig.txt based on the files that you have placed in the CABS subfolder.
Additionally, I have included XCopyCE support in the created SDConfig.txt file to copy files placed in the Files subfolder to the device.
(added test sdconfigce.zip to attempt to detect devices with internal storage vs. storage card and SHOULD manage other ROM languages)
Todo list:
add ProcKill and SuggestReboot options to ini file
-optional kill process before backup/restore
-optional suggest reboot after restore if suggested in ini file
add optional Disable parameter to ini file to "turn it off"
add section to backup/restore individual reg values (instead of entire subKey)
-[RegValues]
-Value1= root, subkey, value, data, type
Build in Restore script to run during UC to further automate UC
Provide bulk REG file import, over and above the scripted reg key values provided by INI files
Click to expand...
Click to collapse
Bug List:
Validation key in ini files do not like LONG reg root names, workaround is to change them to HKLM or HKCU as necessary
- change: Validate = HKEY_LOCAL_MACHINE,Software\Apps\Google Maps
- to: Validate = HKLM,Software\Apps\Google Maps
Click to expand...
Click to collapse
Updates in version 0.1.4:
updated bug in restoring of backup files. Now it will create missing directories and actually copy in the files :-0
Click to expand...
Click to collapse
Updates in version 0.1.3:
updated bug in validation logic on the restoring of backup.
Modified Backup script to automatically generate new SDConfig to make that "last minute" backup into a 1 step process.
Click to expand...
Click to collapse
Updates in version 0.1.2:
Created tool to create SDConfig.txt file automatically based on the presence of CAB or XML files in the CABs subfolder
Provided XCopyCE support to do file copy of the contents of the Files subfolder to the device during UC
Updated Menu applet to call the SDConfigCE tool
Click to expand...
Click to collapse
Updates in version 0.1.1:
Replaced dependancy of SKTools with DotFred Taskmanager for reg functions (it is even smaller and faster and freeware)
Changed display of progress in GUI
Added Version numbers in script and GUI
Click to expand...
Click to collapse
Initial release 0.1.0
How to make your own INI file:
The ini file is a very simple thing to make as it is basically just a text file with a few bracketed headers (sections) and values in them.
The easiest way to do so, is to place a copy of the template on your PC desktop and open it with notepad.
Then use the freeware tool CERegEditor ( http://ceregeditor.mdsoft.pl/ ) to read your device's registry... MOST apps save their customization in:
HKEY_CURRENT_USER\Software\ (App Publisher) \ (App Name)
There are plenty of sample files to use as references. If you need help, I'm certain that someone in this community can help.
PocketBreeze.ini
[UCMe2]
appname=PocketBreeze
subdir=PocketBreeze
Validate = HKLM,Software\Apps\SBSH.net PocketBreeze
[regkey]
key1=HKEY_CURRENT_USER\Software\SBSH\PocketBreeze
Click to expand...
Click to collapse
OwnerSettings.ini
[UCMe2]
appname=Owner
subdir=Owner
[regkey]
key1=HKEY_CURRENT_USER\ControlPanel\Owner
Key2=HKEY_LOCAL_MACHINE\Ident
key3=HKEY_CURRENT_USER\Software\Microsoft\Bluetooth\Settings
Click to expand...
Click to collapse
GoogleMaps.ini
[UCMe2]
appname=GoogleMaps
subdir=GoogleMaps
Validate=HKLM,Software\Apps\Google Maps
[Files]
cache-GLM.dat=\Application Data\GoogleMaps\cache-GLM.dat
index-GLM.dat=\Application Data\GoogleMaps\index-GLM.dat
prefs.dat=\Application Data\GoogleMaps\prefs.dat
prefsext.dat=\Application Data\GoogleMaps\prefsext.dat
prefsext2.dat=\Application Data\GoogleMaps\prefsext2.dat
prefsfriends.dat=\Application Data\GoogleMaps\prefsfriends.dat
prefsfriendsmini.dat=\Application Data\GoogleMaps\prefsfriendsmini.dat
strings-all.zlb=\Application Data\GoogleMaps\strings-all.zlb
Click to expand...
Click to collapse
Format of ini file is:
[UCMe2]
AppName = Friendly name for future use
subdir = subfolder to store the files
Validate = condition to look for before restoring (either a filepath and name or reg key... Reg key must be formatted like ROOT,KEY)
[regkey]
filename1 = regkey to backup
filename2= other regkey
[Files]
destinationfilename1.ext = source filename with full path
destinationfilename2.ext = source filename with full path
Just create an ini file for each app to backup
**** Reserved for suggestions or requests
I'm thinking of adding a switch to the ini files as a block to prevent backing up certain apps...
It would be used to "install" an app that only needs file copy like an exe or shortcuts or similar... no sense of copying back those files for backup, as they would never change.
an entry in the ini like:
[UCMe2]
RestoreOnly = 1
Would it make a difference to anyone if I CREATED new app shortcuts, or just copied the old ones for backup/restore?
Another optional ini setting should be:
[UCMe2]
Validate = <fullpath\file> or Reg key
Which would only restore the backups of the appropriate reg key or path\file exists. No sense restoring data for an app if it isn't yet installed.
hmmm...
I've added a bit of a GUI to the backup process, just to see something while it runs. I'll get around to doing the same to the restore mode...
UCMe2.mscr
Code:
ScriptDir = SystemPath("ScriptPath")
IniFiles = ScriptDir \ '*.ini'
StatusType(ST_LIST)
StatusInfo("UCMe2 Backup", "Backup process running")
ForEach F in files (IniFiles)
AppName = IniRead(F,"UCMe2","appname")
SD = IniRead(F,"UCMe2","subdir")
RestoreOnly = IniRead(F,"UCMe2","RestoreOnly")
StatusShow()
StatusMessage( AppName, ST_LIST, TRUE )
If (RestoreOnly = False)
MkDir(ScriptDir \ SD)
ForEach K, V in iniKeys (F,"regkey")
RunWait(Scriptdir\"SKTools.exe","#REXP(" & V & ") #FNAME(" & ScriptDir \ SD \ K & ".reg)")
StatusMessageAppend( "." )
EndForEach
ForEach K, SettingsFile in iniKeys (F,"Files")
copy (SettingsFile, ScriptDir \ SD \ K ,TRUE)
StatusMessageAppend( "." )
EndForEach
StatusMessageAppend( "OK" )
ElseIF
StatusMessageAppend( " - Skipped by RestoreOnly value" )
EndIf
EndForEach
StatusMessage( "Backup Complete" )
WriteStatusHistory( Scriptdir \ "BackupLog.txt" )
StatusMessage( "Window closing in 5 seconds" )
Sleep( 5000 )
StatusType(ST_HIDDEN)
Updated the scripts a bit and made a GUI menu... but that has limited value, beyond my playing with MortScript
here is a template of the current ini entires, but most of them aren't necessary... see the examples I already have in the zip.
Code:
[UCMe2]
appname = (descriptive Name)
subdir = (subfolder name)
RestoreOnly = 0/1 (1 = do not back up this app)
Validate = <fullpath\file> or Regkey HKLM,Software\appname\key (NOTE the comma in the reg key)
[regkey]
key1="HKEY_CURRENT_USER\Software\AppName\etc"
key2="HKEY_LOCAL_MACHINE\Software\AppName\etc"
[Files]
backupFilename.ext=Fullpath to sourcefilename.ext
anotherbackupFilename.ext=Fullpath to sourcefilename.ext
andanotherFilename.ext=Fullpath to sourcefilename.ext
rilphone2.ini
[UCMe2]
appname=Rilphone2
subdir=Rilphone2
[regkey]
key1=HKEY_LOCAL_MACHINE\Drivers\BuiltIn\RIL
[Files]
rilphone2.dll=\WINDOWS\rilphone2.dll
Click to expand...
Click to collapse
PocketBreeze.ini
[UCMe2]
appname=PocketBreeze
subdir=PocketBreeze
RestoreOnlyIfRegExists = 1
Validate = HKLM\Software\Apps\SBSH.net PocketBreeze
[regkey]
key1=HKEY_CURRENT_USER\Software\SBSH\PocketBreeze
Click to expand...
Click to collapse
I see where I should make a subdir to hold the INI files, and another to hold the backup folders... the prog dir is getting cluttered
I can see another mini app for this process... one to enable or disable individual ini files... (probably just move them to a different folder instead of deleting the ini file)
I don't think Mortscript has that kind of support for forms, so it might remain a manual process for a while. Lemme see how clever I can be
attached pics to post 1
there is a minor issue in the restore script... I have to re-think my logic for the validation determination, but I'll get that
I fixed the restore mode problem. as well are eliminated 2 unnecessary fields from the INI files.. the RestoreIfRegExists (or file)... now it just examines the content of the validate field... if it has a comma in it, it assumes it is a reg entry.
I still need to put in error handling, but I have to figure out how that all works in MortScript.
I also am considering having it backup/restore specific reg values, in addition to the whole key, but much of will be based on MortScript... it is lacking in reg features and I'm currently dependant on SKTools to do the reg functions... I'd much prefer to do it internally, but MS doesn't have a way of determining the regtype that it is reading, so I can't store that so I can restore it to the correct type.
fixed a simple issue of the reg export grabbing the level higher and exporting from there.
let me be the first one to reply the app looks nice, isent it nice that MortScript can be used in many ways?
This is great, I will be watching on this
that's funny how this is like a 2-page OP
but this is a fantastic idea and crazy useful if it comes to fruition. between this and UC or sashimi, flashing roms would have so little downtime..wow....
This thread will serve as a bottom-up guide to modifying SPB Mobile Shell 3.5. Any help and links is appreciated and will be incorporated.
Last updated: 10/24/09
*Basics of SPB Mobile Shell 3.5*
Areas of the program that can be modified are based on an XML architecture.
Entering the Program Files folder, one finds many files named *.dat. Many of these correspond to concepts or widgets that are easily familiar: clocks and etc., and several of them are responsible for the larger structure and feel (qa_layouts, for example). A more comprehensive listing of all the include files is:
[To come]
*.DAT Structure*
.dat files that can be modified are actually standard .zip archives. Simply copying them over to your PC, changing the file extension from .dat to .zip, then opening the archive and extracting the files inside, shows you all that comprises a given widget or layout.
assword: In extracting files from the .zip, one will be prompted for a password, which is universally b0fm18zq .
The files contained in an archive are generally a mix of .xml files (determination layout, composition and functionality) and .bmp (image files that correspond to the different looks a widget may have). The .xml files may be viewed and edited in any standard text editor, like Notepad++, and the .bmp files can be viewed and edited in anything from Photoshop to Microsoft Paint (though, for exactitude, Photoshop or similar is best).
*What Goes Into a Widget*
A widget is defined by three specific files (with filename containing the three prefixes qa_, va_, and ma_), as well as by XML references in files like qa_layouts.dat and qa_layouts_bup.dat.
*Simple Widget Appearance Modification*
Luiggi's 9 Icon Build Guide: http://rapidshare.com/files/101365258/9_Icon_Build_Guide.zip
Just making a quick link here to another forum thread for Vostradamus Mobile Shell Manager. Besides the app there's also a lot of information there on how to modify widgets:
http://forum.xda-developers.com/showthread.php?t=689087
I have a shutdown sequence and some sounds I would like to turn in to a flashable .zip file. I checked out the CW forums, but that was more painful than informative. I have taken a look at some of the zip files I have found so far, but am not 100% sure about what I'm doing. Can anyone point me to a how-to or even in the general direction of some information to get me started?
Thanks guys!
Edit: Those interested can find all the information needed in the3dman's post and here:
http://www.londatiga.net/it/how-to-create-android-update-zip-package/
http://www.londatiga.net/general/how-to-sign-apk-zip-files/
I'd copy this guy
http://forum.xda-developers.com/showthread.php?t=795459
Thanks for the link. I had actually started there, and it's a great template if I just want to throw in my own files, but I was really looking for a how to so that I had more options for customizing, rather than being stuck with only the shutdown / startup sequence.
Sent from my SGH-T959 using XDA App
First you have to have your folder structure like this in the zip:
Main .zip
{
META-INF { com -> google -> android -> update-script } ( <- these are folders inside the META-INF except update-script this is a script file)
app (if the file you want to flash is an app it goes in this folder)
framework (if the file you want to flash is a framework file it goes in this folder)
system (if the file you want to flash is a system file (start up animations) it goes in this folder also make sure you put the correct subfolder inside this folder ie: if your file goes in system -> media make sure you put the file you wish to flash in a correctly named subfolder other wise it will flash into just the system folder and not into the correct folder within the system folder on your phone.)
}
After your folder structure is set up you must tell clockwork which folder or folders in the zip to flash. To do this open the update-script from the zip with a text editor and modify or add these lines with the correct folders.
copy_dir PACKAGE:framework SYSTEM:framework (use this for the framework folder)
copy_dir PACKAGE:app SYSTEM:app (use this for the app folder)
copy_dir PACKAGE:system SYSTEM:system (use this for the system folder)
Then sign your zip and flash.
Below is a picture of an example folder structure so show what I mean. Also I attached a zip with an example update-script in it.
the3dman said:
First you have to have your folder structure like this in the zip:
Main .zip
{
META-INF { com -> google -> android -> update-script } ( <- these are folders inside the META-INF except update-script this is a script file)
app (if the file you want to flash is an app it goes in this folder)
framework (if the file you want to flash is a framework file it goes in this folder)
system (if the file you want to flash is a system file (start up animations) it goes in this folder also make sure you put the correct subfolder inside this folder ie: if your file goes in system -> media make sure you put the file you wish to flash in a correctly named subfolder other wise it will flash into just the system folder and not into the correct folder within the system folder on your phone.)
}
After your folder structure is set up you must tell clockwork which folder or folders in the zip to flash. To do this open the update-script from the zip with a text editor and modify or add these lines with the correct folders.
copy_dir PACKAGE:framework SYSTEM:framework (use this for the framework folder)
copy_dir PACKAGE:app SYSTEM:app (use this for the app folder)
copy_dir PACKAGE:system SYSTEM:system (use this for the system folder)
Then sign your zip and flash.
Below is a picture of an example folder structure so show what I mean. Also I attached a zip with an example update-script in it.
Click to expand...
Click to collapse
Thank you very much! This was PERFECT for getting me started! This lead me to the following sites for more information on how-to's and even all the available syntax. For anyone looking to get into this (it's not difficult), check out these pages:
http://www.londatiga.net/general/how-to-sign-apk-zip-files/
http://www.londatiga.net/it/how-to-create-android-update-zip-package/
Plugin Installation:
Open the Plugin Manager
Choose Install a Plugin
Choose the plugin you want to install
Choose Run a Plugin
Choose the Plugin you want to run
Enjoy!
NOTE: The usage instructions in each plugin description below assume you have already installed it. When the instructions end, that's when you run the plugin from the plugin manager.
SuperR's Kitchen Plugin Descriptions
SuperR Maintained Plugins:
add_placeholder
Only for system-as-root devices
Adds placeholder files to all empty directories in your project
add_remove_files
Add all apk files from a directory
Choose apk to import
Choose directory structure to import
Delete files from your ROM based on directory structure
NOTE: To use "Choose directory structure to import" and "Delete files from your ROM based on directory structure", your directory must be set up as the following example:
Code:
your_directory_name/system/anything_you_want
your_directory_name/vendor/anything_you_want
your_directory_name/cache/anything_you_want
your_directory_name/hidden/anything_you_want
your_directory_name/boot.img
The above is only an example. You can add anything you want as long as there is a "system" directory inside another directory. When choosing the directory, choose your_directory_name instead of system or it won't work. Think of the directory structure exactly like the kitchen project directory. When you import directory structure, your directory will be copied into your project directory and files will be overwritten if they already exist. When you remove a directory structure, you will choose your_directory_name again and the plugin will remove the same files it finds from your project directory.
amlogic_unpack
Unpack Amlogic firmware img
apktools
Choose an apk from your current rom directory.
Decompile the apk.
Build apk.
Sign apk with 3 options (use signapk.jar, copy original META-INF to new apk, or copy new classes.dex and resources.arsc to original apk).
Move apk back to where it came from.
Patch smali using .ptch files
Delete META-INF from all apk files
Delete SEC-INF from all apk files
Separate lib directory from all apk files
Zipalign apk files
aroma_install
Install Aroma in your existing ROM.
Create aroma-config using a menu.
Choose apk files to add to the option menu.
Usage:
Extract your ROM normally using ONLY set_metadata or set_perm.
autorom_config
Creates an AutoROM config file to automate the extraction process and many other tasks.
Currently supports perm type, vendor.img, rom name, custom signature, deodexing, root, su.d, and Busybox
buildprop_add
Adds lines from a file to build.prop.
concatimg
Combines partition_*.img files into a single img file
custom_zip
Create a flashable zip of one or more image files as long as you know the partition name where it should be flashed.
Create a flashable patch zip from directories that have matching fs_config and file_contexts3 files
Convert updater-script to update-binary script for use in the mods_install plugin
Usage:
Copy the partition images and/or directories you want in the zip into a new directory in your project.
In the kitchen main menu, choose Plugin Manager > Run a plugin > custom_zip
Choose the new directory from the list.
For img files in by-name devices, type the partition name from your device where it should be flashed (ex. aboot)
For img files in mmcblk devices, choose your block from the list (add it to the device superr_mmc file if needed first).
decrypt_htc
Decrypt ruu.exe and ruu.zip files stored in your current project directory.
Extract system.img & boot.img to the current project directory for extraction.
Usage:
Copy ruu.exe or ruu.zip to current project directory (ruu.zip must be named exactly ruu.zip).
gapps
Downloads and includes Open Gapps in your ROM.
Choice of aroma, super, stock, full, mini, micro, nano, or pico
Detects Android version and architecture from ROM to download the latest available version for your device.
If there is no ROM, it will allow you to choose Android version and architecture.
Remove gapps if it already exists.
gen_set_metadata
Generates set_metadata lines for every file in project directories that have matching fs_config and file_contexts3 files.
img_tools
Allows rebuilding ext4 img files that have been extracted by the kitchen even if there is not a complete ROM in the project.
Convert sparse img to raw img
Convert raw img to sparse img
Build super.img
Resize img
super.img Build Requirements:
All included img files must be built as sparse.
img file names must be either partition.img or partition_new.img.
super.img size must be in 00_project_files/srk.conf.
Example:
supersize=9437184000
The numeric value in the example above is the raw super.img file size in bytes.
The kitchen adds the super.img size when unpacking a super.img. If the kitchen did not unpack the super.img, you can enter the size in srk.conf manually.
Optional values metadata-size and metadata-slots can also be added to srk.conf. Defaults are listed below:
metadata-size=65536
metadata-slots=2
*This plugin will only work in v3.2.1.0 or higher*
lg_tools
Unpack LG kdz files
Removes rctd, ccmd, and triton from LG boot.img.
mods_install
Add any flashable zip to your ROM that uses an update-binary script instead of a updater-script
Remove mods
Shows the kitchen added mods you currently have installed
ozip_decrypt
Decrypt firmware.ozip files
payload_dump
Unpack payload.bin firmware
rockchip_unpack
Unpack Rockchip firmware img files
samsung_tools
Asks one-by-one if you want to add ro.config.tima=0, ro.config.knox=0, ro.securestorage.knox=false, ro.securestorage.support=false, ro.security.mdpp.ux=Disabled, and wlan.wfd.hdcp=disabled to ramdisk default.prop
Create tar.md5 from all img, mbn, ext4, and bin files in your ROM directory.
Create tar.md5 from all the above except system.img, system.img.ext4, boot.img, and recovery.img
Decode OMC/CSC
Deodex patch for Android 8.1+
Pack *_new.img files to lz4
sepolicy_injector
Converts sepolicy denials into allow rules, and optionally patches seplicy with the new rules.
Paste a denial
Read denials from 00_project_files/logcat.log
unsign_mtk_img
Removes MTK signature from img files
updateapp
Extract firmware.zip that contains UPDATE.APP
Extract img files from UPDATE.APP
Usage:
Place a firmware.zip or UPDATE.APP in your rom directory.
xiaomi_patch
Patches several things in Xiaomi firmware.
Usage:
Extract your firmware with the kitchen, then run the plugin.
xperia_unpack
Unpack Xperia firmware
Choose full firmware zip, an ftf file, or a sin file.
When choosing a sin file, all sin files in the project directory will be unpacked.
Respects the partition_extract_list variable from kitchen/tools/srk.conf
User Contributed Plugins:
None
Custom Plugins
The donate version has plugin support. This means you can integrate your own script into the kitchen. Each plugin must have its own directory inside the kitchen plugin directory, and it must be named the same as the plugin script.
Examples:
/kitchen/tools/plugins/example_bash/example_bash.sh (Linux, Mac)
/kitchen/tools/plugins/example_batch/example_batch.bat (Windows)
You can check the example plugins in the kitchen for more details and use them as templates for your own plugin.
There are 3 variables set in the example plugin to take note of:
bd = /path/to/kitchen
rd = /path/to/kitchen/superr_projectname
plugdir = /path/to/kitchen/tools/plugins/pluginname
NOTE: If you would like to contribute a plugin, please PM a link to the plugin for review.
This post contains the last working versions of all plugins that have lost native Windows support.
If you are running the kitchen in WSL, WSL2, Linux, or Mac you should use the kitchen plugin manager to get the latest versions of these plugins.
This is your battery view when your device is turned off and plugged in.
This thread is Made for the S5 specifically (though these images can be used if rescaled to the right size.
The file can be known as Battery_scale.PNG
The file can be Located at. /res/images/charger
The file is a Multi surface image. Basically a zip png
To extract All the ".PNG" files use. https://github.com/Aaahh/Battery-Images-Replacer
Thanks to @Aaahh for making this a lot easier
Originally posted by cunha17 @ https://forum.xda-developers.com/showthread.php?t=1609059&page=5
Battery-Images-Replacer (forums.oneplus.net/threads/battery-charging-image-replacer.186460) is a way to easily change the battery boot animation. You can use Aaahh provided images or change them and make your own flashable zip. There are 2 problems in that solution, first it is directed to a specific platform (oneplus) and second, it does not work in Marshmallow (CM13).
I figured out a way to make Battery-Images-Replacer to work in Android 6 (Marshmallow) and problably in 5 (Lollipop). Just stating that I'm using CM13 in a Galaxy S3 (i9300) phone, but the code is the same one Aaahh provided with two minor changes:
The battery_?.png and battery_charge files are deprecared in 6.0, and replaced by battery_scale.png (multi surface image) with mandatory 6 frames (hardcoded in Android). To make Battery-Images-Replacer work with previous Android versions, the deprecated files are kept; and
The block device in anykernel.sh file needs to be generalized to work in i9300 (my case) and maybe others, so it was replaced at line 9 with: block=`find /dev/block/platform -name BOOT`;
Warning: be shure to do the 2nd step above, or the flashing will not work, but also, you may brick your phone!!!
But the catch is the creation of the new battery_scale.png file. In this case, we have the 6 single surface images (battery_?.png files) and want to make a "Multi Surface Image" file compliant with Android 6.0.
I made the following script (create_multi_surface_image.sh) that convert multiple PNG to a single "Multi Surface Image", you just need to change the FILES and SCALEFILE variables if needed. This script uses ImageMagick, exiftool and pngcrush to do the job. Just run the script where the battery_?.png files are.
create_multi_surface_image.sh
Once the battery_scale.png is created, you need to copy it to the Battery-Images-Replacer-ak-opo-anykernel/charger/ directory if you didn't run the script there. Go to the base directory (Battery-Images-Replacer-ak-opo-anykernel) and run "zip -r ../Battery-Images-Replacer.zip ." and you should get the flashable zip file at the parent directory.
Now transfer the zip file to your phone (adb push, usb file transfer, etc) and make shure that the file is available to TWRP ou CWM. Boot into recovery and flash the zip file. Turn off the phone and start charging. Enjoy your new battery animation.
I will attach the battery_surface.png file if you just want the final result using the source files (battery_?.png) provided by Aaahh and available at github.com/Aaahh/Battery-Images-Replacer.
Thanks Aaahh for the great job!
And what you have waited for
(Please note this is from my device which is running RR9.0)
(Edit will upload via computer as labs doesn't let edit an add images)