Database Develop

Cooking a rom...

Hi, I followed the thread: "How to reconstruct a dumped ROM"... (obviously I had, before, did a rom dump!). Now I have a directory named "dump" with several subdirs.
In the step 3) there is written: "After this step you can optionally edit the OS files with the proper tools"... now the question is: what are these proper tools? I searched in the forum, in the other threads but I didn't find anything... My needs are: to delete some programs that are in the rom (for example Pocket Word, Pocket Excel, other..) in order to obtain more space, but to install other tools at the free space.
Thanks in advance for your help....

Great question ! i can't help you , but i wait for answers ....

I asked the same thing the other day, and got an answer(thx again to him).
Actually, I'm doing it right now, as a test I've successfuly dumped and rebuilt lsvw's rom using enhanced imgfs tools batch files, nbdump.bat nbname.nb & nbbuild nbname.nb, now I'm removing files from the rom and maybe add some other, like that quick gps thingy, latest msn(optimized for trinity, removed vga resources), phone pad, and some other thing on my custom extrom.
I had the same doubt as you, but it seems that we're overcomplicating things, you can simply use the file explorer to remove files from that dir, beware of which files you remove/alter.. initflashfiles.dat has some operations to be done after flashing the device(creating folders,renaming files, moving them to startup/start menu/etc folders), I thought that if the file didn't exist on the windows folder, whatever invoques initflashfiles.dat would crash, but it doesn't seem to be the case, I haven't put this to test, but I've found several missing files on the initflashfiles.dat(and a typo, "floder", go figure what it means - lazy/rushed editing IMO), so there seems to be some tolerance to the operations contained in that file.
I won't edit the wiki until I'm 100% sure that what I know is correct, but to sum it up:
dump the files
add/delete files with explorer
edit the registry using rgucomp
edit initflashfiles.dat using the original windows notepad & use an hexeditor to remove the 1st 2 bytes
run NBBuild.bat to create the *.nb file
OSchecker.exe to validate the *.nb file
nbhtool.exe to create the nbh
flash it(I prefer the sd card method)
Code:
rgucomp needs setting _FLATRELEASEDIR environment variable to current directlry like this:
set _FLATRELEASEDIR=.
Dump default.hv/user.hv file to .reg with:
rgucomp.exe -nologo -o default.hv > default.reg, then add line "REGEDIT4" to the beginning of REG file.
Modify the .reg file to your liking, (save it in UTF-16 with CR+LF terminations and a new line at the end of the file) and convert it back to .hv
And don't forget to flash Olipro's Hard SPL before, it may save your device.
"and convert it back to .hv"
http://forum.xda-developers.com/showpost.php?p=1186635&postcount=1
(no wonder I didn't find this info, forum search is almost useless, googled for rgucomp and voilà, first result(above) right answer)

Building your own kitchen (Part 1)

Xplode has created a really great kitchen for us to play with and have made my custom ROM with this kitchen. I think it’s so easy that everyone is now able to create his own ROM.
However, I would like to go a bit further: Instead of just using the kitchen someone has made, I would like to take any of the ROMs (e.g. Helmi_BA_WM2k5_AKU3.5_v1.4.CF2 R2 by baniaczek) and use that as my kitchen starting point.
I’ve been doing a lot of reading on the subject and this is what I’ve figured out so far. It is by no means complete (or maybe even correct), but I can certainly use some help to get further. Below information is not something I found out on my own, but is based on what is mentioned in other postings in different forums and websites and picking apart the batch files I’ve found in several kitchens.
My intention of this posting is to make a simple how-to wiki-page so anyone could create his/her own kitchen and from that kitchen create the best possible ROM for their own use: Add the packages they use and leave out the stuff they don’t need. My plan is not that everyone will start publishing the ROM they have created from a decompiled ROM since there would simply be to many chefs
------------------
Step 1: Convert the nbf file to an nba file.
The ROM file that you load on your phone is always called nk.nbf. However, before you can do anything with this file, you’ll need to convert to to nk.nba. For this you use a tool called “xda3nbftool.exe” (yes, the one you used to set the operator with)
The command to do the conversion is: xda3nbftool.exe -x nk.nbf nk.nba 0x20040521
After a minute or so, you’ll have a file called “nk.nba” that is the same size as the original
Step 2: Brake the nk.nba file into separate files.
The nk.nba file consists of 2 parts and need to be split. To do this split, you’ll use the following command:
prepare_imgfs.exe nk.nba
After the program has run, you’ll have 2 files: “imgfs_removed_data.bin” (0.5 mb) and “imgfs_raw_data.bin” (variable size, but e.g. 27 mb)
Obviously, the part we’re interested in is the bigger file of the 2.
Important remark: For other HTC platforms (like HTC Uni), the above command is executed with an extra parameter “-nosplit”. However, if that parameter is added the output is unusable when performed on the Blue Angel ROM.
Step 3: Extract the modules
Now you have the raw image file, you’ll need to extract it and convert it back into modules.
To do this, you’ll first need to place a file called “recmod.exe” in the directory where the imgfs_raw_data.bin file is. The next step is to run this command:
viewimgfs imgfs_raw_data.bin
This command will create a directory called “dump” and it will extract all the files and many directories in this directory. You can have a look in this directory and will probably recognize a lot of the names if you have been building ROMs on someone’s kitchen.
Step 4: Dividing the modules into SYS and OEM
Before you can do anything with these modules, you’ll first need to convert them to packages. To do this, you’ll need a piece of software called “Package Tool” (from Bepe)
Start the program and select the dump folder via “File\Open”. Once selected, it will give some basic information about the dump directory like OS etc.
Now select Tools\Build Packages, but before you start the command, make sure you have the file map.txt in the same directory as the Package Tools application. That way, many of the GUID numbers will be translated to readable names.
This program will just run a few seconds. After it is complete, you’ll now find a SYS and OEM directory in the dump directory. If everything went well, then there will be just 1 file left: initflashfiles.dat. All other files and directories that were there before are now in the SYS or OEM directory.
However, in the real world…. My experience with several ROMs I’ve tried, the Package Tools program is unable to properly complete the process for a, to me, unknown reason and when it has run, the directory is far from empty. Under the section “[Missing Files]” there is the information about files that are missing.
When you look in this file, you’ll see that all the missing files are not really missing but are directories with the same names and extension of the files that where not placed in the correct sub-directories. All is not lost yet. You can manually move the files to the mentioned directories. Once you have completed this job, you should still end up with a virtually empty dump directory.
There is also a chance, like with fake WM6 ROM on this forum, that after you move all the files that are mentioned in the “missing files”-section but still end up with a long list of files in the dump directory. If that’s the case, then obviously something went wrong. However, at this point, I don’t know why this happens. However, it does look like it’s not a good starting point to build your own ROM with.
Remark: The “Missing files” section may also contain entries like this one:
19a7f28b-6bc7-4fe9-b060-76ae3a65ff72
19a7f28b-6bc7-4fe9-b060-76ae3a65ff72.rgu (File)
This indicates that the RGU file is missing. However, this is not a big problem. Just create an empty file with the name in the mentioned directory. Later on, the BuildOS.exe program will use the empty file to place the correct information in the file.
Step 5: Move the 2 directories
Now you have the correct SYS and OEM files, you’re on you way to start cooking. Move the 2 directories to a different directory. (like how it is in Xplode kitchen for example) and remove the dump directory
------------ Now, I’m at this point and here I’m a bit lost ------
Step 6: Adding and removing
Now you are at the part that was the whole point of the exercise: Adding and removing packages. Adding premade packages is not too difficult: With some luck the packages you want to add can be found in a different kitchen or is otherwise available. (Helmi and others wrote some documents on how to create packages, so refer to those).
Take the packages and place them in the OEM directory.
Taking out packages should be as simple as well: Just move the directories of packages you don’t want to a different directory (you could also just delete them, but you might need them again later). When removing packages, there is of course a big chance that you remove something that is essential for a part of the OS that you are not aware of, so removing bit and pieces is more trail, error and a bit of luck.
(continued on the next post)

Building your own kitchen (Part 2)
(continued from above port)
Step 6a: Changing the registry
After you’ve followed step 1 to 5, you also extracted the default.hv and user.hv and can be found in SYS\Metadata directory. This is the registry that also contain all the bits and pieces of registry files that are in the packages (the .RGU files)
To modify these 2 files, use these commands:
SET _FLATRELEASEDIR=.
rgucomp -o default.hv -nologo > default.txt
rgucomp -o user.hv -nologo > user.txt
Add "REGEDIT4" in the beginning of the files and leave a blank line at the end of the file. Save the file as UTF-16 or Unicode format. (Ultra-Edit is very good editor for this)
After you have made the changes, you will need to covert them back to a format your PPC will understand. Use these commands:
SET _FLATRELEASEDIR=.
copy default.txt boot.rgu
rgucomp -b
ren boot.hv default.hv
copy user.txt boot.rgu
rgucomp -b
ren boot.hv user.hv
---------------
The next steps are basically the reverse from the first 5 steps: After taking the files apart, they now need to be put back into place.
----------------------------------
Step 7: Building the ROM up again.
To start building the ROM now, the first command you execute is BuildOS.exe.
This program will create the dump directory again and will copy the directories and files from SYS and OEM to the directory.
Remark: There are several versions of BuildOS on this forum. Xplode’s kitchen is using a more advanced version where you can easily select the packages you want to be included (instead of moving them in and out the directory). This is a much nicer approach and will make ROM building as simple as installing a regular piece of software on your PC. However, to keep it a bit more simple for this how-to, I’m assuming an older version of BuildOS.exe that will not ask for any user input. (The more advanced version will require you to modify XML files to add packages. It’s not too difficult, but does require a bit more background knowledge)
Step 8: Building the file image system
Now you have all the files and directories that make up the ROM, you’ll need to convert it back into a file image.
For this, you run the program BUILDIMGFS (without any parameters)
Remark: For some reason, but this program is very memory intensive. If you don’t have that much internal memory, or your swap file is too small, this program is never able to completely run. I’ve noticed this problem on more then 1 computer. (I have the source code of this program and tried if I could do something about this. However, the program is heavily relying on a DLL called “cecompr_nt.dll” and I expect that that DLL is the culprit. I’ve been searching for more information on this DLL, but have not found anything on the internet about it)
Important note: If you have added to many modules to your own ROM, the BUILDIMGFS process may crash. So, if this happens, you’ll need to go back to step 6 and remove some of the packages you’ve added. If you go back to step 6, you’ll need to delete the “dump” directory first.
This program will convert the dump directory back in the file “imgfs_raw_data.bin”.
Once the program has run, the file should be something like 27 mb again.
If the program does not crash and runs to completion, there is still a chance that you have added to many packages to your ROM. When the BUILDIMGFS is ready, it will show the number of free sectors at the end of file system image. If it is showing something like ffffef that means that it’s too big, since it should show a small (hexadecimal) number like 1e or something like that.
Since/If you want to add as many packages as possible to the ROM (instead of installing them in RAM) you may need to repeat step 6, 7 and 8 several times. To make your life a bit easier, make a screen shot of the OEM directory and keep track which one worked and which one didn’t). If you go back to step 6, you’ll need to delete the “dump” directory first.
Step 9: Building the nk.nba
To create the nk.nba file again, you need the file you just created in step 8, but also the other file created in step 2: imgfs_removed_data.bin (maybe this file is created by buildimgfs??)
When you have these 2 files in a directory together, run this command:
MAKE_IMGFS nk.nba
Once the program is complete, the nk.nba file should be something 32 mb again.
Important remark: For other HTC platforms (like HTC Uni), the above command is executed with an extra parameter “-nosplit”. However, if that parameter is added the output is unusable when performed on the BA ROM.
Step 10: Convert the nk.nba back into nk.nbf
The final step of the process: creating the file that our BA understands: nk.nbf
This step is into 2 pieces:
A: Update the check-sum of the nk.nha file with this command:
XDA3NBFTOOL -c -u nk.nba
B: Convert the file:
XDA3NBFTOOL -x nk.nba nk.nbf 0x20040521
As you can see, the last parameter is the same as in step 1. This is some sort of password that is needed to encode the file with.
Now, the ROM is complete and you’re ready to flash it on your BA. I assume that you know how to do that part

