Greetings all,
I would like to know something that seems to be so simple it hasn't been documented here anywhere.
My question is: How do I build the source provided by Google for my Desire HD?
Yes, there are tutorials, don't point me to them. They either provide you with the AOKP way or the CM way.
I want to build my stuff from scratch.
Is there a generator that will create the necessary file structures for me (in the devices folder)?
Is there a complete list that my rom needs to include in order to make it run on my device (preferably a list of folders I need)?
I know about the vendor files, these are created by a third party. How do I know what vendor files I need to create? How do I know how to name them?
Don't get me wrong, I've used C, C++ and C# for YEARS (I think about 8 now) and I know how to code. I just don't know how to compile android!
It doesn't seem that hard though, I've seen threads where people provide ROMs for the Desire HD without even having the device!
Also, how would I test this and debug it? I don't think it's safe to just flash my rom once I get it compiled to my actual device and possibly brick it.. Can I use an emulator?
I hope you will read this post before answering something alike "Plenty tutorials" or "This can be found everywhere", because it can not. I can only find AOKP or CM ways, I want neither.
Greetings Ultimate-Tester
The only time I know of that this has been achieved for this device is aospX, an ICS ROM on the Inspire 4G forums. It is much harder than you would think. Google does not support this hardware, HTC does. So there was never AOSP source for this device.
Yes, I can imagine how hard it is. As I said I have programming experience, it's just that I don't have it with Android ROMS.
I have built mainly for Windows, also on Ring0 level (which is the lowest level you can get) so I think making drivers is a task I can handle. I am definitely not underestimating it.
Could anyone give me an answer to this line:
Code:
Is there a generator that will create the necessary file structures for me (in the devices folder)?
Is there a complete list that my rom needs to include in order to make it run on my device (preferably a list of folders I need)?
I am very interested in how other people knew what folders to create and what files to put in them. How would the Google Source (envsetup) know which device files to use and what not? Again, can I generate the file structure somehow?
Greetings,,
My suggestion is to use device trees from AOSP-based ROMs that already exist for this device. For example, look in the cfX manifest.xml for Ace-specific stuff (kernel, device, etc.). I personally haven't seriously tried this before, so that's all I can offer.
Okidoki, will do. Then for the last item: Testing.
What will be a safe way to test out my brew?
What will actually happen if I flash a ROM with missing files? I hope there's an underlying catcher that will send something I can see in logcat and fix it that way.. Is this the case, or will I immediately brick my phone once I do something wrong? Do I need to make sure something is 100% there in order to reach my recovery again?
Greetz,,
I'm nor aware of any safety nets. If you're developing, you probably have to be willing to take the risks.
Related
I've been reading the forum, and based on the information and the tools there I have been able to modify my extended ROM, which is great. Now of course I'd like to modify the main ROM as well, but despite the many hours I've spent searching the forum, I can't find the necessary information to do it. There's always something essential missing, something which probably is obvious to a programmer, but not to a normal user. As I've been able to modify the extended ROM, I guess I should be able to modify the main ROM too. Who can point me in the right direction?
from what i understand it's not even 100% possible with xda1 since people cant seem to make the extracted files back to a nbf file
and there are no tools that i know of that even extract the main rom from a xda2
As I understand it, when you upgrade the operating system, you're actually modifying the ROM. Some people here like to call it to "flash", I think, and there are a lot of messages about it in here. I just haven't found the information necessary to do it. I want to modify the ROM on my XDAII.
no the operating system is the rom which is in a eeprom in the device
when you flash the rom you replace the operating system with the new one
when you say modifying it mean more in the way of exchanging different files inside the rom
but if you just mean flashing the rom with a newer then here is a guide
http://wiki.xda-developers.com/wiki/HimalayaRomFlashing
What does EEP stand for? How many ROMs are there?
I've seen a ROM created here for the XDAI, containing more programs than what the devices normally come with. I would like to have a ROM on my XDAII containing the programs I use, so that I don't need to reinstall them every time the device is hard reset. Isn't this possible?
What does EEP stand for?
Click to expand...
Click to collapse
huh what does EEP have to do with this ?
suppose it could stand for
Executive Excellence Publishing
or
European Environmental Press
how many roms there are i think there are 1.5 1.6 1.66 and 1.72
about extra programs then they are not! in the rom they are in the extended rom any CAB file you copy to the extented will install after automatic after a hardreset
you should take a look at the romkitchens ( specifically for xda1, but can be made for xda2 as well ).
and mkrom, and the other romtools
EEPROM stands for "electrically erasable programmable read only memory".
this is sort of the predecessor of flash memory.
"electrically erasable programmable read only memory" sounds like a contradiction, but thanks for that, it makes more sense than EEPROM.
What about all of us users who don't have a Unix machine? I suppose we're stuck with the original ROM then, and have to install our programs over and over again for every hard reset. Of course you can put a few of them in the extended ROM, but it becomes full too quickly and you're left with installing the rest of them manually.
well you can upgrade to a newer rom as they come out
like i have 1.66 but if i wanted 1.72 i could upgrade
about contradiction heh yeah suppose so but then if it was 100% always READ ONLY then it would be random was what in it as how the transistors randomly set when it was produced
A newer ROM wouldn't contain the programs I want.
no :/ but it could contain bug fixes for ms and radiostack and such
i suspect that extented rom was made so it would be easier for the phonecompanys' and other 3th party resellers to get programs preinstalled fast without having to mess around too much in the rom
this is at the cost of memory though
but then some programs dident like to be in the rom i believe here i mean if setting files were places in the rom aswell and the program could not write to the setting file
mkrom also works on cygwin under windows.
( now I also wrote this in the wiki page )
Isn't that just for XDA I?
it works for windows ce in general.
that doesn't mean that there is no work involved in getting it to work, but it is possible to make it work for the xda2. I use it to build custom roms for the devices we sell, that is why I wrote it in the first place.
What's cygwin?
How much space is there in the ROM to add extra programs? In the ROM that this forum developed for XDA I they added quite many programs from what I could see.
http://www.google.dk/search?hl=da&ie=UTF-8&q=cygwin&btnG=Google-søgning
Thanks for that, Rudegar.
To Itsme: I don't mind the work, but it looks like its written for programmers and that if you're not a fairly skilled programmer, you wouldn't be able to do it.
Firstly I want to stress that I am not making any accusations or (as far as I know) experienced anything like this, it's just a thought I had.
So my question is what's to stop an unscrupulous cook from adding something to a ROM that would steal account passwords? Sorry if this is a dumb question but I'm not a cook.
Thanks.
Very little, I guess.
I doubt anyone else goes to these lengths, but I always check the entire list of apps and their permissions (in Android) on install of a ROM.
But that's not foolproof, and takes ages, so often I do a diff of the file system to see if any dodgy apks are there.
Droidwall in whitelist mode will help against a malicious app, but a kernel based exploit would get through all of this
So personally I stick with modaco Rom, and tek kernel, as Paul & tek are trusted and have a good track record and history here and on modaco forums. So I guess just stick to major trusted chefs or wait for official. And be wary of new ROMs and chefs, not that we should distrust them, but just be wary till they build up a good reputation.
Thanks for your reply- you mentioned some things I had not considered doing.
I am currently using the Modaco 3.0 ROM and have been using it since 2.6 and have had no issues with it, I suppose the ultimate way forward would be to cook your own ROM but I'm from WinMo and wouldn't know where to start not to mention finding the time to learn all this stuff.
RetroFlux said:
Thanks for your reply- you mentioned some things I had not considered doing.
I am currently using the Modaco 3.0 ROM and have been using it since 2.6 and have had no issues with it, I suppose the ultimate way forward would be to cook your own ROM but I'm from WinMo and wouldn't know where to start not to mention finding the time to learn all this stuff.
Click to expand...
Click to collapse
You're in luck, we are in the same boat.. I made an easy kitchen for new Android cooks:
http://forum.xda-developers.com/showthread.php?t=633246
Regarding security, yeah I would go by reputation... but the best thing would be to cook your own ROM once you know what you want in a ROM, after trying out custom ROMs made by others.
Sweet! I'll check it out, thanks.
Yeah. Cooking your own seems the best bet.
One idea I did have. How about a thread where a trusted user or admin puts in the MD5/CRC hashes of the stock apk files, and makes an MD5 file. Then, users could check any suspect apps to see what (if anything) isn't stock. ie. a non-stock SMS app might be a bit suspect etc.
Although this would have a load of false positives for anyone who just edited a picture or icon within an apk.
Similarly, a catalogue of boot.img MD5 sums (the part that contains the kernel ramdisk) would allow users to check their boot.img looks legit before flashing.
The biggest issue here though is how to make sure that it's kept up to date, and that it's verified in some way so a malicious user couldn't add their own MD5 for their malicious app/kernel to the list, thus giving it trust.
Maybe better just learning to cook a rom... It's pretty easy once you get the hang of it. Just stay away from SPL and Radio until you know what to do.
Yeah I thought about getting cooks to hash their stuff but I don't think there would be much take up and like you say the false positives would be an issue.
anon2122 said:
Very little, I guess.
I doubt anyone else goes to these lengths, but I always check the entire list of apps and their permissions (in Android) on install of a ROM.
But that's not foolproof, and takes ages, so often I do a diff of the file system to see if any dodgy apks are there.
Droidwall in whitelist mode will help against a malicious app, but a kernel based exploit would get through all of this
So personally I stick with modaco Rom, and tek kernel, as Paul & tek are trusted and have a good track record and history here and on modaco forums. So I guess just stick to major trusted chefs or wait for official. And be wary of new ROMs and chefs, not that we should distrust them, but just be wary till they build up a good reputation.
Click to expand...
Click to collapse
You might come in for a surprise if you think checking apks is safe.
A simple keylogger (there's one which will compile and work for android - DON'T PM me about the name, I won't tell you) added to initrc, zipped log file of key catches and a simple ftp of the file once every 6h will do just fine.
For additional privacy concerns, you can always catch the entire screen (but that'll slow the system too much), or even zip and ftp the /data/data ...
Possibilities exist.
For the real adventurous, you might always add the code/function to one of the programs which are compiled while aosp'ing, for example, busybox, dropbear, whatver... Share that in a rom, and there you go.
Checking apk perms, scripts or whaever won't do you any good in this case.
This is why you try new roms from "amateur" chefs at your own risk. Believe me, bricking is the least of your concerns when trying new roms from unknown "devs"
I think this just further renforces the 'cook your own ROM' route. Don't worry I won't PM you about it as I'm not looking to steal people's passwords just looking to try and protect myself, I'm getting paranoid now and thinking about going back to a stock ROM :O
Wondering if anyone would be so kind as to give me a quick guide how-to make an AOSP build for the Rhodium?
Can someone give me abit pointer, like a guide or somethng?
You mean something like this? http://source.android.com/index.html
I think the best way to do it would be to use squashfs-tools to unsquash system.sqsh, and simply make the edits you want to. Then you would want to recompress it into a new system.sqsh (using version 3 of squashfs-tools, NOT version 4).
Alternatively, you might be able install everything you want on a vanilla build of Android, and simply distribute all those files (data.img and system.sqsh) when you've made all the customizations you want. I'd imagine this second method would be more likely to lead to problems when being run on other models of the device, or on other service providers.
Hey guys!
I just got my serranoltexx and am fairly happy. However, I really would like to try and get AOKP running. Could any devs point me in the direction of where to start, you know, just bootstrap me with some reading? I have a background in Linux and UNIX, have developed some networking stack API projects on windows and have written a ****load of bash, perl etc. scripts in the past. I've also worked on the Matroska container format. Compiling etc. pose no challanges for me. However, I have never fumbled around with Android and I have no idea what drivers and other components might be needed. And how to start finding out what's missing...
I do know how to bootstrap my source repository and sync it... and in theory also how to compile AOKP - for supported devices, that is. What I don't know is: how do I start resolving unmet dependencies, and, you know, generally port a rom to a new device?
Please don't post if you haven't even compiled your own ROM yet. More likely than not, you'd be wasting your time.
I've posted on xda-dev as well, not sure which is the more suitable forum, possibly this one... Link to the other thread:
http://forum.xda-developers.com/showthread.php?t=2501539
And please don't post me to this guide right here as it is only of limited help. As I said, I know how to do it in general... You know, this guide:
http://aokp.co/learn/so-you-want-to-build-aokp-jb-ubuntu-1204
I tried to build it, but many things are missing once i flashed the *.zip.
Maybe i messed up with sources and patches.
Tell us if you have success! :good:
Hi
I have asked this before but I haven't gotten the answer and some things have changed.
My goal is to edit the kernel of my device to include rtl8192cu driver.
I have the sources from http://gitgub.com/puresoul/android_kernel_lge_d605 (I hope I got the link right) I am currently stuck at creating the .config file and getting the right files to include the driver. Could anyone help me out, any links to tutorials that actually tell me how to? The guides online are almost all specific to a certain device or their goal is different.