Develop Bugs

[KITCHEN][06.05.2010]Manila CMD Kitchen Environment

When I first started on this project, this kitchen existed of 5 script each containing few lines of code, only able to handle one LUA script at a time. I had just helped out on the first ever manila 2.0 VGA port and I could see the use of a kitchen that did most of the manual labour automatically. At that time my understanding of what needed to be done to successfully edit script was limited. As I tried to add more features to the script I learned more about LUA, the handling and decompiling of the scripts. I chose to make the kitchen do as much for you on first run. The kitchen got more mature after I met hilaireg who knew a lot more about batch scripting than I did and who's perfectionist style made the kitchen what it is today.
After we teamed up we started a little manila group and got into contact with co0kiemonster. He's the one who created\updated most of the tools on which the script relies, and so not only optimizing manila handling but also pushing it's boundaries. We put in the applications that best handle manila files and connected these via the script. Since our last update co0kie kept developing the tools and they became a lot better. A batch script isn't really the way to handle this but until we get a real manila GUI, we decided to give the script one last update. Since this will likely be the last big project hilaireg will be presenting here, this last version is dedicated to him.
Workstation/System Requirements:
The Manila Kitchen environment can run on a Windows XP, Windows Vista, and Windows 7 platform providing the following requirements are met:
Microsoft .NET 3.5 SP1 (M9Editor)
Elevated priviledges
Windows XP/Vista/Seven
Kitchen Contents:
ROOT
MANILATOOL.CMD by hilaireg & 12aon
Manila Kitchen Guide
Revision History
_SOURCE folder
_TOOLS folder
Shortcuts to tools
TOOLS
LUATOOL.EXE by Co0kiemonster
M9EXT.EXE by Co0kiemonster
MANILANAMES.EXE by Co0kiemonster
M9EDITOR.EXE by 6Fg8
CFC_GUI.EXE by Chainfire
NOTEPAD2.EXE by Florian Balmer, Compiled by Co0kiemonster
MANILAHASH.EXE by NisseDILLIGAF
XVI32.EXE by Christiaan Maas
RAPICOPY.EXE, RAPIPROC.EXE, RAPISTART.EXE by Scott Seliman
GREP.EXE by Tim Charron
Current Version (Attached Files)
Manila Kitchen 5.05.06, 4.7 MB (06/05/2010)
Previous Versions
Manila Kitchen 5.04.23, 4.7 MB (23/04/2010)
Manila Kitchen 5.03.04, 4.1 MB (04/03/2010)
Manila Kitchen 4.10.16, 9.3 MB (16/10/2009)
Manila Kitchen 4.10.02, 7.7 MB (02/10/2009)
Credits:
Special thanks to the following folks for sharing their knowledge and expertise. If I missed someone, it's purely accidental – send me a note and I will add your name to the list.
6fg8
chainfire
co0kiemonster
sztupy

Overview
The Manila Kitchen is an automated environment that includes tools (utilities) to perform decompilation, editing, and recompilation of HTC Manila OEM files.
Instructions are passed to the MANILATOOL command script which in turn, initiates various executables to perform the necessary actions required on the HTC Manila OEM files.
Some of the tools used by MANILATOOL were written by 6fg8, chainfire, co0kiemonster, and sztupy. As such, some of these tools are not compatible with excessively long path names or paths that contain spaces or brackets. To avoid issues, place the Manila Kitchen in a relatively short path that does not contain spaces or brackets such as: C:\XDA\Manila_Kitchen
The Manila Kitchen provides the following benefits:
Consolidated Tools
All of the tools required to perform Manila related activities have been incorporated. These include decompilation, comparison, recompilation, .CAB creation, direct deployment to mobile devices, updating Mode9 Editor reference index, and backing up. The executables are initiated with the appropriate command parameters and in the correct sequence by MANILATOOL thus eliminating the "guess work" typically required.
Improved Resiliency
The activities required to manage HTC Manila OEM files are complex in nature. In some cases, a Manila file may fail to be decompiled or cause one of the initiated executables to generate and error as a result of an unexpected condition. The MANILATOOL command script will attempt to recover from such errors when possible so as to complete the command that was initiated.
Command Line Help and Version Information
Wondering what command parameters are available in the MANILATOOL command script? Simply append -HLP to the end of the MANILATOOL command script to display a summary of parameters available. To determine the version of the MANILATOOL command script in use, append -VER to the end of the MANILATOOL command script.
Enhanced File Recovery
Accidentally changed a file and need the previous version? The MANILATOOL command script performs a backup before any critical operation making it easier to retrieve a previous version of a file.
Enhanced Script Diagnostics
Although a significant of amount effort has gone into the development of the Manila Kitchen, it is possible that a script logic error may occur. To assist in troubleshooting such errors, the MANILATOOL command script includes a comprehensive logging debugger.
Topic Index
Preparing the Kitchen Environment ....... 3
Initializing the Kitchen​Decompiling Manila OEM Files ............ 4
LUA Editing
Mode9 Editing
General Editing
Updating 'm9editor.names.txt'
Updating the Repository​Working with Manila Files ............... 5
Initializing the Kitchen​Recompiling Manila OEM Files ............ 6
Recompilation​Testing the Manila OEM File Changes ..... 7
Installer .CAB Method
Direct to Device Method​Reference Web Links ..................... 8
Frequently Asked Questions (FAQ) ........ 9

Preparing the Kitchen Environment
The Manila Kitchen environment must be initialized prior to initial use. During the initialization phase, all MANILATOOL command script parameters are enabled and the contents of following folders, sub-folders, and files are removed and recreated:
_backup
_queue
Decompiled
Release
Repository
Workspace
The following configuration files will be reset to their initial settings:
m9editor.cfg .\_TOOLS\M9Editor
notepad2.ini .\_TOOLS\Notepad2
xvi32.ini .\_TOOLS\XVI32
The following applications shortcuts will be reset to their initial settings:
CFC_GUI.lnk
M9Editor.lnk
manilaHASH.lnk
Notepad2.lnk
HexEdit32.lnk
The following Manila Mode9 reference index will be reset to their initial settings:
m9editor.names.orig.txt .\_TOOLS
mnf_m9paths.orig.txt .\_TOOLS
m9editor.names.orig.txt .\_TOOLS\M9Editor
Initializing The Kitchen
The following procedure will initiate the Manila Kitchen initialization process. All HTC Manila OEM files found in the .\_SOURCE folder will be copied to the .\_queue folder.
Currently, there are two versions of Manila reference index names; one for pre-Manila 2.5 and one for post-Manila 2.5. It is possible to set the initial Manila reference version during the kitchen initialization procedure. For example, if the .\_SOURCE folder contains a specific version of HTC Manila OEM files, specify the Manila version as part of the parameter. If the kitchen will contain a mix of pre-Manila 2.5 and post-Manila 2.5 files, an incomplete set of Manila files, or an unknown Manila file, specify 0.0 as the kitchen version.
The following procedure will initiate the Manila Kitchen initialization process.
► To initiate a Manila Kitchen reset and specify Manila version 1.3
Place a copy of the original (untouched) HTC Manila OEM files or packages in the .\_SOURCE folder.
Double-click (launch) the Command Prompt shortcut found in the root of the kichen folder.
At the prompt, type the following command: manilatool.cmd -oem:1.3
Press ENTER.
► To initiate a Manila Kitchen reset and specify Manila version 2.5
At the prompt, type the following command: manilatool.cmd -oem:2.5
Press ENTER.
► To initiate a Manila Kitchen reset and specify a mix, small set, or unknown Manila files
At the prompt, type the following command: manilatool.cmd -oem:0.0
Press ENTER.