** Can I use Notepad to edit and save ???
I got error here. When I try to do
To modify these 2 files, use these commands:
SET _FLATRELEASEDIR=.
rgucomp -o default.hv -nologo > default.txt
rgucomp -o user.hv -nologo > user.txt
Add "REGEDIT4" in the beginning of the files and leave a blank line at the end of the file. Save the file as UTF-16 or Unicode format. (Ultra-Edit is very good editor for this)
After you have made the changes, you will need to covert them back to a format your PPC will understand. Use these commands:
SET _FLATRELEASEDIR=.
copy default.txt boot.rgu
rgucomp -b
ren boot.hv default.hv
copy user.txt boot.rgu
rgucomp -b
ren boot.hv user.hv
************************************************************
C:\Scoter Kitchen\Utilities\TOOLS>rgucomp -b
Microsoft (R) RGUComp Version 1.0.000
Registry file processor and hive builder.
Copyright (C) 2004 Microsoft Corporation All Rights Reserved.
built: Nov 19 2004 15:17:13
importing registry file ".\boot.rgu"...
InitRegistry FAILED in file ".\boot.rgu" within a few lines of line 1.
BuildBootHive: (RGUComp) !ERROR failed importing ".\boot.rgu"
wmain: (RGUComp) !ERROR failed building BOOT hive
****************************************************
Now, I got errors on line 3 of default.rgu and line 154 of user.rgu ...
I didn't edit those line at all .. Why errors !!
I put REGEDIT4 in the first line of both default.txt, and user.txt and leave 1 blank line at the end.
I saved it into unicode.

