Related
I'm using DCD's new 2.3 Kitchen.
I created an OEM from a Mortscript install cab (ver. 4.1) using Ervius Package Creator.
When BuildOS compiles the registry I get an "error building defaul.hv and user.hv".
Checking the log comes up with this:
log.txt said:
Failed to parse value name HKEY_LOCAL_MACHINE\Software\Spb Software House\Pocket Plus\11\Applications\MortScript.exe!!!
InitRegistry FAILED in file ".\Registry\3361ebcd-b637-423d-b96b-5d65fda26662.rgu" within a few lines of line 6.
ImportFromPackageListStrict: (RGUComp) !ERROR failed importing ".\Registry\3361ebcd-b637-423d-b96b-5d65fda26662.rgu"
wmain: (RGUComp) !ERROR failed building DEFAULT hives
Click to expand...
Click to collapse
Here is the RGU. Line six seems to deal with the creation of a value, "window classes". Looking at a manual installation the value is supposed to be a Multi Line Value.
Here is what is in the RGU:
Code:
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Spb Software House\Pocket Plus\11\Applications\MortScript.exe]
"Enabled"=dword:00000001
"UserName"="MortScripts"
"WindowClasses"0x00010000SysListView32
[HKEY_CLASSES_ROOT\MortScript\Shell\Open\Command]
@="Windows\\MortScript.exe""" """%%1"
[HKEY_CLASSES_ROOT\MortScript\DefaultIcon]
@="Windows\\MortScript.exe,-130"
[HKEY_CLASSES_ROOT\MortScript]
@="MortScript"
[HKEY_CLASSES_ROOT\.mortrun]
@="MortScript"
[HKEY_CLASSES_ROOT\.mscr]
@="MortScript"
According to this guide the """ in line 9 is an error with Ervius Package Creator that should be changed to \" so I tried changing it to:
Code:
[HKEY_CLASSES_ROOT\MortScript\Shell\Open\Command]
@="Windows\\MortScript.exe\" \"%%1"
And I got the same error. Any suggestions are appreciated.
HI , I am stuck exactly at the same place....
Hi all!
I'm fairly new to this whole ROM development thing, and the most I know how to do is use the kitchen to modify working ROMs to my leisure.
Lately I've been trying to port/build CM7 to my device, which is fairly new (and only recently got a forum here on XDA) which is the Samsung Galaxy W (codename Ancora).
First I tried to use as a base existing CM7 ROMs from devices with similar hardware, by just modifying the updater-script to put the files in the right partitions, however with no luck.
So then I decided to download the sources for CM7 and try to port using a generic build and then filling in the blanks related to hardware and such, but again with no luck (maybe related to something I heard about samsung specific patches?)
So now I'm trying to build it from source for the device, but I'm stuck at creating a vendor folder that works.
I've updated most the files that need updating but I keep getting this error:
Code:
build/core/product_config.mk:205: *** No matches for product "cyanogen_galaxyw". Stop.
I've inserted the references need in almost all files called but still nothing. Any ideas?
You have device and vendor folder, properly referred??
Greets!
mDroidd said:
You have device and vendor folder, properly referred??
Greets!
Click to expand...
Click to collapse
I believe so. But could you be a little more specific so I can double check? Some file may have gone over my head.
Thanks in advance,
At what stage is this failing? When you run envsetup.sh or when you setup lunch or when you call make?
medizen said:
At what stage is this failing? When you run envsetup.sh or when you setup lunch or when you call make?
Click to expand...
Click to collapse
When I setup lunch
Sent from my GT-I8150 using XDA App
When you run . build/envsetup.sh does it populate lunch with cyanogen_galaxyw?
i.e "including device/samsung/galaxyw/vendorsetup.sh"
it should populate lunch with an option to select for the cyanogen_galaxyw.
You're building on Linux
Lunch menu... pick a combo:
1. full-eng
2. full_x86-eng
3. simulator
4. medizen_olympus-eng
Which would you like? [full-eng]
If not check your vendorsetup.sh that is in your vendor/(Brand)/(Device) directory.
medizen said:
When you run . build/envsetup.sh does it populate lunch with cyanogen_galaxyw?
i.e "including device/samsung/galaxyw/vendorsetup.sh"
it should populate lunch with an option to select for the cyanogen_galaxyw.
You're building on Linux
Lunch menu... pick a combo:
1. full-eng
2. full_x86-eng
3. simulator
4. medizen_olympus-eng
Which would you like? [full-eng]
If not check your vendorsetup.sh that is in your vendor/(Brand)/(Device) directory.
Click to expand...
Click to collapse
Edit2: Yes it does. I just wasn't seeing it.
Edit3: This is what I get in the lunch menu:
Code:
Which would you like? [full-eng] 76
build/core/product_config.mk:205: *** No matches for product "cyanogen_galaxyw". Stop.
Device galaxyw not found. Attempting to retrieve device repository from CyanogenMod Github (http://github.com/CyanogenMod).
Traceback (most recent call last):
File "build/tools/roomservice.py", line 16, in <module>
result = json.loads(urllib2.urlopen("http://github.com/api/v2/json/repos/show/CyanogenMod?page=%d" % page).read())
File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.7/urllib2.py", line 394, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 412, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 372, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1201, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.7/urllib2.py", line 1174, in do_open
r = h.getresponse(buffering=True)
File "/usr/lib/python2.7/httplib.py", line 1027, in getresponse
response.begin()
File "/usr/lib/python2.7/httplib.py", line 407, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
line = self.fp.readline()
File "/usr/lib/python2.7/socket.py", line 447, in readline
data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer
build/core/product_config.mk:205: *** No matches for product "cyanogen_galaxyw". Stop.
** Don't have a product spec for: 'cyanogen_galaxyw'
** Do you have the right repo manifest?
Do you have a .mk file from you devices/[vendor]/[model] that references your vendor .mk files?
Maybe you did not extract the files in the folders, poor am I not understanding you?
Greets!
The problem has to do with some of the core files, which is why it doesn't build.
I have recently attempted the same thing with CM7 for the HTC Flyer/View tablet, without much success. I believe my tablet shares the same chipset and CPU as your Samsung Galaxy W (MSM8255T)
What I did was clone a similar build and try to modify some of the script sh files and mk files from a similar device (HTC Incredible 2/S aka vivow and vivo on HTC codenames/CM7). Once you edit these files and properly substitute the device name, you can get past the problem you are having in the OP with the "device not found and looking up cyanogen repos", but you must already have the proprietary and device files extracted, and properly edited in /rootcm7folder/device/htc/galaxyw and /rootcm7folder/vendor/htc/galaxyw
For the proprietary files, it's pretty easy, just take the extract-files.sh script and modify the device name and it'll copy the necessary ones to /vendor/htc/galaxyw
That'll let you finish lunch, but once you compile, it won't start. I think it has something to do with some different libraries in my case, but I'll update you if I figure out more.
---------- Post added at 12:27 PM ---------- Previous post was at 12:16 PM ----------
whoops, ignore the htc folders I wrote above and substitute it for samsung. I was thinking wrong for some reason.
I'm making an attempt at building the ics source code from google and modifying the build to run on my lg thrill and I was wondering if anyone can shed any light on making a vendor folder for my device?
This is NOT going to contain anything for users to flash - this is for developers(or those who aspire and want to learn). This is a work in progress.
I want to make it clear that XDA nor the mods endorse or approve of this thread(well, they are allowing me to post it), but this is a concept that may be helpful for multiple reasons.
Please go easy on me, constructive criticism is welcomed, flaming is not. Do not post if you are not adding to the discussion or a developer asking a question. This is something I have been working on for a "rom" I will be putting out in a few days.. I just decided I would share the process, maybe others can help refine it.
Benefits:
If you build for multiple devices you can use this SAME flashable on those other devices and only need to edit the updater-script, prop edits that are device specific, and any system or apk's that are device specific! This could take 5 minutes or less to change AND upload!
It will work on ANY rom(for the same device) as long as you aren't modifying the things that rom specifically needs - and with this method it would be very rare that you would somehow break a rom.
You can still add files/apks, delete files you don't want, modify(rather than replace) the build.prop - technically you could create a flashable that turns stock into CM9 if you wanted to, but only then is a full ROM really needed.
Users can choose the rom they want and add your customizations(the entire community can use your flashable, rather than just a portion!)
It reduces the flashable filesize - rather than 100-400mb your flashable could be 4-20(depending how much you are changing).
It takes MUCH less time to flash, the recovery log will be shorter/easier to read, and it reduces the chance of errors(you are changing less).
Easier to track the changes since the flashable has been reduced to what is NEEDED.
This is an open source community - other devs and even users could look at your flashable and clearly see what you've done, how you've done it, so everyone benefits.
Easier to support - to make changes is EASY, faster zipping, signing, updating, uploading, etc.
You can choose to make it CONFIGURABLE - add #comments in the updater-script, the included build.prop script, or add a readme in the flashable that tells them what they can remove if they don't want it!
I'm quite sure there are MANY more reasons this is beneficial, but I'll leave it to you to decide..
Post 1 - Benefits, explanation, reasoning
Post 2 - Instructions and a soon a flashable example that I will publish
Post 3 = profit?!
First, there are totally different systems out there we can try to get running, CM9, MIUI, etc- this is when the very framework is absolutely different-- otherwise every rom we have RIGHT NOW is just a series of tweaks to the stock(like the leaked ICS) rom. We can argue that people just tweak what is there, or "develop" something new, but nearly everything is building on the concepts of something before- so let's do it right.
What makes a rom unique:
It is easier to keep track of changes(the /system will only have the changes you make, your updater-script will show you other changes, and any scripts you create will show the last changes) - so there shouldn't be "and other stuff I don't remember" in your changelog. This will also assure that there are less potential issues- you are ONLY changing specific things- troubleshooting these things are easier when you aren't including the entire modified flashable.
What you are trying to accomplish:
The main thing that makes a "rom" stand out from any other is the changes to the build.prop - you totally replaced it with something that is your own(or an adapted version hopefully giving proper credit to whoever's tweaks you are using): but they are using your "rom" if they have your build.prop and not someone else's. Everything else is deleting, copying, setting permissions, etc.
The goal: making it more open source
Until you build something totally new(Cm9, miui, etc), you are working with an open source platform, modifying, adding, deleting, scripting. Period. Admit that you are giving the base platform some tweaks, or a "flavor" that others will hopefully prefer.
If you are already developing, you know that with the correct updater-script you can add apks, delete what you don't want, over-write the things you want to replace- this includes theming and everything else you could want.. and usually you would include this in the full base rom, totally pre-configured. With a build.prop that is yours alone.
Conclusion:
Unless you are building an OS from scratch, or modifying it so heavily that it is more yours than it is not, giving the end users these options without wiping is the way to go. If they can flash your mods and then mine and end up with a better final product, how can this go wrong? This is open source, this is android, this is evolution.
Instructions:
First, keep track of all the changes you want to make - the better organized you are, the easier this will be. If you aren't even sure what all you did..
How to do it:
One of the main things you are changing by creating a total prepacked rom is the build.prop- perhaps you have tweak A, and I have tweak B, and those tweaks are different enough to change the users experience.. but why not combine them if possible? It IS possible.
Decide on the build.prop edits that you want to add/modify(you will NOT replace their build.prop) and modify the propEditor script as needed - if you build for multiple devices I would recommend you add the device specific ones at the end(with #comments) for easy modification/removal from script. You really only need to MODIFY the RO.whatever lines(because they are read only), everything else can be added to a local.prop in the /data folder
Create your updater-script as you normally would, as you know this does the main work - this will likely remain mostly the same, with just a few lines added for the scripts you need to modify the build.prop. Just make sure you delete what you would from the rom itself with the script
Rather than copy your /system /data or any other files into the rom you would normally be modifying, those are the only files you will include in the flashable - if this is done right it will make all of the changes you want without breaking anything.
If you want others to be able to understand/build upon your work you can add #comments or a readme in the above steps, then all users would have to do is remove the lines you instructed, re-zip(no need to sign if they use 7-zip or winrar) and then flash.
As said in the previous area, outside the build.prop you can make a small flashable that will change everything, but if you can MODIFY tweaks already in the build.prop, or add lines if they don't exist-- we would be creating a continual evolution of a better and better performing rom.. with feedback bad tweaks would get tossed, each developer adds their flavor, but users can flash what they want to get the performance they desire without the headache and confusion that comes with wiping everything of the developer they used before that. This will enable them to learn more about how and what we are doing with their devices, and they can provide feedback that makes it better for everyone.
The code(that may need work) to modify or add lines in the default build.prop is here:
(This may require testing, big thanks to tommytomatoe for all the help, original thread is here.)
Code:
#!/sbin/sh
# Build.prop editor script with basic sed commands
# tommytomatoe
# May 12, 2012
# mounting system as rw
busybox mount -o remount,rw /system
if [ $? != 0 ] ; then exit
fi
FILE=/system/build.prop
TMPFILE=$FILE.tmp
line1=ro.product.version
line2=ro.HOME_APP_ADJ
line3=ro.media.enc.jpeg.quality
#Add more line# formatted as above as needed to identify each prop
line1Arg=Classicv0.1.0
line2Arg=1
line3Arg=100
#Add more line$Arg formatted as above as needed for each prop change
lineNum=
#to add additional prop changes copy the lines between here
prop=$line1
arg=$line1Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
#and here and paste to the end, changing the $line# and $line#Arg to match what you've added
# to iterate over all the prop values you want to change,
# just copy and paste the code chunk or create a for loop.
# I will leave it to you to create a for loop
prop=$line2
arg=$line2Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
prop=$line3
arg=$line3Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
It may require some work, feel free to offer advice if you can help make it better), but you can make a few changes to that, and rather than replacing the entire system on a users phone, you are making YOUR modifications to make their device work better! Read the #comments above to see the different tweaks you are trying to make, and it will automatically either change the value, or it will add the line if it doesn't already exist in the build.prop
Profit?!
I understand many developers may think this would make it easier to "steal" your work, but as I said before, everything android is open source. Besides, with enough changes this makes it a TRUE rom, and it will be NEARLY as complex as the much larger file he would be uploading.
It could actually be profitable time/effort wise, ANY rom could be done with this as long as you tell them what base to work with.
Example of "profit"
Mike 1986.'s ARHD is on 10 devices, if you check, most of the features in one are in the rest of them. He has enough experience where porting everything over all of his changes to a new rom probably isn't that difficult for him(I'll bet he is VERY organized), but this would enable him to make a few changes to a propEditor script, the updater-script, remove or change out a few files.. re-zip and sign, upload, done.
This also takes out much of the opportunity for developer error or errors during flashing..
Doubt I'll need it.. but we'll see.
I have seen many questions about build.prop editing but very less of them have been convincing to be solved and modders don't need to tell people to add lines from next time
First how to make a script sh file which contains your prop lines
Click to expand...
Click to collapse
Open npp and type:
#!/sbin/sh[This is the first line to call busybox]
busybox echo "" >> /system/build.prop[Call busybox for prop file]
busybox echo "Title of your added lines" >> /system/build.prop(not recommended but works absolutely)[This is the description line which is written inside build.prop for understanding of your apk's value nature..]
busybox echo "ro.config.ringtone=opal.ogg" >> /system/build.prop....(And just the same way add lines)[This line put your default ringtone to opal.ogg]
Provide a line break
busybox echo "" >> /system/build.prop[Call this line again for busybox to finish prop file]
save file with script.sh extension.....save it at the main folder which contains meta-inf folder too...
Add these lines to updater-script after
Click to expand...
Click to collapse
ui_print("Adding lines to build.prop");
package_extract_file("script.sh", "/tmp/script.sh");
set_perm(0, 0, 0777, "/tmp/script.sh");
run_program("/tmp/script.sh");
For modifying the script ...like deleting prop lines....its quite hard to manage through it..end up in bootloops...will see to work it out...if any of you have got the deleting prop lines successful then post here
Try this one
Code:
{ sed -i "/^$1=/{ h; s/^$1=\(.*\)/# $1 was \"\1\"\n$1=$2/ }; \${ x; s/$1//; x; t e; s/$/\n$1=$2/; : e }" "$TMP"; }
this will search your build.prop for a line and replace it with something that you want it to be... then it will echo all of that to a temporary file of your choosing for reference. it will also comment out what the old prop was
RErick said:
Try this one
Code:
{ sed -i "/^$1=/{ h; s/^$1=\(.*\)/# $1 was \"\1\"\n$1=$2/ }; \${ x; s/$1//; x; t e; s/$/\n$1=$2/; : e }" "$TMP"; }
this will search your build.prop for a line and replace it with something that you want it to be... then it will echo all of that to a temporary file of your choosing for reference. it will also comment out what the old prop was
Click to expand...
Click to collapse
Great..i will work through it
epicsilence said:
I have seen many questions about build.prop editing but very less of them have been convincing to be solved and modders don't need to tell people to add lines from next time
Open npp and type:
#!/sbin/sh[This is the first line to call busybox]
busybox echo "" >> /system/build.prop[Call busybox for prop file]
busybox echo "Title of your added lines" >> /system/build.prop(not recommended but works absolutely)[This is the description line which is written inside build.prop for understanding of your apk's value nature..]
busybox echo "ro.config.ringtone=opal.ogg" >> /system/build.prop....(And just the same way add lines)[This line put your default ringtone to opal.ogg]
Provide a line break
busybox echo "" >> /system/build.prop[Call this line again for busybox to finish prop file]
save file with script.sh extension.....save it at the main folder which contains meta-inf folder too...
ui_print("Adding lines to build.prop");
package_extract_file("script.sh", "/tmp/script.sh");
set_perm(0, 0, 0777, "/tmp/script.sh");
run_program("/tmp/script.sh");
Click to expand...
Click to collapse
I cant quite understand this. Could you please make a simple way on how to do this. thanks :fingers-crossed:
Najmi Mansor said:
I cant quite understand this. Could you please make a simple way on how to do this. thanks :fingers-crossed:
Click to expand...
Click to collapse
1. Don't quote full op
2.Nope there is no other simple method, you may learn from now
Najmi Mansor said:
I cant quite understand this. Could you please make a simple way on how to do this. thanks :fingers-crossed:
Click to expand...
Click to collapse
Friend, npp means notepad ++ ..you can get it from sourceforge.net ...and for later instructions type and understand meaning written in brackets
And yes...you need to read more threads around xda so you can understand more threads easily..
Enjoy reading
RErick said:
Try this one
Code:
{ sed -i "/^$1=/{ h; s/^$1=\(.*\)/# $1 was \"\1\"\n$1=$2/ }; \${ x; s/$1//; x; t e; s/$/\n$1=$2/; : e }" "$TMP"; }
this will search your build.prop for a line and replace it with something that you want it to be... then it will echo all of that to a temporary file of your choosing for reference. it will also comment out what the old prop was
Click to expand...
Click to collapse
Can you explain this a bit further in terms of usage? What part of this code is the line to be replaced and the line to be supplanted? I assume 1 & 2 are the lines, but I still don't quite understand... Maybe you could give an example? Thank you.
epicsilence said:
Friend, npp means notepad ++ ..you can get it from sourceforge.net ...and for later instructions type and understand meaning written in brackets
And yes...you need to read more threads around xda so you can understand more threads easily..
Enjoy reading
Click to expand...
Click to collapse
Thanks for replying
Heatshiver said:
Can you explain this a bit further in terms of usage?
Click to expand...
Click to collapse
Hello, learn more about sed here...my friend once implemented it on galaxy s2 for verification....but same script did not applied for xperia series...so i think its more important to get to know deep about its usage......
SED-Complete Document(Unofficial)
Always share knowledge, sometimes we might get more than we know
anybody has sample zip for this including updater script commands and the file script.sh, thanks anyone can help
---------- Post added at 04:14 AM ---------- Previous post was at 03:30 AM ----------
TheDriller said:
Try this one
Code:
{ sed -i "/^$1=/{ h; s/^$1=\(.*\)/# $1 was \"\1\"\n$1=$2/ }; \${ x; s/$1//; x; t e; s/$/\n$1=$2/; : e }" "$TMP"; }
this will search your build.prop for a line and replace it with something that you want it to be... then it will echo all of that to a temporary file of your choosing for reference. it will also comment out what the old prop was
Click to expand...
Click to collapse
can u give an example of a line that ur trying to replace in buildprop? what if this line ro.config.dha_empty_max=36 you change the value to 40 . . pls? thanks
I have multiple errors like this
frameworks/av/media/libstagefright/ACodec.cpp:39:24: fatal error: QCMetaData.h: No such file or directory
this file located in hardware/qcom/media/mm-core/inc/ directory
how i can add this directory to include_paths?
if it is to a linux computer, you would add this to your /home/user/.bashrc file <- notice the dot.
export PATH=$PATH:/path/to/whatever/file/you/need
you can add this line below the same line, if you have one like this already.
to test, youc an also type it on the CLI, if it works, and you needed it permanent, then add it to the file mentioned.
no. it not about PATH variable
on UT compilation i have multiple errors like this
frameworks/av/media/libstagefright/ACodec.cpp:39:24: fatal error: QCMetaData.h: No such file or directory
becouce including header file QCMetaData.h locating in hardware/qcom/media/mm-core/inc/ directory that was not in <<includes_directories>>
how i can add this includes directory to each project which include files from it?
i dont want to catch all dependencies. how get it automatics?
ah I see. that's beyond my sys admin knowledge. someone with programming (gcc) skills can help you. Sorry
Hi Maybe this can help http://stackoverflow.com/questions/...odec-cpp-in-android-sources-in-libstagefright
gazhead said:
Hi Maybe this can help http://stackoverflow.com/questions/...odec-cpp-in-android-sources-in-libstagefright
Click to expand...
Click to collapse
nope