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?
Dear Community,
Please read the following before starting on reading on.After lots of requests I decided its time to provide every oncoming developer with a short guide on how to start developing for our beloved Mimmi (most stuff applies also for Robyn or other Android devices).
I'd also like to get a few words passed on what actually in most cases developing is, so let's start with the basics:
There is different ways of developing there is people like Cyanogen Mod which provide you with a bunch of changes to the original Android source code which enables new features, adds hardware support or make things easier for specific device developers. However these people at Cyanogen are often not fully recognized so please make sure to thank these people as well. Besides that there are ports of similiar devices which will not be explained in this tutorial but also these developers usually put a lot of effort into their roms however since the source is already compiled changes are usually of a cosmetic nature. In this tutorial however you will find the basics on how to compile kernel or android from source in order to build your own changes into your own rom, which btw would have never been possible without the developers porting xrecovery or cwm to our devices so please give these people a big thumbs up as well after reading on.
What do I need/Environment set up
Most people have issues on setting up a the heart of your Developer Carreer, the Environment. What I strongly advise is to have at least a bit knowledge of the main usuage of Linux Distributions and also programming languages. Without these you will most likely fail at one stage or another to make a successful build.
So lets evaluate what you need :
Linux Distro (i.e. any Ubuntu should do well)
a VM or native Linux
quite a bit of Linux skills and programing skills
Time and a high tolerance of frustration
Sufficent RAM (at least 4 GB, more is advised otherwise use native Linux)
If you know how to install a native Linux Distribution you can probably skip this part, I will explain how to use a VM to fill the basic needs and keep your development area seperated from you most likely otherwise needed productive platform.
The following Steps are just keywords, if you want to develop you will need to inform yourself how to achieve all this yourself, there's lots of tutorials out there.
Step 1: Download a VM and a Linux Distro
Step 2: Install VM Software (i.e. VirtualBox or VMWare Server)
Step 3: Install the Linux Distro in VM (you'll need at least 6 GB Swap and 50 GB or More HD space to have enough room for experiments/seperate syncs/etc...)
Step 4: Figure out if you installed 32 Bit or 64 Bit (you'll need this later)
Step 5: Boot your new VM based Linux Distro
Step 6: Set up a Share Mount between your host and your VM
Step 7: download the Android Source/Cyanogen Source of your desire (i.e. : repo http://**** -b gingerbread) into a folder for you desire (the folder should represent your ROM's/Kernel name)
Building a Kernel
Building a Kernel is one of the easier parts considering the full source code is available for download. Sony Erricson Open Source Dev Website is providing fully funtional Kernel sources usually in the tar.gz format. Download the source code and extract it, or if you use a git based repository clone or checkout the project into a folder of your desire.
The next step, is not mandatory but advised to sync the entire Android repo/CyanogenRepo as the repo also provides the Cross Compiler toolchain which is needed to compile for your device.
Once everything is finished downloading you should check the following path in the Android repo : platform/linux-x86(orx64)/prebuilt/toolchain/arm-eabi-4.4.3/bin/ this is the cross compiler we will use to build the kernel itself, its vital to have the compiler present, the version number maybe different though.
Lets start with the building process itself:
Code:
cd kernelfolder
cp arch/arm/configs/semc_mimmi_defconfig .config (the command maybe change to copy another default config file, it creates a file in the root of the kernel folder called ".config"
ARCH=arm make menuconfig (this will bring up the kernel configuration menu for arm devices)
In the Menu Config you can change/add features to the Kernel once you are done safe the kernel config. Now your Kernel is ready to be compiled:
Code:
ARCH=arm CROSS_COMPILE=/pathtoandroid_source/platform/linux-x86(x64)/prebuilt/toolchain/arm-eabi-4.4.3/bin/arm-eabi- make -j4
This will start a compile with 4 Jobs using the Architecture ARM and the Cross Compiler arm-eabi from the Android Source Repo. Once finished you'll find your Image in your kernel folder under arch/arm/boot/Image. Now you'll need to build your own ramdisk this is covered here at xda as well azuzu has also build a tool available to download.
Follow the instructions to create the kernel.sin which now can be flashed with Flashtool. Changes to Kernel source will now be available to your compiled Kernel. How to change the Kernel source is beyond this tutorial but programmers in C will have fun there.
Building Android from Source
Now lets get started with the more advanced part and the most frustrating part in the beginning. The easiest way to build for the mimmi would be to sync the Cyanogen Gingerbread source code. Which can be checked out using the repo binary (see tutorials on googles website also which packages for which architecture (x86 or x64) are addionally needed also the correct java version is important)
Now lets cut to the chase.
Code:
repo sync -u http://github.com/CyanogenMod/... -b gingerbread (or froyo or another branch you would like to check out)
once your repo is synced (you could also add "-j8" to enhance the speed of the repo command, it will take quite a while) you are almost ready to start. If you synced an AOSP source you will have the get your device and hardware libraries ready first. This means you will have to port i.e. the device project and hardware project (mimmi and msm7227-common folders from CM and also hardware folder from CM) to the AOSP source. It makes sense to port these to your AOSP source since they are the most complete so far. For Camera libraries you can sync from doixanhs repo the libcamera-5mp.
Now lets get a short overview over the Android source, it contains of various folders:
frameworks
device
vendor
hardware
platform
external
These are the most interesting, frameworks folder holds a bunch of android libraries and files which provide the functionality however often you will need to change a few things here and there since the mimmi is unique in its hardware. Everything you change will need to be approved with the following command:
Code:
make update-api
This will add all the functions, variables or anything else to the current-api.xml and ensure its available at build time.
The device folder holds device specific files, build-configs and so on. Lets look at some of the important files:
Code:
device/semc/mimmi/overlay/frameworks/base/res/res/values/config.xml/power.xml
The two xmls hold configurations of the build process which are device specific either LightSensorWarmupTime and so on the full list is in the root folder of frameworks/base/res/res/values/config.xml <-- any part you feel you need to change copy the lines from there and change in you device specific config.xml.
Now to another file:
Code:
device/semc/msm7227-common/BoardConfig.mk
This files olds the device sepecific configurations for the ARM, WLAN, etc.
Look at all the files in mimmi and msm7227-common and figure out what they do, google of course will guide you on that.
Also take a look in the:
Code:
vendor/cyanogen/products/
folder and find the mimmi config and get familiar with this as well. Nobody will be able to help unless you face specific issues. Developing is learning by doing and a lot of self teaching and the will to understand all of this yourself. We can't teach but you can learn. Specific questions however are usually proudly answered by most devs if they have already figured it out.
Lets start building now, first you'll need to get your lunch command to know which devices have makefiles (I always do it to be sure)
Code:
source build/envsetup.sh
This will now add all the known devices to your lunchcombo (the devices are usually definied in the vendorsetup.sh pointing to the makefiles)
Code:
lunch
Will get you the list of available devices and will wait for user input to select the device you want to build, choose the mimmi.
Code:
make -j4
This will start the building process with 4 jobs.
Now its time to get a coffee. Usually you will have a bunch of different issues on this part but the CM source is pretty good and you might be lucky there.
Now lets look at typicial errors:
Code:
symbol not found : means a variable in used in the code has not been defined, before its use this one is a tricky one
try to locate the source file and find the line the compiler is complaining about. Now check in the framework usually in
res/res/values or layout look for the type of the erros (String or array) and look in the corresponding xml if the variable
is present. Now look in vendor/cyanogen/overlay if your variable is also declared there and so on.
Code:
function not found/function of incompatible types : also a tricky one, you might sync a repo and made local changes to
a file and suddenly your functions another file calls are not present or have changed, find the differences between them and
think about how it has changed, maybe add the function again or maybe another function does the job now. you will need
to locate the changes compare them and you should be fine again
Code:
No Rule to make target: this one is usually due to a missing/incomplete Makefile you might need to add manually or
if you don't need it anyway the easiest would be to delete the not building folder
Once your source has finished compiling you will find you system image in:
Code:
out/products/mimmi/system/
As of now unfortunately its still missing a few files here and there. Compare ROMs and Compare what might needs to be added. However I advise not switch libraries around its best to use your own libraries. However sometimes you will face issues when doing this so start with the files created there and just add the recovery and ramdisk to your rom. Now observe via adb if everything is running. This will take time and add one missing lib after another one and reboot, after each (like grallocs or librils or fm libs and so). This is basically a debugging part of the job.
You will now add one by one more functionality, but keep in mind to use logcat to see what goes wrong, maybe some stuff can be changed in the source rather then randomly adding stuff.
also this one just in case.
Hey there c: As always, you come surprising everyone with your stuff haha Good job on this one, I think it is always good to have some tutorials from the people who build specifically for our Mimmi's
Before reading this, I wanted to get started on developing and I went to Android's official developers site, I did some steps, now I have the complete source of Android here (I use Ubuntu 10.04, the LTS version... Dunno if telling you that it is LTS ver. really matters, but just in case) andthe whole environment ready to build. Now, reading at this, I realize I don't have 4Gb of RAM on this "old" (2007..) notebook. Anyways, the thing is: I followed the steps listed here, but when I wrote this command-
Code:
$ make -j4
-the terminal started to execute files, or something... I'll add a screenshot at the end about this. It has been 3 days since that, and the terminal is still doing the same. I know developing requires a lot of patience, but... 3 days? Is this normal?? I have looked through the Internet for problems with this command, but no one seems to have talked about it.
Thanks for your time, work and effort for the community, we really appreciate it c: Bye!
Link to the Screenshot:
http://i259.photobucket.com/albums/hh313/link_4ever/Screenshot.png
The 'make -j4' uses 4 threads to compile everything, if your notebook does not have at least an hyperthreading-technology enabled CPU, well, that's to expect when building an entire OS, plus you don't have sufficient RAM, I do have 2GB and a DualCore CPU and it takes at least 1 hour to compile an average desktop kernel with that same command. I have not tried to compile android, but I think that it will take at least 4 hours to compile everything. Just my thought.
RozenTensai said:
The 'make -j4' uses 4 threads to compile everything, if your notebook does not have at least an hyperthreading-technology enabled CPU, well, that's to expect when building an entire OS, plus you don't have sufficient RAM, I do have 2GB and a DualCore CPU and it takes at least 1 hour to compile an average desktop kernel with that same command. I have not tried to compile android, but I think that it will take at least 4 hours to compile everything. Just my thought.
Click to expand...
Click to collapse
Thank you for your answer! Just ten minutes ago, the 'make' command finished ! And about my notebook, it is just like yours: 2Gb RAM and Dual-Core CPU, I'm not sure but I think it runs at 2,8 GHz. And also, like I said earlier, I know developing takes time. I know how slow processes can be, in fact, there were commands previously that took 1 hour or more to finish their tasks. 1 hour, 4 hours, it's ok but... 3 days? Isn't it a bit too much xd?? Now I'm afraid to turn off the computer because I don't want to compile that thing again hahaha
the "-j" option depends on the number of (virtual) cores you have.
get the number:
Code:
grep processor /proc/cpuinfo | wc -l
if you have native linux and like to work on the machine I recommend do lower the number at least -1 otherwise get a coffee and keep hands off the build process
b
make -j4, lol. Many people do not have. 4 cores on the processor
paul-xxx said:
make -j4, lol. Many people do not have. 4 cores on the processor
Click to expand...
Click to collapse
This parameter refers to threads instead of hardware cores
Sp4rrow said:
This parameter refers to threads instead of hardware cores
Click to expand...
Click to collapse
ok. probably a mistake. but still. I always use 2. it brought to me the best results
I use j6
And also j refers to jobs everybody may change to what they want. For kernel i build with j12.
If you know better like it seems you always do write it down.
Sent from my U20i using xda premium
I can't find any 2.1.1.A.0.6 Sources. Link to the sources you use slade?
http://developer.sonyericsson.com/cws/devworld/search-downloads/opensource?cc=gb&lc=en
should be:
x10_x10mini_X10minipro_x8_eclair_2.1.A.0.435.tar.gz
Stock Kernel with only CWM5 installed...
Slade i want some help from you. how can i embed CWM5 in the stock kernel without any other changes to it??
i want a stock kernel with nothing changed in it only CWM5 installed in it. how this can be done???
i forgot to say the most important thing!: Thank you very much for your work and effort Slade
I just came to the configuration menu of the kernel. i see there are options predefined for the mimmi, but how can i optimize it more, there are soooo many options, and to tell the truth i don't have a clue what they do
I apologize if this has been covered elsewhere, I've searched and come up empty.
Is there any way (or what is the best way) to visualize what specific files within a kernel source are inter-related, what files take priority over others, etc? For example, I want to trace from top to bottom the related kernel source files & actions that would be triggered by insertion into a headphone jack, and dig through the code as much as I'm able and try narrowing down the source of a problem. I can (and have) poked around in github, and understand how to compile the kernel, but don't quite have a grasp of the hierarchy of files, drivers, etc. within the source.
If there isn't a way to 'map' out a specific kernel source, has anyone seen a generic flowchart or 'map' created in general for visualizing the inter-relationships of source files within android kernels? Can anyone recommend a good book for that?
Really new at this. I've figured out how to compile a kernel, pack into a boot.img, edit a ramdisk, etc., within the last few weeks, but this is a major roadblock in my understanding of kernel source code.
I eventually found this if anyone else has the same question:
Interactive Diagram of Linux Kernel: http://www.makelinux.net/kernel_map/
Diagram of Android Internals: http://www.makelinux.net/android/internals/
Hi everybody,
I'm currently in process of making my first builds of CM13 for my A310F.
The repositories for CM are unofficial, maintained by a user i tried to get in contact with, who didn't respond yet.
Now, while the stock kernel sources of MM are open sourced and a few hacks were already done in the unofficial CM repositories, the CM device/vendor/kernel sources are already a bit deprecated with a few erroneus configurations in the device repo, so I'm on my way to clean it up a bit.
Currently CM itself builds, but after booting most of the hardware features are broken and they were using the 5.1.1 kernel instead of the 6.0.1, and the blobs were not taken over correctly, or not all blobs were taken.
My question is now, how are you managing to get the correct list of the blobs needed? What is the best way to find out which blobs i need to take from the system.img?
I'm wondering the same thing. How do you know which blobs to pull in the first place when you're trying to build up the first rom?
There will be some dlopen errors for missing files in the logcat. After resolving them, it's mainly trial and error
Believe it or not, there is a method to this, and it requires some trial and error and a good sense of knowing what android needs to boot. If you look at the start up classpath and are just generally aware that the modem/network connection and filesystem utils need to be executed first (though for some reason binder and zygote can't start them themselves, despite the fact they are to running under init, but whatevs) so after bootloader hands off to kernel, you can go through the ramdisk and make sure all the on boot, on init on fs related libs/binaries are present. If you use a qcom device, just assume any lib or binary that starts with "libq" or even just the letter "q" is proprietary and required. Qcom is a bit full of themselves (ironic were talking about cm here) but anyways then there's the rild/crypto/fs libs and binaries. rngd, rmt_storage, rild daemons and anything that starts drmsever or netd will be required as well.
You can get significant hints from boot logs as well.
Aside from that, just keep note of what isn't produced by the aosp tree yet is present on the devices stock system, then determine how important it looks for android to able to start up
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!