Thank you for the info, will sure to give it a try when I have time later on...

Thank you very much! Will try to localize ROM using OEM Packages.

How to localize WWE ROM to other language?

Immediate help

this is for legal reasons. where exactly are sms messages stored? a lot depends on this!

I don't remember where exactly they are, but I think we have an app that can back them up. Even if you find them though they will be in a weird format

corp769 said:
this is for legal reasons. where exactly are sms messages stored? a lot depends on this!
Click to expand...
Click to collapse
Texts are stored in a database file located here in this directory:
Code:
/data/data/com.android.providers.telephony/databases
the name of the database file you want is called mmssms.db
To get it from your phone enter this code in terminal:
Code:
su
cp /data/data/com.android.providers.telephony/databases/mmssms.db /sdcard
That should copy the file to your sd card then you can mount your sd card and pull the file off to your PC. To read the file, download sqlite studio, install it, add the database and you should be able to figure it out from there. Sqlite studio can be found here
http://sqlitestudio.one.pl/index.rvt

(Deleted)

combine SystemUI.apk with SystemUI.odex

I am facing issues in compiling systemui.apk and systemUI.odex files. I was porting Pixel Navigation bar for AOSP ROM of @Santhosh M. There is any to combine both the files?

If i remember right i made the Pixel navbar for Santhosh M ROM. Doesn't it work anymore? If you don't like the home button just decompile the apk and go to drawable-xxhdpi-v4 and change the ic_sysbar_home icon.
Anyway in order to combine them
1. Download baksmali. Make new folder and put the baksmali.jar and SystemUI.odex there.
2. Open command prompt in the folder where baksmali is located. Type in command prompt "adb pull /system/framework/arm" to extract the required files from the phone.
3. Type "java -jar baksmali.jar deodex SystemUI.odex -l" in the command prompt and if it successful there should be an output folder called "out". Copy it and paste it to the decompiled SystemUI.apk then rename it "smali"
4. Get the required odex files from Pixel's SystemUI(tho' i would recommend you to get them from the already modified systemUI as it usually generates the same number IDs so you wont have to deal with odex file changes).
5. Paste them to smali/com/google/android/systemui(if i remember right you had to create google/android/systemui folders so no worries if they are missing)
6.Recompile
I'd advise you to use this tutorial as it is way more detailed.

