Related
So, I've looked at every vendor tree that I can find. Not all of them are set up the same, but that appears to be taken care of via the .mk files. I really want to help some folks with an Eris vendor tree. Is there anyone out there who can and will explain a few things to me?
1) What proprietary files can we leave in the repo, if any? I've seen at least one repo that seems to have some proprietary binaries in it, but then uses the extract-files.sh to pull the rest. I just don't get where the line is. Maybe they don't either?
2) Why can't we put all of the proprietary files in the repo? If we're building the ROM, and we're just going to put them on the ROM and post it anyway...
(I get copyright issues, but posting them in the ROM and posting them in the repo seem to be pretty much the same to me. )
Thanks!
I would like to know the same thing.
I would also like to see a detailed "map" of the files in a "generic" rom
I have tried making sense of them by looking inside, but I am having a hard time telling if the files I am seeing are generic Android, device specific, or extra files someone threw in to customize the rom
I think a good start would be a list of the minimum files required to get Android running on a device along with a description of what each file (or at least each group of files) does.
Then maybe later add a description of the optional packages.
ROM chefs could then use that list as a starting place and add the specific information for the device they are cooking for.
Anyone know of a list like this or maybe one that is at least partially complete so that we wouldn't have to start from scratch?
I have read a few posts in this section, but it is totally impossible for someone like me (new to smartphones, flashing and the rest) to understand anything. Would you please explain some of the terminologies used here? Some of them are: kernel, 3g, port, system.ext2, BT... and thousands more.
Thank you very much!
you don't really "need" to understand any of that.
all you need to do is to learn how to download files, learn how to extract the downloaded file, learn how to copy them to an sd card, and learn how to run a program inside windows mobile.
if you can do all that, you should be set!!!
just follow steps 1-6 (ignore step 1b - the part about system.ext2) - http://forum.xda-developers.com/showthread.php?t=951962
Well noted AkumaX. Thank you very much!
XDAndroid is a project to port Android onto older HTC phones.
There are two main parts of XDAndroid, which combine to form a complete port:
Kernel/drivers: You can find packages to run Android on old HTC phones from a variety of sources, but whatever package you use, all rely upon the kernels/drivers created by the XDAndroid team to enable the basic hardware.
Android system: The Android system forms all of the parts of the phone's interface that you can directly interact with. Once the kernel/drivers have setup the hardware, you can add on an Android system port of your choice to form a complete build. Many system ports are available, both in terms of different versions (2.1 Eclair, 2.2 Froyo, 2.3 Gingerbread, etc.) and different starting points in the case of ports written by those outside of XDAndroid.
XDAndroid releases an "official" system port you can use, which is directly ported over by the XDAndroid team from the Android Open Source Project, and is very close to stock. Many of the alternative builds you come across are modifications of the XDAndroid system, containing customizations that deviate farther from stock Android, while others have different starting points altogether, and are ports of the ROMs found on official shipping devices that have already been customized (but still use the same basic kernel/drivers found here).
Android is a framework that runs on top of Linux. In order to get Android running on our devices, first we must get Linux running on the hardware with all drivers implemented, and then, we hook Android into these drivers. Thus, broadly viewed, the XDAndroid project is divided into two parts: the kernel/drivers and the Android port.
When you look at the files in your Android directory, you'll probably see something like the following:
zImage: The Linux kernel and drivers.
modules-###: Additional drivers for the kernel. Your system will load without this, but things like wifi may not work, or you may encounter instability.
initrd.gz: Used in the Linux boot process.
system.ext2: Most of the Android framework.
rootfs.img: Additional parts of the Android framework that are customized for our devices.
data.img: This file contains what would be your internal memory on a real Android device. Whenever you install a program it goes in to here. A new empty one will be automatically created if you don't have one.
haret.exe: Reboots you from Windows into XDAndroid.
startup.txt: Commands passed to XDAndroid on bootup that are customized by the user.
ts-calibration: Contains calibration information for the touch screen. If you don't have this file, you will be prompted to calibrate your screen on startup.
AndroidApps: A folder where if you copy any apks into it, they will be automatically installed on bootup.
manekineko said:
XDAndroid is a project to port Android onto older HTC phones.
-------.
Click to expand...
Click to collapse
Good explanation manekineko!...I believe this is what op was looking for.
there is light at the end of the tunnel, it wont take much longer if the devs keep up this good work, until there can be made stable and good builds with good battery life etc. when the time is there i will create an complete noob friendly installation guide (with pics and maybe even an vid).
I'm currently trying to figure out which one to install!
manekineko said:
XDAndroid is a project to port Android onto older HTC phones.
There are two main parts of XDAndroid, which combine to form a complete port:
Kernel/drivers: You can find packages to run Android on old HTC phones from a variety of sources, but whatever package you use, all rely upon the kernels/drivers created by the XDAndroid team to enable the basic hardware.
Android system: The Android system forms all of the parts of the phone's interface that you can directly interact with. Once the kernel/drivers have setup the hardware, you can add on an Android system port of your choice to form a complete build. Many system ports are available, both in terms of different versions (2.1 Eclair, 2.2 Froyo, 2.3 Gingerbread, etc.) and different starting points in the case of ports written by those outside of XDAndroid.
XDAndroid releases an "official" system port you can use, which is directly ported over by the XDAndroid team from the Android Open Source Project, and is very close to stock. Many of the alternative builds you come across are modifications of the XDAndroid system, containing customizations that deviate farther from stock Android, while others have different starting points altogether, and are ports of the ROMs found on official shipping devices that have already been customized (but still use the same basic kernel/drivers found here).
Android is a framework that runs on top of Linux. In order to get Android running on our devices, first we must get Linux running on the hardware with all drivers implemented, and then, we hook Android into these drivers. Thus, broadly viewed, the XDAndroid project is divided into two parts: the kernel/drivers and the Android port.
When you look at the files in your Android directory, you'll probably see something like the following:
zImage: The Linux kernel and drivers.
modules-###: Additional drivers for the kernel. Your system will load without this, but things like wifi may not work, or you may encounter instability.
initrd.gz: Used in the Linux boot process.
system.ext2: Most of the Android framework.
rootfs.img: Additional parts of the Android framework that are customized for our devices.
data.img: This file contains what would be your internal memory on a real Android device. Whenever you install a program it goes in to here. A new empty one will be automatically created if you don't have one.
haret.exe: Reboots you from Windows into XDAndroid.
startup.txt: Commands passed to XDAndroid on bootup that are customized by the user.
ts-calibration: Contains calibration information for the touch screen. If you don't have this file, you will be prompted to calibrate your screen on startup.
AndroidApps: A folder where if you copy any apks into it, they will be automatically installed on bootup.
Click to expand...
Click to collapse
Thank you so much for your explanations, manekineko. I believe that I am now ready to cruise through all the threads of this section without fear.
shatred said:
there is light at the end of the tunnel, it wont take much longer if the devs keep up this good work, until there can be made stable and good builds with good battery life etc. when the time is there i will create an complete noob friendly installation guide (with pics and maybe even an vid).
Click to expand...
Click to collapse
shatred, I am eagerly waiting for two things: (i) for the developers to release the perfect Android builds (my sincere encouragements to them by the way!!!) and (ii) for your installation guide.
gueyenono said:
I'm currently trying to figure out which one to install!
Click to expand...
Click to collapse
tell me your phone type, so an rhod-100? 200? 300? etc.
and tell me what you prefer more, an good battery life and an stable running system without camera support OR less stable system, bad battery life but with camera support.
Tell me and i will help you
shatred said:
tell me your phone type, so an rhod-100? 200? 300? etc.
and tell me what you prefer more, an good battery life and an stable running system without camera support OR less stable system, bad battery life but with camera support.
Tell me and i will help you
Click to expand...
Click to collapse
Uhm... You no longer have to choose. WisTilt2 pulled the latest commits from GIT into his test kernel.
arrrghhh said:
Uhm... You no longer have to choose. WisTilt2 pulled the latest commits from GIT into his test kernel.
Click to expand...
Click to collapse
yeah but if you activate the camera libs the phone wont go into deep sleep mode right? or is that fixed already?
shatred said:
yeah but if you activate the camera libs the phone wont go into deep sleep mode right? or is that fixed already?
Click to expand...
Click to collapse
Seems I was wrong about that. It was the other way around, if the libs are disabled the phone won't sleep.
However, with FRX05 there's no need for the libs. FRX05 + GIT kernel or WisTilt2's newest kernel is all you need for cam.
arrrghhh said:
Seems I was wrong about that. It was the other way around, if the libs are disabled the phone won't sleep.
However, with FRX05 there's no need for the libs. FRX05 + GIT kernel or WisTilt2's newest kernel is all you need for cam.
Click to expand...
Click to collapse
hmm yeah about that, i tried frx05 with wistilt2 latest kernels but it doesnt work for me, i think its an problem with my user conf... can you perhaps send me your user conf from frx05?
shatred said:
hmm yeah about that, i tried frx05 with wistilt2 latest kernels but it doesnt work for me, i think its an problem with my user conf... can you perhaps send me your user conf from frx05?
Click to expand...
Click to collapse
Same for FRX04... It's in my bundle.
If you remove all of the ln -s and bind mounts, should work just fine...
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
Hey, I hope this is the right place to ask this, as this is a general rooting question that is not relevant for the device
Anyway, I have a few questions I hope you guys could answer me
1. From what I've understood, when I want create my own ROM, downloading the source also includes the actual OS right?
2. Assuming I'm creating a costume ROM, will I be able to:
a. Have a complete control over connections? As in, create an app that will be able to (with out notifying the user) turn off/on any connection? (BT / wifi / GPS / NFC or anything else)?
b. Make an app that will have access to the OS's file system?
c. Make an app that will be able to control the content of the device, as in, add or remove any given app?
d. Will I have access to the OS drivers? As in, will I be able to remove drivers or add costume drivers?
danduson said:
Hey, I hope this is the right place to ask this, as this is a general rooting question that is not relevant for the device
Anyway, I have a few questions I hope you guys could answer me
1. From what I've understood, when I want create my own ROM, downloading the source also includes the actual OS right?
2. Assuming I'm creating a costume ROM, will I be able to:
a. Have a complete control over connections? As in, create an app that will be able to (with out notifying the user) turn off/on any connection? (BT / wifi / GPS / NFC or anything else)?
b. Make an app that will have access to the OS's file system?
c. Make an app that will be able to control the content of the device, as in, add or remove any given app?
d. Will I have access to the OS drivers? As in, will I be able to remove drivers or add costume drivers?
Click to expand...
Click to collapse
1. Yes, you will download the source to build the OS, as well as the Device Tree, Kernel, and Vendor Files.
2.
a. Yes, that is possible, if you know how to make an app.
b. Yes, that is possible, if you know how to make an app.
c. Yes, that is possible, if you know how to make an app.
d. I'm not sure that I understand the question, but yes, you will have access to the BLOBS (Binary Large OBjectS) that are the drivers for your device. You can substitute them or build other ones, depending on your phone or platform.
I recommend that you watch through my video tutorial on how to build Android, and how to make device trees from scratch, as well as other videos about upgrading and making changes to apps that are in your custom rom.
You can find a link to it here:
https://forum.xda-developers.com/android/general/guide-how-to-build-custom-roms-kernel-t3814251
Hope that helps! :good:
AlaskaLinuxUser said:
1. Yes, you will download the source to build the OS, as well as the Device Tree, Kernel, and Vendor Files.
2.
a. Yes, that is possible, if you know how to make an app.
b. Yes, that is possible, if you know how to make an app.
c. Yes, that is possible, if you know how to make an app.
d. I'm not sure that I understand the question, but yes, you will have access to the BLOBS (Binary Large OBjectS) that are the drivers for your device. You can substitute them or build other ones, depending on your phone or platform.
I recommend that you watch through my video tutorial on how to build Android, and how to make device trees from scratch, as well as other videos about upgrading and making changes to apps that are in your custom rom.
You can find a link to it here:
https://forum.xda-developers.com/android/general/guide-how-to-build-custom-roms-kernel-t3814251
Hope that helps! :good:
Click to expand...
Click to collapse
I see, thank you very much for the info
I will watch the tutorial you provided
Hi everyone,
as title suggests, I'd like to "port" clean AOSP to be able to install and run it on the custom device.
Basically, the situation is following: I got a custom device, based on rockchip rk3288 SoC. The device currently runs Android 5.1 successfully. I'd like to update Android to version 6 (got AOSP sources and AWS builder image up and running), but the company that created Android v5 for us no longer exists.
Thus I am here to ask for advice(s) on how to proceed (or whether it even is a good idea to do that myself, given the fact that I have zero experience with Android ROMs development), possibly a step-by-step guide on what to do.
The question is, do I just find drivers for hardware components present in the device (usb hub, ethernet, etc.) and just somehow "link" those to existing sources (of AOSP) and just run the build with different parameters? Or do I need to build a whole new kernel for the given device-OS combination?
Thank you for any advice or opinion!
Well this is an interesting one. There are several routes you can take here.
If you have the kernel source code, and the source code for the drivers, you could probably build the kernel from source and use it to boot Android, however, as that's unlikely, you're looking at a more regular porting process, which usually consists of pulling the vendor blobs from the existing Android system, building AOSP/Lineage with those blobs involved, and hacking together a new ramdisk that HOPEFULLY will be compatible. It's a very long and very tedious process, but it's certainly possible.
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
abtekk said:
Well this is an interesting one. There are several routes you can take here.
If you have the kernel source code, and the source code for the drivers, you could probably build the kernel from source and use it to boot Android, however, as that's unlikely, you're looking at a more regular porting process, which usually consists of pulling the vendor blobs from the existing Android system, building AOSP/Lineage with those blobs involved, and hacking together a new ramdisk that HOPEFULLY will be compatible. It's a very long and very tedious process, but it's certainly possible.
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
Click to expand...
Click to collapse
Thanks for pointing in the right (or at least some) direction! I found some guide on porting ROMs which I followed, basically like you said. So I just replaced some files in System image. Will flash later today, so maybe I will get some results!
abtekk said:
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
Click to expand...
Click to collapse
So I was following this tutorial, although found some irregularities, let's say: For example, none of those 2 folders contained init.d/ directory, thus I didn't update it. Also, I haven't found META-INF folder therefore haven't updated updater-script.
Basically, when I did (or at least what I think I was doing was that I took /system partition from our current ROM, that is working on that custom device and replaced stuff in there by stuff from the new system I wanted to port. My idea from what I've read was that i took kernel (and boot/recovery) from the original, working ROM and "injected" the new system onto it. Is that correct? Is that what I needed to do? Because the problem is, I cannot boot into the system (might as well be because of Kernel version, because I am trying to port Android 6 on Kernel 3.10. which was used in the current ROM running Android 5). It looks like the device is stuck in bootloader, or "somehow doesn't know what to start" (sorry, I can't put it better), displaying only my device's logo.
When I connect it to the computer via USB cable, running adb devices shows me that device, but when I try to access shell using adb shell I got error saying that /system/bin/sh wasn't found, which made me thinking that somehow the /system partition isn't "linked" properly, like I stated in the beginning.
Was I doing everything correctly? Do I need to do something above that? (maybe do you know about some tutorial). I am trying to port AOSP 6 Android.
Thank you!