Decompiling Manila OEM Files
HTC Manila OEM files must be decompiled before changes can be made to them. The decompilation of HTC Manila OEM files occurs on files that are found in the .\_queue folder. Use the Manila Kitchen initialization process to copy the HTC Manila OEM files from the .\_SOURCE folder to the .\_queue folder before attempting to decompile files.
As files are processed, they are removed from the .\_queue folder and placed in a .\Processed folder. Once completed, decompilation mode will be disabled so as to prevent accidental loss of work to decompiled Manila files. The Manila Kitchen must be initialized in order to enable decompilation mode.
Decompilation
The decompilation process passes each manila file found in the .\_queue folder to the LUA processor (luatool.exe) tool. During the decompilation process, the LUA processor (luatool.exe) tool validates the decompilation and produces additional output files if the decompilation was not successful.
Additionally, the decompilation process will extract a copy of embedded Manila (Mode 9) scripts, initiate the LUA processor (luatool.exe) tool to decompile the extracted script, and validate that the decompilation occurred successfully.
Upon completion, a decompiled version of the Manila file will be found in one of the following folders - which are determined by the results of the decompilation process:
Completed: .\Workspace\_lua (successfully decompiled)
Incomplete: .\Workspace\_lua (partially decompiled)
Error: .\Workspace\_lua (failed decompilation)
InternetPortal: .\Workspace (XML files)
Manilapages: .\Workspace (XML files)
Mode9: .\Workspace (Mode9 files)
PNG: .\Workspace (Image files)
QTC: .\Workspace (Image files; in Graphics folder)
SQLite: .\Workspace (Database files)
TTF: .\Workspace (True Type Font files; in Graphics folder)
XML: .\Workspace (XML files)
Unknown: .\Workspace (Unknown files)
The following procedure will initiate the Manila Kitchen decompilation process.
► To initiate HTC Manila OEM file decompilation
Ensure desired HTC Manila OEM files are present in the .\_queue folder once the kitchen initialization has completed.
Double-click (launch) the Command Prompt shortcut found in the root of the kichen folder.
At the prompt, type the following command: manilatool.cmd -dec
Press ENTER.

Working with Manila Files
Once the HTC Manila OEM files have been decompiled, changes may be made as required. The Manila Kitchen provides a single work area for Manila file editing; this is:
Workspace
Workspace
This workspace contains all of the decompiled Mode9 files, graphics, and other Non-LUA files that are typically manipulated using the M9Editor, Notepad2, and/or CFC_GUI.
Workspace\_lua
This area of the workspace contains all of the decompiled LUA files. Use a standard UTF-8 compatible editor such as Notepad2 to make changes to the files.
LUA Editing
Files that have failed to decompile during the initial decompilation process typically need to be manually edited so as to address the cause of the failure. Editable *.lua Manila files reside in the .\Workspace\_lua folder and may be change with a text editor such as Notepad2.
Once the Manila file has been fixed, initiate the the LUA Comparison (luatool.exe) tool to validate that the changes made to the file are correct.
The LUA Comparison process will compare the changes made to the decompiled Manila file against the original Manila file. If successful, the Manila file will be moved from the .\Incomplete or .\Error folder to the
.\Completed folder.
The following procedure will initiate the comparison process.
► To initiate Manila file comparison
At the prompt, type the following command: manilatool.cmd -cmp
Press ENTER.
Mode9 Editing (Mode 9, Graphics, PNG)
M9Editor is a tool for editing Manila files; nearly all aspects of a Mode9 LUA file can be viewed, changed, and saved. Mode 9 LUA Manila files are stored in the .\Workspace\Mode 9 folder and are changed with from within the M9Editor.
Additionally, the M9Editor tool provides graphics import/export capabilities as well as Chainfire File Compression (CFC) support. Lastly, the M9Editor tool includes a folder (directory) viewer which displays information specific to Manila files.
Although it is possible to decompile Manila files with the M9Editor tool, the current version (3.0.03) utilizes a deprecated version of the LUA Decompiler (luadec.exe) which is not supported by this Manila Kitchen.
► To initiate the M9Editor tool
Navigate to the Manila Kitchen folder.
Double-click the M9Editor shortcut.
General Editing (InternetPortal, Manilapages, QTC, PNG, SQLite, TTF, XML)
Some of the Manila files found in the .\Workspace folder may also be changed by other tools such as Notepad2 and CFC_GUI.
► To use an other tool to edit certain Manila files
Launch the desired tool (ex: Notepad2, CFC_GUI, etc.)
Select the Open file option from within the tool.
Navigate to the .\Workspace folder.
Select the Manila file to change.
Updating 'm9editor.names.txt'
From time to time, HTC adds new Manila files or updates the names of existing ones. To update the M9Editor Reference Index file, initiate the Manila name scan process using the MANILATOOL command script. The Manila Name Finder (mnf.exe) tool will iterate through the HTC Manila OEM files found in the .\_SOURCE folder and obtain the new names.
Updating the m9editor.names.txt reference index file ensures that the M9Editor tool is able to display the friendly Manila file name making it easier to work with Manila files - instead of the compiled Hash name used by HTC. Currently, there are two versions of Manila reference index names; one for pre-Manila 2.5 and one for post-Manila 2.5.
The Manila name scan process supports the following Manila versions: 2.5, 2.2, 2.1, 2.0, 1.3, 1.2, 1.1, and 1.0. Specifying a Manila version other than 2.5 will initiate the Manila Name Finder (mnf.exe) tool in pre-Manila 2.5 scan mode. The MANILATOOL command script determines which scan mode to use by first querying the 'kitchen-ver' file - if the value is 0.0; the mode specified in the command parameter is utilized.
Use one of the following procedures to initiate the appropriate M9Editor reference index update process.
► To initiate a pre-Manila 2.5 reference index update
At the prompt, type the following command: manilatool.cmd -mnf:2.1
Press ENTER.
► To initiate a Manila 2.5 reference index update
At the prompt, type the following command: manilatool.cmd -mnf:2.5
Press ENTER.
Updating the Repository
Updating the .\Repository folder ensures that a recent backup copy is available in the event that a change to *.lua must be reversed. During the repository update, decompiled *.lua files found in the .\Workspace\_lua folder are copied to the .\Repository\_lua and a hierarchy (by unhashed names) is created in the .\Repository\windows folder.
The .\Repository\windows folder hierachy displays shortcut links to the Manila files that correspond to a Manila feature. For example, navigate the hierarchy and double-click the shortcut link that corresponds to the file that requires modification - the appropriate tool will be launched.
The following procedure will initiate the repository update process.
► To initiate a repository update
At the prompt, type the following command: manilatool.cmd -lib
Press ENTER.