Sashko98 said:
If i remember right i made the Pixel navbar for Santhosh M ROM. Doesn't it work anymore? If you don't like the home button just decompile the apk and go to drawable-xxhdpi-v4 and change the ic_sysbar_home icon.
Anyway in order to combine them
1. Download baksmali. Make new folder and put the baksmali.jar and SystemUI.odex there.
2. Open command prompt in the folder where baksmali is located. Type in command prompt "adb pull /system/framework/arm" to extract the required files from the phone.
3. Type "java -jar baksmali.jar deodex SystemUI.odex -l" in the command prompt and if it successful there should be an output folder called "out". Copy it and paste it to the decompiled SystemUI.apk then rename it "smali"
4. Get the required odex files from Pixel's SystemUI(tho' i would recommend you to get them from the already modified systemUI as it usually generates the same number IDs so you wont have to deal with odex file changes).
5. Paste them to smali/com/google/android/systemui(if i remember right you had to create google/android/systemui folders so no worries if they are missing)
6.Recompile
I'd advise you to use this tutorial as it is way more detailed.
Click to expand...
Click to collapse
Thanks! I will be trying this out today. You developed Pixel Nav bars and the thing is you made it for January build. This is April so I have seen that it doesn't works. We need to decompile the systemui.apk again and again Change the ID and other things.
I have ported pixel Navbars for LineageOS. It was easy and today, I stuck in this steps.