Frequently Asked Questions (FAQ)
What types of files can be placed in the '.\_SOURCE' folder?
Any type of file may be placed in the .\_SOURCE folder. The MANILATOOL command script will only copy files that contain the word "manila" in them to the .\_queue folder.
I accidentally specified the wrong version of Manila files during the kitchen initialization; is there a way to change it without initializing the kitchen again?
The default Manila file version is stored in the kitchen-ver file. Use a standard text editor such as Notepad2 to edit file. The file must contain a three characters equivalent to the version - valid versions are: 2.5, 2.2, 2.1, 2.0, 1.3, 1.2, 1.1, 1.0, and 0.0 (Unknown/Custom)
What is the '._BACKUP' folder used for?
Before most operations occur, a backup of files that will be changed or removed from/in a given folder is performed. This ensures that previous functional files remain available in the event that a "rollback" is required.
What is the difference between the "Incomplete", "Error", and "Completed" (successful) LUA folders?
Manila files that are successfully decompiled are will appear in the "completed" folder - 100% comparison result. Manila files that are decompiled but do not pass the comparison validation (less than 100%) are placed in the "incomplete" folder. Manila files that report a 0% decompilation result are placed in the "error" folder.
What is the difference between the files in the '.\Release\_lua', '.\Release\_error', '.\Release\CAB', and '.\Release\DEVICE' folders?
The .\Release_error folder will only appear when unexpected errors were encountered during Manila LUA file recompilation. The folder will contain logs detailing the problem that was encountered with a Manila LUA file. The folder is removed and recreated at each recompilation.
The .\Release\_lua folder contains the recompiled versions of the Manila LUA files that are found in the .\Workspace\_lua folder. These are the files can be distributed directly to a device or via CAB file.
The .\Release\CAB folder contains the recompiled versions of the files found in the .\Release\_lua folder. These are the files can be installed via ActiveSync or a Storage Card.
The .\Release\DEVICE folder contains the recompiled versions of the files found in the .\Release\_lua folder. These are the files can be installed via ActiveSync or a Storage Card.
What is the difference between the files in the '.\Processed', '.\Workspace', and '.\Repository' folders?
The .\Processed folder contains the HTC OEM Manila files that were copied to the .\_queue during the Manila Kitchen initialization process. During the decompilation process, the files are moved from the .\_queue folder to the appropriate folder - which is determined by the LUA Comparison tool results.
The .\Workspace\_lua folder contains decompiled versions of the HTC OEM Manila files - these are the files that are typically modified and recompiled. The remainder of the folders in the .\Workspace folder contain various non-LUA files.
The .\Repository\_lua folder contains a duplicate copy of the decompiled Manila files. The repository serves a form of backup.
What are the extra .TXT files that appear in the partially decompiled LUA script folders?
The *.error.txt file contains the STDOUT error that was generated by the LUA Decompiler. When this file appears, there is a logical error in there script, which makes it impossible to run the script. The file will usually contain the approximate (line number) location where the problem was encountered.
The *.log.txt file contains the compared disassembly output from the orignal Manila file and the decompiled LUA version - which appears in the folder. When this file appears, it is an indication that the script will function but it does not match the original Manila file.
The *.dis.txt file contains the raw (full) disassembly of the original Manila file and may be used to resolve the decompilation issue.
The *.status.txt file contains the decompilation result - 0% to 100%.
Visit the following website to obtain more information in troubleshooting a failed decompilation:
http://winmo.sztupy.hu
Is the disassembly output always correct?
Yes. Even though the some of the events may be not be displayed in the disassembly output, the correct sequence of events will be provided.
The M9Editor tool provides a built-in decompiler, why not just use that?
The internal LUA Decompiler (luadec.exe) provided with the M9Editor tool is an earlier version. This internal version does not provide the extra files required to resolved decompilation errors.
The M9Editor should be used when editing Mode9 files and attach extracted embedded LUA script back to their original Mode9 files.
There are strange errors such as '.\documents and settings\<profilename>\eee' errors, what is the solution? (Only in older versions)
One of the Manila Kitchen tools is in an unknown state or temporary files are locked and cannot be freed. Note the path location of the .\eee folder, restart the workstation, and manually delete the folder, sub-folders, and files.
An error message is displayed when attempting to delete a file or folder, what is the solution?
A running process is preventing the file or folder from being removed. Restart the workstation and manually delete the file or folder.
Can Error Reporting be disabled so as to not have to click the Close button every time the LUA Decompiler and/or LUA Comparison tool generate an application error?(Only in older versions)
As previously noted, some Manila files cause the LUA Decompiler (luadec.exe) and/or LUA Comparison (compare.exe) tool to generate an application error. Visit the following website(s) for more information on how to suppress the Error Reporting message box.
Windows XP
http://www.windowsnetworking.com/articles_tutorials/Disable-Error-Reporting-Windows-XP-Server-2003.html
Windows Vista/Seven
http://thehiddenguide.com/how-to-disable-error-reporting-in-windows-vista

Recompiling Manila OEM Files
Once editing is complete, the Manila files must be recompiled before they may be used on a mobile device.
Should an error be encountered during recompilation, the MANILATOOL command script will create a Manila LUA error log file in the .\Release\_error folder and continue recompiling Manila LUA files. In the event of a "hard" recompilation error, the contents of .\Release\_lua folder will be removed and the previous successful recompilation will be restored.
Recompilation
The recompilation process occurs on files that found in the .\Workspace\_lua\Completed folder. Once completed, the files are ready for deployment to a mobile device that is directly connected to a workstation or via an installer .CAB file.
The following procedure will initiate the recompilation process.
► To initiate Manila file recompilation
At the prompt, type the following command: manilatool.cmd -rec
Press ENTER.

Testing the Manila OEM File Changes
The Manila Kitchen environment provides additional tools for testing a final work product. Manila files can be distributed to mobile devices using one of the following methods:
Installed .CAB
Direct to Device
The quickest method of distributing recompiled Manila files is via an installer .CAB file. The direct to device method of distributing recompiled Manila files is via ActiveSync over a USB/Serial connection - this method is
quickest during development activities.
Installer .CAB Method
The MANILATOOL command script provides a parameter to automatically create a redistributable .CAB file. The installer .CAB can be copied to the mobile device and launched using the device File Explorer. Alternatively, the installer .CAB file may be installed via ActiveSync. Should an installer .CAB fail to install on a device, it is likely that policy restrictions are in effect.
The following procedure will initiate the .CAB creation process.
► To initiate the CAB Wizard tool
At the prompt, type the following command: manilatool.cmd -cab
Press ENTER.
Direct to Device Method
The MANILATOOL command script includes a parameter to automatically stop the mobile device Manila executable (manila.exe), transfer a copy of the Manila files, and restart the mobile device Manila executable.
The copy operation may fail on a device where policy restrictions are in effect. Additionally, the Manila executable may not restart in such cases.
The following procedure will initiate the comparison process.
► To initiate RAPI Copy tool
At the prompt, type the following command: manilatool.cmd -dep
Press ENTER.

Reference Web Links
Manila 3D Kitchen
http://winmo.sztupy.hu/manilakitchen.html
http://forum.xda-developers.com/showthread.php?t=487331
Manila Tutorial
http://forum.xda-developers.com/showthread.php?t=399212
LUA Decompiler
http://forum.xda-developers.com/showthread.php?t=568281
LUA 5.1 Decompiler
http://winmo.sztupy.hu/luadec.html
http://forum.xda-developers.com/member.php?u=1433290
http://forum.xda-developers.com/showthread.php?t=479910
LUA Decompiling Tutorial
http://winmo.sztupy.hu
http://winmo.sztupy.hu/manilakitchen/rhodium2_manila_wvga_src.zip
TF3D Manila Mode9 Editor
http://forum.xda-developers.com/showthread.php?t=464984
MNF - Manila Name Finder
http://forum.xda-developers.com/showthread.php?t=546820
CFC - The Manila/TF3D Image Editor
http://forum.xda-developers.com/showthread.php?t=437777
TouchFLO/Manila/SenseUI
http://forum.xda-developers.com/group.php?groupid=131
Co0kie's Beta Testing and Development
http://forum.xda-developers.com/group.php?groupid=192
Max Sense Testers
http://forum.xda-developers.com/group.php?groupid=185
GT7 Sense 2.1 Theme Beta Testers
http://forum.xda-developers.com/group.php?groupid=202
Leaked Full EXT/Manila 2.5 Packages-latest official sprint tp2
http://forum.xda-developers.com/showthread.php?t=642817

Enabling the Logging Debugger
Although a significant of amount effort has gone into the development of the Manila Kitchen, it is possible that a script logic error may occur. To assist in troubleshooting such errors, the MANILATOOL command script includes a comprehensive logging debugger.
The logging debugger can provide basic, expanded, or verbose (full) logging. To enable the logging debugger, append -DEB:[1-5] to the end of the MANILATOOL command script. For example, to set the logging debugger level to 1, type the following command at the Command Prompt:
manilatool.cmd -hlp -deb:1
Processing activities are displayed in the Command Prompt window and are recorded in the ManilaTool_Log_#.##.##.txt file. The log file will include the version of MANILATOOL command script and the command parameters that was requested. The following logging debugger levels are available:
Level 0: Default. The MANILATOOL command script typically operates at this level.
Level 1: Provides slightly more details on the script processing activities. Specifiy this logging level to view the results of actions performed on a Manila file.
Level 2: Provides comprehensive details on the processing activities performed on a Manila file. Specify this logging level when trying to determine why a Manila file may have failed to be processed. Choosing this logging level on a large number of Manila files will increase the time it takes to complete Manila file processing.
Level 3: Developer verbose level 1. Specify this logging level to view the script routine names that are invoked during operation as well as the variables that are dynamically set. Choosing this logging level on a large number of Manila files will greatly increase the time it takes to complete Manila file processing.
Level 4: Developer verbose level 2. Specify this logging level to view the script routine names that are invoked during operation as well as the dynamic and common variables that are set. Choosing this logging level on a large number of Manila files will drastically increase the time it takes to complete Manila file processing.
Level 5: Developer verbose level 3. Specify this logging level to view the script routine names that are invoked during operation, display all script variables. Additionally, this logging level will create a .\_debug folder which will contain a copy of the files that are normally removed during a script routine operation. Choosing this logging level on a large number of Manila files will significantly increase the time it takes to complete Manila file processing.
The following log files are generated during MANILATOOL command script processing:
ManilaTool_Log_#.##.##.txt
ManilaTool_FileCopyLog_#.##.##.txt
ManilaTool_LUAFilesLog_#.##.##.txt
ManilaTool_MNFLog_#.##.##.txt
ManilaTool_Mode9Log_#.##.##.txt
ManilaTool_NonLUAFilesLog_#.##.##.txt

Very nice work as always 12

Very nice work on this, I am around now, So I can start to help out more, haha

Forgive me for being an utter dumbass.
I've got your kitchen and was trying it out. However, what files do I need to drop into folder 01_manila? I've tried dropping just the manila file into it, the extracted *.luac scripts but I keep getting errors saying no files found.
Kindly point me in the right direction?
Thanks.
KF

kinnyfaifai said:
Forgive me for being an utter dumbass.
I've got your kitchen and was trying it out. However, what files do I need to drop into folder 01_manila? I've tried dropping just the manila file into it, the extracted *.luac scripts but I keep getting errors saying no files found.
Kindly point me in the right direction?
Thanks.
KF
Click to expand...
Click to collapse
Yes sure, That's the reason I included the m9editor as well, for it's abilty todifferentiate between different kinds of manila files. Copy only the Lua files (unchanged) to the 01_manila folder. There is a checkbox in the m9editor and if you will check it, it allows copying of multiple files. After that you are good to go and you can run the 01_Decompile.bat, 12

12aon said:
That's whats up!
@MRFERRARI23
What I think that going wrong with you is that your files are not called xxxxxxxx_manila make sure they are name that way or the cab creation script won't recognize them.
One other thing I noticed is that the path to the kitchen contains names with spaces like "mr vizziato". This can throw the kitchen off. To test this put the kitchen directly in you C:\ folder or in any rate not in the folder with spaces in in their names, and check back with me, 12
Click to expand...
Click to collapse
the 2 files I have in there now just look like this 18c01b6d_manila and 72ac571f_manila so I think they are in there right
as for running the program im doing so right from my desktop screen cause when I try to run it from c drive an I go to name the cab It doesnt give me that black pop screen it goes to this white page with info that doesnt allow me to do anything!
EDIT: how do I eliminate that space between mr vizziato?? I cleared the space by going to the start menu an going to my name but idk still nothing