I just followed your tutorial and I got this error
C:\Users\Xaif\Desktop\Baksmali\framework>java -jar baksmali.jar deodex SystemUI.
odex -x
usage: java -jar baksmali.jar [options] <dex-file>
disassembles and/or dumps a dex file
-?,--help prints the help message then exits.
Specify twice for debug options
-a,--api-level <API_LEVEL> The numeric api-level of the file
being disassembled. If not
specified, it defaults to 15 (ICS).
-b,--no-debug-info don't write out debug info (.local,
.param, .line, etc.)
-c,--bootclasspath <BOOTCLASSPATH> A colon-separated list of
bootclasspath jar/oat files to use
for analysis. Add an initial colon
to specify that the jars/oats should
be appended to the default
bootclasspath instead of replacing
it
-d,--bootclasspath-dir <DIR> the base folder to look for the
bootclasspath files in. Defaults to
the current directory
-e,--dex-file <DEX_FILE> looks for dex file named DEX_FILE,
defaults to classes.dex
-f,--code-offsets add comments to the disassembly
containing the code offset for each
address
-i,--resource-id-files <FILES> the resource ID files to use, for
analysis. A colon-separated list of
prefix=file pairs. For example
R=res/values/public.xml:android.R=$A
NDROID_HOME/platforms/android-19/dat
a/res/values/public.xml
-j,--jobs <NUM_THREADS> The number of threads to use.
Defaults to the number of cores
available, up to a maximum of 6
-k,--check-package-private-access When deodexing, use the
package-private access check when
calculating vtable indexes. It
should only be needed for 4.2.0
odexes. The functionality was
reverted for 4.2.1.
-l,--use-locals output the .locals directive with
the number of non-parameter
registers, rather than the .register
directive with the total number of
register
-m,--no-accessor-comments don't output helper comments for
synthetic accessors
-n,--normalize-virtual-methods Normalize virtual method references
to the reference the base method.
-o,--output <DIR> the directory where the disassembled
files will be placed. The default is
out
-p,--no-parameter-registers use the v<n> syntax instead of the
p<n> syntax for registers mapped to
method parameters
-r,--register-info <REGISTER_INFO_TYPES> print the specificed type(s) of
register information for each
instruction. "ARGS,DEST" is the
default if no types are specified.
Valid values are:
ALL: all pre- and post-instruction
registers.
ALLPRE: all pre-instruction
registers
ALLPOST: all post-instruction
registers
ARGS: any pre-instruction registers
used as arguments to the instruction
DEST: the post-instruction
destination register, if any
MERGE: Any pre-instruction register
has been merged from more than 1
different post-instruction register
from its predecessors
FULLMERGE: For each register that
would be printed by MERGE, also show
the incoming register types that
were merged
-s,--sequential-labels create label names using a
sequential numbering scheme per
label type, rather than using the
bytecode addressQA
-t,--implicit-references Use implicit (type-less) method and
field references
-v,--version prints the version then exits
-X,--experimental enable experimental opcodes to be
disassembled, even if they aren't
necessarily supported in the Android
runtime yet
-x,--deodex deodex the given odex file. This
option is ignored if the input file
is not an odex file
Click to expand...
Click to collapse
I also tried doing like the above given command so I followed this steps:
C:\Users\Xaif\Desktop\Baksmali\framework>java -jar baksmali.jar --deodex SystemU
I.odex -l
Error occurred while loading boot class path files. Aborting.
org.jf.util.ExceptionWithContext: Cannot locate boot class path file /system/fra
mework/core.jar
at org.jf.dexlib2.analysis.ClassPath.loadClassPathEntry(ClassPath.java:2
96)
at org.jf.dexlib2.analysis.ClassPath.fromClassPath(ClassPath.java:207)
at org.jf.baksmali.baksmali.disassembleDexFile(baksmali.java:67)
at org.jf.baksmali.main.main(main.java:305)
C:\Users\Xaif\Desktop\Baksmali\framework>
Click to expand...
Click to collapse

I have used ApkTool for Android to deodex that file and it did it successfully. Now, I am porting again

[Xposed Module] [Android 11] Reading file between /data/data/package_name and /data/data/packeage_name/file

What's the difference between the two following directories and what's a difference when I save the text file in two dir:
(1) /data/data/package_name
(2) /data/data/packeage_name/file
So, I wanna read a text file in Andoird 11 through Xposed Module. I can read the file's content in the (1) dir, but it can't in the (2) dir, which I meet the "ACCESS: (Permission Denied)".
I wonder what's the difference when I save the text file in the above directories? And is there any way to read the file in /data/data/packeage_name/file directory?

First things, its wrong place for ask that and another thing its cause to selinux security you can easily fix by using new Xsharedpreference which will store your file in different path or you can try by fix folder permission of /data/data/packeage_name/file directory but i m not sure this one works or not in your condition.