12aon, Please, help me. I can`t decompilled file from manila 2.1 "53cc1e4f_manila",
if you can do this - help me please.
View attachment 53cc1e4f_manila.zip

Hey man, I am currently on a trip in the USA and I do not have the means to help you decompile at the moment. If you want it decompiled right away you can check out stupy's threads and tutorials (I have links in my first post) but I warn you this is kinda hard, good luck, 12

12aon said:
Hey man, I am currently on a trip in the USA and I do not have the means to help you decompile at the moment. If you want it decompiled right away you can check out stupy's threads and tutorials (I have links in my first post) but I warn you this is kinda hard, good luck, 12
Click to expand...
Click to collapse
Ok, I will wait )))), and when you will be able to do this?

Thanks, really useful that you did!

Man, this is seriously awesome
Extremely helpful tool, thank you very much

built in htc [FM TRANSMITTER] dev needed.

this is an older tutorial i found for the evo way back. it needs to be updated..
this could possibly work on other android htc phones to that have the fm transmit capability....
the evos Broadcom chip has a built in fm receiver and also a transmitter.
according to some threads and diagrams ive seen the transmitter does have a power source, it just doesnt have and software code to actually work.
like hdmi the hardware was there but there was no code set up, therefore we didnt have full hdmi out. it had to be built from scratch.
the hardware for the fm transmitter is there we just need some one to build the code for it.
some one please take this on!!
This tutorial was originally posted in > android development and hacking > android software development.
i am reposting it here in the evo forums for guidelines
its a nice tutorial but its old. i think it was for android 2.0 ive followed the tutorial but i couldnt get it working, and i by no means have the experience to switch things up and get it working.
[TUTORIAL] Reverse engineering HTC FM Radio for noobs (on EVO 4G)
Okay, I'm writing this because I want to help any other newbies trying to learn how to reverse engineer. The technical details involved in this are extremely daunting, so the purpose of this tutorial is to first explain in layman terms exactly what you're trying to accomplish and what to expect. Then we'll go over the details. That way you're not completely blind going into this. I'm fairly new to the scene, so I'm not as knowledgeable as everyone else. If you see any errors in my post, let me know so I can change. I'm going to assume you know a little bit of Java, can find your way around a computer, and know nothing about Android. The techniques used should work with other Android phones. For this tutorial I'm using Windows 7, Cygwin, and my stock (not rooted) EVO 4G mobile phone.
The FM tuner for the Evo is run by a Broadcom chip: BCM4329. This chip is pretty amazing in that it does wireless, bluetooth, and it has an FM receiver/transmitter. We're interested in the FM receiver / transmitter.
Now, all android phones are based on a Linux kernel. Basically they're Linux running computers. The Android operating system is then installed onto the linux system. Every app is then run off of Android.
Android is based on Java but it is not a Java system. It uses a virtual machine called Dalvik. Google did this to get around licensing issues with Sun Microsystems. So they pretty much invented their own machine language (called byte code) for the Java language. This makes things complicated for the reverse engineer because from what I've read, once Java is converted into this machine language or byte code, it can't be converted back.
So let's rehash.
If you were programming strictly in Java, you would see these extensions:
Java source code = .java
Compiled Java source code = Java byte code = .class
Compressed file to package your program = .jar (Java Archive)
But since you're programming in Android and Dalvik, you will see these:
Java source code = .java
Compiled Java source code = Dalvik byte code = .dex
Compressed file to package your program = .apk
(I haven't mentioned this, but HTC further Optimizes their .dex code)
Optimized Dalvik byte code = .odex
I'm writing all of these down because it's very easy to get confused with all of the extensions. (for me at least!). remember how I said once you go dex, you can't go back to java? That's where JesusFreke comes in. He's a senior member of XDA, and he created "baksmali" and "smali", two programs that can convert the Dalvik code back into a human readable format. These files have extensions of .smali
Decompiled Dalvik byte code = .smali
But what can you do with .smali files? That's where this other senior member, brut.all comes in: He developed apktool. apktool takes JesusFreke's work to the next level. This program in conjunction with NetBeans, actually lets you trace through any program using the .smali code taken from JesusFreke's programs!
apktool does this by converting those .smali files into "fake" .java files that can be used by the NetBeans (program that compiles and makes java programs) IDE. I say "fake" because apktool embeds the .smali code into java files as comments. However, once you attach a debugger to NetBeans, you'll see that the debugger will follow line by line every execution statement found in the smali code!
So...... you can take the program you want, plug it into Net Beans using a debugger (using the default ddms command provided by Android SDK), and you can trace everything you do in the program. I have it connected to my phone, so whenever I push a button while running my HTC FMRadio app or unplug my headphones,I see the corresponding response to the HTCFMRadio code I have loaded in NetBeans. I can now see in real-time how the program operates from my own interactions... JAM.
Technical Aspects: How to get from ground zero to tracing HTCFMRadio?
1.) Download Android SDK - Go to google development site and follow instructions: Make sure to download the latest Java JDK. Once that is installed, download NetBeans 6.8. Unfortunately, smali debugging does not work with the lastest versions of NetBeans.
Download the "Java SE" version for minimal space
http://netbeans.org/downloads/6.8/index.html
You can follow the rest of Google walkthrough and download Eclipse and ADT plugin, but it's not pertinent to this. You're going to be using adb and ddms from the android SDK extensively, so make sure the path for </android SDK/tools> is included in the PATH variable in your ENVIRONMENT SETTINGS. To get here, right click My computer, click properties, Advanced Settings, ENVIRONMENT SETTINGS.
2.) Search for 7z and download it. It is an awesome and free compression tool that will be extremely useful. It can be used to "unzip" .jar, .apk, and other compressed formats.
3.) Get the Radio app. You can do this by going to "shipped-roms" website, downloading the latest Supersonic image, and following the directions in the unlockr tutorial for HTC kitchens at the unlockr website... (once you have extracted the files from the image, you can look in the system/app and system/framework directories to get the files listed below) or:
you can pull the following files from your phone:
Using the command prompt type (and with phone plugged in, and with USB debugging enabled on phone):
adb pull /system/app/HtcFMRadio.odex
adb pull /system/app/HtcFMRadio.apk
adb pull /system/framework ./framework
This will put HtcFMRadio.odex and HtcFMRadio.apk in the current directory and create a framework directory with more files. A couple of the files in the framework are needed for the HtcFMRadio app, but for simplicity, we're just going to pull the whole directory.
Now that we have the files, we have to make a few changes to make the app installable and to be viewable by the debugger. To do this we have to decompile the .odex format into a human readable format we can edit. That brings us to:
3.) Download baksmali and smali from Project Hosting on Google Code (google search smali).
Usually an Android application is made up of one file, an apk file. Inside the apk file is an AndroidManifest.xml file, a classes.dex file (compiled Java code for the program), and other folders. The other folders contain either graphics or other .xml files that tell the program how it should look to the user. We don't have to worry about those for now. This is important because APKTOOL only opens programs set up this way. But wait up? We didn't download one .apk file, we downloaded an .apk file and an .odex file! What gives? Well, if you right click the apk file and open it (using 7z), you'll see that it's missing the classes.dex file. The dex file for the app is actually the HtcFMRadio.odex file we downloaded. So, to make this system app more like a nominal app, we have to find a way to convert the HtcFMRadio.odex to a classes.dex file. That's easy with baksmali and smali!
Once you download goto command prompt and type:
java -jar baksmali-<version>.jar -d framework -x HtcFMRadio.odex
(Remember to match baksmali-<version>.jar with the filename of baksmali you downloaded)
If done correctly, you should see a newly created \out directory
This creates an out\com\htc\fm directory with many .smali files.
Now let's reverse the process and put it back as a dex file. Type at command prompt:
java -jar smali-<version>.jar out -o classes.dex
If done correctly you'll see a newly created classes.dex.
now, right click on HtcFMRadio.apk (select 7z and open). Drag classes.dex into the file. Say yes to the prompt. Now you have a normal apk file APKTOOL can read!
4.) Download APKTOOL from Project Hosting on Google Code and the helper apps for your OS. (If you're extracting files for windows OS you should have apktool.bat and aapt.exe). Extract (again using 7z, don't you love this program?) apktool.jar (keep it as a jar file, don't extract the stuff inside of it), apktool.bat, and aapt.exe to the directory you're working on. To make things neat, you can also delete HtcFMRadio.odex (you don't need it anymore) and classes.dex (make sure you put it in the HtcFMRadio.apk file first!)
If this is the first time you're using apktool, then you have to install the htc framework so apktool can baksmali the Radio app. You only have to do this once:
apktool if ./framework/com.htc.resources.apk
Alright, at the command prompt:
apktool d -d HtcFMRadio.apk
This extracts the contents of HtcFMRadio.apk and places them in the HtcFMRadio directory. However, there are two major differences between this content and the content created in step 3. If you go into the smali directory you'll see that instead of .smali files, you'll see .java files. And if you go back and edit the AndroidManifest.xml file, you will also see that it's in text! Android applications convert their xml files to binary format. Now that APKTOOL has converted everything to an IDE friendly format, we can use NetBeans to edit everything. The first thing we're going to do is edit AndroidManifest.xml (using notepad) and add the following:
android:debuggable="true" to the Application tag.
IT should now look like this:
<application android:theme="@android:style/Theme.Black.NoTitleBar" android:label="@string/fm_app_name" android:icon="@drawable/fm_radio" android:taskAffinity="android.task.fmradio" android:description="@string/htc_corp" android:allowTaskReparenting="true" android:debuggable="true">
This permission lets the debugger watch the program while it's running on the phone.
We are going to run into two problems if we try to install this program. One is that Android doesn't let you install more than one copy of a system app. The second issue is that if we change the signature of our system app, then we'll have to change the signatures of our other system apps as well! Ahh.... So, to get around that, we're going to trick Android into thinking we have a completely new program. We're going to do that by renaming the com.htc.fm class to com.htc.modradio class. Next step:
5.) Cygwin (or Linux virtual machine)
The easiest way that I can think of to replace strings in multiple files is by using linux. You can most definitely do it in WIndows, but I dont know how. If you let me know how, I can put it in this tutorial.
(update: you can use Notepad++ to easily find/replace strings in multiple files for Windows. You still, however, want to download Cygwin if you're going to develop with Android-NDK.)
For now, just search for Cygwin (Cygwin is a program that lets you run Linux commands from a command prompt using your Windows directories), and install it. Make sure to have the Perl option selected. You'll need Perl to make the following commands work.
Once you get Cygwin up and running
cd <to your HtcFMRadio directory>
in my case it's
cd /cygdrive/c/Users/Jerry/Desktop/HtcFMRadio
now type the following commands in this order:
this command changes all occurances of htc/fm to htc/modradio in your xml and .java files.
find ./ -type f | xargs perl -pi -e 's/htc\/fm/htc\/modradio/g'
this command changes all occurances of htc.fm to htc.modradio
find ./ -type f | xargs perl -pi -e 's/htc.fm/htc.modradio/g'
If you don't follow this order, your source code will get messed up.
If using cygwin, a bunch of .bak files will be created. Using windows search, find all .bak files in your HtcFMRadio directory, then select them all and delete them (Make sure they are only files with .bak!)
Now just rename the fm directory to modradio. It is located in HtcFMRadio/smali/com/htc
Now go to your windows command prompt and type:
apktool b -d .\HtcFMRadio modradio.apk
Now sign and install modradio.apk on your phone.
adb install modradio.apk
If you have never signed before, then you need to use keytool and jarsigner. These two files are in your JDK directory, so make sure you include your JDK directory in the PATH variable of your ENVIRONMENT SETTINGS. (To get here, right click on My Computer, click Properties, Advanced Settings, Environment Variables. Once you make change, open up a new COMMAND prompt to see changes).
cd to the directory which has modradio.apk
now type:
keytool -genkeypair
Answer all questions, then use the same password for all password prompts.
Next type:
jarsigner -verbose modradio.apk mykey
Type in the password you created in the above step. Your apk should now be signed.
Next install:
adb install modradio.apk
Success!
6.) Testing the app on phone
Go to your phone and you'll now see a new FMRadio icon next to your first. Click on it and watch it open. It should now be able to play music. Keep it open.
7.) Using Netbeans
Go into HtcFMRadio and delete the build directory created by APKTOOL.
Now open up Net Beans and click on File, New Project, Select Java Project with Existing Sources, click on Next
Select HtcFMRadio directory for Project Folder, rename Project Name to whatever you want. Let's type in ModRadio. click on Next
Next to "Source Package Folders" click on "Add Folder" and select the smali directory.
Click Finish. For a quick tutorial by Brut.all, search APKTOOL in youtube and click on: Apktool Demo 2 - Smali improvements
Right click on Libraries. Click on "Add Jar / Folder". You want to add Android.Jar. Since I have Android 2.1 loaded I went to /platforms/android-7 located in my android SDK directory.
Your project is now ready for editting!
8.) Running the Debugger to trace through program.
Next go back to Windows command prompt and type ddms. This runs the Dalvik Debug Monitor. A window should open up. In the left hand side you should see com.htc.modradio. That's our app! To the right you're going to see 2 numbers, you're interested in the one to the right, 4 cells away from com.htc.modradio. This number is a port number, and you're going to use it to communicate with NetBeans. (In my case it is 8603)
Go back to NetBeans and click on Debug, Attach Debugger.
In the host field type: localhost
In the Port field: type in the second number you saw. (8603)
If everything is working you'll see a bug appear next to com.htc.modradio in the Dalvik Debug Monitor. Look at the bottom bar of NetBeans for feedback. If you get errors make sure the numbers match, or try port 8700 and make sure you select com.htc.modradio in the Dalvik Debug Monitor. Port 8700 is the default port used for whatever program you select in Dalvik Debug Monitor.
9.) Setting a breakpoint
I'm making this a seperate step because it is completely arbitrary. When creating a break point be sure to follow this rule:
You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#".
Rather than looking for a spot to breakpoint, though, I'll tell you where to put one so you can quickly see how the debugger traces through the code. You aren't "REQUIRED" to do the next step, but if you want to trace you have to put a breakpoint somewhere.
In Net Beans click on the Project tab, click on Source Packages, com.htc.modradio, and then doubleclick on BroadcomFMTuner.java
We're going to insert a breakpoint. Scroll down to line 3226 and on your keyboard press: CTRL-SHIFT-F8, select line in dropdown box and hit ok. (To keep it simple, I usually look for "invoke" instructions to set breakpoints at)
Now go to your phone and click on the physical "back" button on your phone. This will clear the radio,(you should still be able to listen to music). Drag your status bar down. You should see a radio icon. Click on it again. The radio backgroudn will appear, but you wont' see any text or anything. Now go back to your netbeans application. You should now see debug options highlighted! Click on Step Over (F8) to step through!
{
"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"
}
i found a few things.
http://pdf.eccn.com/pdfs/Datasheets/Broadcom/BCM4329.pdf
http://www.broadcom.com/products/Bluetooth/Bluetooth-RF-Silicon-and-Software-Solutions/BCM4329

Mad tutorial man! You have just opened up my world even more to Android. Thank you heaps.
BTW your freakin signature got me good damn you! I thought someone had hacked my PC LOL

Any chance that this will work with JB?. Can you post app?. Thanks.

How To Set Up an IDE to Develop to the Nook Touch on Windows

Setting up a development environment is really not that hard. I am using Windows 7 with a 64-bit processor, although the procedure is not terribly different across sytems, just make sure you choose the right download for your architecture.
The entire process can be broken down into four major steps. Let's get started.
1) Get Java
You can get the Java Standard Edition Software Development Kit through this link: http://www.oracle.com/technetwork/java/javase/downloads/
At the time of writing this post, the latest version available is 7u3. Click the download button under where it says 'JDK' and you will be taken to a list of installers. Make sure you get an installer from the group who's header is "Java SE Development Kit 7u3"; the other one is just sample code.
Make doubly sure that you choose the right architecture (x86 vs x64) as the wrong one will give you an error message and you will have to go uninstall everything and start over.
After the download has finished, run the installer.
Note: It may give the option to install JavaFX and the Ask Toolbar. While they won't hinder your development in any way, there won't be any need for them within the scope of this guide so you might find it worthwhile to not install them.
2) Get Eclipse
Once you've installed the Java DK, go get a copy of the Eclipse IDE here:
http://www.eclipse.org/downloads/ You can see that the IDE comes in many different flavors. Eclipse Classic will work fine.
Extract the folder and place the 'eclipse' subdirectory in a safe place. Try running eclipse by traversing this directory and running eclipse.exe. If you see the Eclipse splashscreen, everything is OK. If you see an error message then something may have gone wrong when you installed Java. If it complains about missing or corrupted DLLs, you probably have installed the wrong version of Java for your system. If it complains about not being able to find Java (for example, stuff about javaw.exe) you may need to manually add Java's location to your Path environmental variable. There is lots of documentation on how to do throughout the internet and most can probably explain it better than me. (^; Another method to fix the problem is to go find out where all the Java binaries are (Normally something like "C:\Program Files\Java\jdk~~~~~~~\bin"), copy the directory path, and add
Code:
-vm
<FOLDERPATH>\javaw.exe
to the end of the 'eclipse.ini' file that resides alongside 'eclipse.exe'
Note: You may notice that the version of Eclipse you downloaded isn't installed, but instead just runs out of a folder. You may want to consider creating a binaries folder in your home directory to keep all of software of this style in one place.
3) Get Android Plugins for Eclipse
Now that you have Eclipse up an running, you need to set it up for Android development. Start Eclipse up and click the 'Help' menu. Click 'Install New Software...'
In the window that comes up, you should see a combo box labelled 'Work with:' . Paste in:
Code:
https://dl-ssl.google.com/android/eclipse/
then hit enter.
Check 'Developer Tools' and click next. Let Eclipse do it's thing then click 'Finish'.
4) Get the API
Now that you have Eclipse's Android integration plugins, you need to grab an Android API. In Eclipse, under the 'Window' menu, click 'Android SDK Manager.'
The window that opens will automatically go to the internet and grab all the API packages available to download. The Nook Touch currently runs Android 2.1, so find that package set and check it. Click the 'Install <x> Packages' button and let it run.
You are finished! Now to create an Android program. In Eclipse's main menu, navigate File > New > Other... and select 'Android Project' from the 'Android' folder in the window. If you want to modify the source of an existing program, choose the appropriate radio button and browse to the parent directory of the 'src' folder. After you have created your project, you are going to want to make sure it has the right dependencies. On the lefthand pane ('Package Explorer') right click your project folder (The top one) and hit 'Properties.' Under the 'Android' screen, make sure 'Android 2.1' is checked and not another version. Click OK and you should be set.
To generate an APK, under 'File' click 'Export.' In 'Android' click 'Export Android Application.' Choose the right project, click next. If this is the first time you've exported an Android application, you will need to create a keystore. Select the appropriate radio button, navigate to a safe location, and give it your keystore a password. Click 'next' and add all the information you see fit. You will be able to reuse this keystore in future programs. After you've created a keystore, proceed through the export wizard, give your APK a filename, click finish and the file will be generated.
The rest is up to you. (^:

Thanks klausef!
For a non-dev (OK, I used to program short apps in BASIC on my commodore 64 when I was 8 years old), how much can I hope to achieve by setting this up? Do I need to understand a programming language? If so, which? Do you have any suggestions for a noob like me?

Haha I am no Java expert myself but I've been hacking around with the NoRefresh thing and other apps people have coded. You can do more than you think just by rummaging around online documentation.

ROM Building: The Basics Part III

Welcome back everyone
For those who are not familiar with the series, I recommend checking out part I and then part II to get caught up on our continued efforts to modify a ROM to your every whim and need.
We will be utilizing some really cool tools today. They come at a price of patience and perseverance, you know, kind of like what Valve expects from all of their loyal customers, and the worst part is....they could release the HL3 in 10 years, and I would still throw money at my screen.
I digress again.
Today we learn how to decompile those sneaky APK's and the necessary Framework files. They are located in the 2 most important folders:
MD4_Version_1/system/app
MD4_Version_1/system/framework
We need to start at the beginning of this topic.
To begin, let us test your ability to use JAVA....Wait STOP! Java? Programming? We do not need to be experts at programming at all, in fact, implementing mods is really a copy and paste procedure for us noobs, but if you know how to JAVA, maybe you can create your own mods that you can share with the community. Also, I am not a programmer, but I do know how to use logic to trial and error the crap out of the mods until they work.
To test if you have JAVA installed, open up a command prompt in Windows (because if you have Linux, you are not going to even be on this beginner's tutorial now are you?)
type in:
Code:
java
You should see
Code:
C:\>java
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-server to select the "server" VM
-hotspot is a synonym for the "server" VM [deprecated]
The default VM is server.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
-splash:<imagepath>
show splash screen with specified image
Wait, you did not see this did you? Well it happens, you probably got an Unknown Command or some shenanigans that doesn't look similar to the above?
Do not worry, we will need to add JAVA to the environment variables. First head over to JAVA and download the Java Runtime Environment (JRE). Install as you would by clicking next next next next and next and next.
When it installs, it goes to a specific location. The problem is, sometimes Windows does not recognize that path, which is why when you execute the JAVA command in a command prompt it tells you unknown command. We have to tell Windows to search in the java installation folder that you just installed for the JAVA.exe program so Windows can add it to the list of areas to search when you execute a command.
To do this, we will need to add the path in the environmental variables, java explains that sometimes this should not be necessary. But use this for more information and an understand of how to do this to different operating systems.
My path was the default "PATH" for java
Code:
C:\Program Files (x86)\Java\jre7\bin
Once that has been added to the environmental variables, test out the java code and see if it looks like what I have from above.
After this is done, we will need to install the Android SDK, this can be found here
The SDK, is a software development kit. It will allow for a user to create software for your android phone. This tutorial will not be doing that because that is a very heavy order. It will require the release of the Kraken. I do not recommend releasing the Kraken. Unless it is harmless Cthulhu. He's so adorable.
Anyway, this will install platform tools for us to push files to our phone and allow us to to execute these commands.
Remember, we can add the tools of the SDK to our PATH variable so we can execute these tools in any command prompt and at any location.
If you are having trouble at this point, let me know in the comments below and we can try and address this issue.
Now that we have the basic tools down, we need to understand what the heck that APKTOOL, SMALI and BAKSMALI do.
These tools are used to decompile the our APK and JAR files.
Keep this in mind at all times
APKTOOL will decompile and combile APK FILES
SMALI compiles DEX FILES
BAKSMALI decompiles DEX FILES
Do you know what any of these 3 are? Maybe you do, maybe you don't.
The APK stands for Android application package. It is basically the app. In windows, it would be equivalent to the program. The APK is unique in the sense that all the files in the app are actually zipped inside an APK file.
That logic only deduces, we can open almost any APK file with 7-zip. This is good news until we realize, the APK files are actually encoded in a way. We cannot make serious mods until we de-scramble the code hidden in the APK.
This is where APKTOOL comes into play. The APKTOOL can de-compile the encoded files and put it into a folder for us to work with. We can then make our mods, recompile and then put it into our ROM.
After explaining Smali and Baksmali, we will begin a basic mod.
Smali and Baksmali are actually java archive files. They contain instructions to take a DEX file and de-compile them into very interesting SMALI code. DEX is an EXE file for our Android system. We can only de-compile a classes.dex file for now, for it contains the majority of the rest of the tweaks. As a result, doing this is important and very difficult unless you understand what is going on. We will definitely have examples so do not fret, did I mention a half life reference yet...I don't think so.
So back to APKTOOL, we are going to need to understand what it does before we begin. I am assuming you got your APKTOOL downloaded from here, go to your C: drive and create a folder in there called APKTOOL in there, unzip the downloaded file, there will be a file Setup.bat, execute that file and a command prompt window with Green text will appear, I recommend selection 1 first to ensure you have the latest version, but we do not need to do this.
We will need to press option 2, but it says we must place some files in the other folder first. The files needed are actually the framework files, basically, the way our rom interprets the files are needed for this APKTOOL to operate.We will need to go to our ROM's
MD4_Version_1/system/framework/ folder and copy 2 files
Code:
framework-res.apk
tw-frameworkres.apk
These files will be copied into
Code:
C:\APKTOOL\other
This needs to be done before you select option 2.
Once the files are copied, press 2, then we need to install the first two options, so go one by one and install both.
Then when you are back to the main menu, press 3 and setup the directories for your need.
Personally, I took the
Code:
C:\APKTOOL\other
folder and moved into my own working directory. Assume that the locations will be selected by you for organization. I will use the following folder for reference:
Code:
C:\other
This will have all of the tools I need, while you are at it, create a new folder in their called Smali and copy the Smali.jar and BakSmali.jar files in there, they will of course be named something else like smali-1.4.2.jar and baksmali-1.4.2.jar
Rename the files to make life easier
Code:
from
smali-1.4.2.jar
to
smali.jar
and
baksmali-1.4.2.jar
to
baksmali.jar
Back to APKTOOL, now back to me, Now back to APKTOOL, now back to me.
We will be victimizing a specific APK to get modding started.
Before we get started, this is where we start version controlling more seriously. As each mod you add could cause a freeze, hang, bootloop or whatever, so go to the folder of your ROM, select the four files
META-INF
system
boot.img
installbusybox
right click them and "Add to Archive". Zip file only remember, compression level( Normal to no compression is fine)
Now
Lets grab a copy of SecPhone.APK located in the system/app folder
And put it into
Code:
C:\other
Open a command prompt and navigate to that location of the APKTOOL
Execute the following command
Code:
apktool d SecPhone.apk SecPhone
If done successfully, you will something like
Code:
C:\other>apktool d SecPhone.apk Secphone
I: Baksmaling...
I: Loading resource table...
I: Loaded.
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: C:\Users\<Your User Name>\apktool\framework\1.apk
I: Loaded.
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Done.
I: Copying assets and libs...
C:\other>
This means it successfully decoded the file. We will have a folder called SecPhone that has a bunch of folders.
Navigate to the following folder:
Code:
C:\other\Secphone\res\raw
There are 2 .ogg files. Well well well, I thought we took care of these, hmm, guess we need to change these to whatever you need to. Let's assume you did this already and have replaced them. We will need to stop the "mods" for now, for we are learning a process not a mod per se.
So we are done "modding" the file, I know it is not a BIG mod but we are trying to learn how to do this now so we can do the heavy stuff later. Now we can continue to recompile the file.
Go back to command prompt and direct yourself to
C:\other>
Click to expand...
Click to collapse
The put in the following command:
Code:
C:\other>apktool b SecPhone new-SecPhone.apk
Notice we changed 3 things, the d became a b, the second option is the folder we are recompiling, the third is the name of the new file
You should then see something that might be worrisome:
Code:
I: Checking whether sources has changed...
I: Smaling...
I: Checking whether resources has changed...
I: Building resources...
aapt: warning: string 'reject_cause_location_reg_fail' has no default translatio
n in C:\other\SecPhone\res; found: es pt
aapt: warning: string 'reject_cause_location_registering' has no default transla
tion in C:\other\SecPhone\res; found: es pt
aapt: warning: string 'stms_version' has no default translation in C:\other\SecP
hone\res; found: ja
I: Building apk file...
C:\other>
The warnings will be acceptable for the time being as they are related to a different language setting. If you are in English, you will be fine. If you are not, then that is a different tutorial altogether. Also, there is a very particular code bug that occurred the very first time I ran these commands and caused a catastrophic failure, more than any Movie-to-Game adaptation could ever be,
But you think you are done here, well that is not true. You see,
We have compiled the new APK file but unfortunately, it is a system file, we cannot sign this file to tell Android it is legit, we will have to cheat at this point, just like Valve did by creating any other project except Half Life 3 after number 2, you know they have enough funding for it, they are making it, and if I get kidnapped, I will probably be in a basement at Valve which I won't mind if they give me a grav gun. On a side note, while Brian Cranston would make a great Gordon Freeman, I still think Hugh Laurie would do a good job, just saying.
So back to our dilemma. We have created a new file called new-SecPhone.apk, open it with 7-zip, do not do anything yet, open the SecPhone.apk file you should have, it is the original file in the C:\other folder, we will need to drag two files for signature's sake
Copy the
Code:
Meta-INF Folder
AndroidManifest.xml
directly into the new-SecPhone.apk file. This can be done by dragging the files.
This will allow Android to think the file is signed and legit.
Take the new-SecPhone.apk file and copy it to your desktop and rename it to SecPhone.apk
Then place it into your ROM's system/app folder.
Your "first Mod" is ready to go, pretty easy actually but I really think the method is what many of us lack and this centralizes the effort. When you want to mod any System file, this process has to be done.
Its not a crazy mod, that will be after we explain how to modify files with Smali and BakSmali.
That will be in the next part of this set of series. These keep getting longer, I know, but we have a boat ton to cover. I think a central place to go-to for this information is important instead of jumping around to so many places for information. Eventually, the plan is to stick them as one big post I hope so we can integrate the vast amount of knowledge flowing.
Let me know what you think in the comments below, feedback is important, I felt this is so far the most complicated of the series and it will only get crazier. Luckily we can ask questions and keep this series going with an understanding for ROM building and see how much effort goes into someone else's effort modifying one of these ROM's out there, this is just a stock ROM mod tutorial, imagine something like CyanogenMod or any crazy ROM with a boat ton of features. It is time consuming and they deserve mad props for their amazing work.

Again great stuff. Can't wait for the next tutorial!
Sent from my SPH-L710 using xda app-developers app

bigpappags3 said:
Again great stuff. Can't wait for the next tutorial!
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
He is very informative, and puts it in ways I can understand!
------------------------
Sprint Galaxy S3
Need Help? PM
Hit the "Thanks" button if I helped!

I'm stuck
I've downloaded the APKTOOL zip, and there is no setup.bat file in the unzipped package. There are only two files in the package and nothing else. One is an application called aapt, the other is a batch file called apktool. Both of which when executed briefly open a command prompt window that closes before I can read what they say. I've followed every direction to a "T" thus far, and can't figure out what to do. I thought that perhaps I had a bad download, but I've re-downloaded the file several times without success. Any suggestions would be incredibly helpful.

Might have a solution
balcoresbane said:
I've downloaded the APKTOOL zip, and there is no setup.bat file in the unzipped package. There are only two files in the package and nothing else. One is an application called aapt, the other is a batch file called apktool. Both of which when executed briefly open a command prompt window that closes before I can read what they say. I've followed every direction to a "T" thus far, and can't figure out what to do. I thought that perhaps I had a bad download, but I've re-downloaded the file several times without success. Any suggestions would be incredibly helpful.
Click to expand...
Click to collapse
Well it seems they have changed up quite a few things on the Wiki page, the version I was using was 1.5.2, the package has moved around and it seems these instructions are as obsolete as they are dependent on a website to not change things around.
They still offer the 1.5.2 of course but in the archives, suppose it was my fault linking to a constantly changing website than to link to the files directly that I used which I was considering.
This is the link
https://code.google.com/p/android-apktool/

zalooa said:
Well it seems they have changed up quite a few things on the Wiki page, the version I was using was 1.5.2, the package has moved around and it seems these instructions are as obsolete as they are dependent on a website to not change things around.
They still offer the 1.5.2 of course but in the archives, suppose it was my fault linking to a constantly changing website than to link to the files directly that I used which I was considering.
This is the link
https://code.google.com/p/android-apktool/
Click to expand...
Click to collapse
Thanks @zalooa. I'll give it a go tonight for sure. I appreciate you getting back to me!

[XAP] Any application launcher

There is simple, but usefull tool, able to launch any application, script, or other shell directive, by own tile icon tapping.
Using:
1. Rename UniLaunch7.xap to YourOwnName.zip
2. Edit zipped WMAppManifest.xml file:
- replace all occurences of string "UniLaunch7" by "YourOwnName"
- replace line "\Windows\calc7.exe" by your wanted exe, batch, or Mortscript full filepath (see my other threads about console and Mortscript).
3. If you want, replace ApplicationIcon.png by your own icon picture.
4. Repack zip and rename YourOwnName.zip to YourOwnName.xap
5. Deploy it to device
Notes:
Using batch with LaunUri.exe calling you can simply make any "undocumented" system CPL shortcut as internet sharing (LaunchUri app://5B04B775-356B-4AA0-AAF8-6491FFEA5629/_default), GPS enabling (LaunchUri app://5b04b775-356b-4aa0-aaf8-6491ffea5642/_default) etc. Examples are in attached zip (enable scripting first by HaRET Console 7 or another batch interpreter enabling tool e.g. PocketCMD7 registered to batch as cmd /C CALL "%1"
).
Using batch with registry changing you can make simply native installator or profile changer. For example simple scripts RingingOffVibrateOn.bat, RingingOffVibrateOff.bat and RingingOnVibrateOn.bat is tiled in my device.
You can see differences between UniLaunch7.xap and KeyboardCPL.xap (unzip booth) to understand tutorial. First one launches Calcullator, second launches Keyboard CLP.
I will prepare authomatical on-device launchers creator, probably as feature of Phone Commander.

More information on the benefits and advantages.
Or do explained in video