building android 4.1 from source targetting non-nexus device (galaxy s3) - android

I am interested in building Android for Source for a Galaxy S3 (but just knowing how to do it in general will be quite helpful)
I know how to do it for all the nexus devices in general, but I was wondering how to do it for some of the other phones. I know that it is possible because CyanogenMod and other modders do it. Usually when they announce them they include the source for the kernel.
How do you put the pieces together? Getting the android source code and the custom kernel together in something that can be flashed.

Generally it is not trivial. You need some binary files for hardware support (camera, WiFi, NFC, etc) and you need to figure out which those are and how to pull them from the device. The kernel is GPL licensed, so the the manufacturer will release their version/patches at some point, but you might have to wait. Then you have to create device build files to put all those together in an image for the particular device. Your best bet is to get CyanogenMod source and see how it is done in practice.

Related

Build AOSP ROM with CyanogenMod device files

I would like to compile my own pure AOSP (Android 5.0 or 5.1) ROM for my Samsung Galaxy S4 Mini (serranoltexx). I read something about this here but I have a few more questions. I searched for the nessesary files on GitHub and found this here:
Device tree
Vendor files
These are CM files so can I use them for an AOSP build? And do I have to change some of these files or can I use them to build my ROM without any changes? And also these files are for CM 12 (5.0.2) and maybe I want to compile a 5.1 ROM. Can I also use them for the new version of Android?
The device and vendor files are not really part of the AOSP, so you should have no trouble making the vanilla AOSP while including these specific trees. If a vanilla AOSP doesn't include your device in the available options, however, none of the source will use these device and vendor products to poll and use hardware features included in the 3rd party trees, so the end effect will be no new functionality.
Part of porting would be to make sure the specific projects in the AOSP use the specific hardware features when necessary, as there is nothing there to tell it otherwise. Though these may work to enable specific cameras, or graphics drivers, etc, you won't get any extra functionality, other than the fact the devices exist (which may be enough).
To include these projects in the build, you'll have to edit one of the main make files in the build/target/product directory of the AOSP. Ideally, you'd have your product specified here, but if you do not, you can add it to a generic makefile therein. See this post for info that will set you on the right path.
This is a bit of a hack, and ideally you would be better off editing the setup scripts to be able to 'lunch' for your device. The scope of this is well beyond this post, but is covered by Karim Yaghmour's excellent Embedded Android.
Hope this at least sets you off in the right direction!
You have to include CAF patches into AOSP rom. See, Google supports pixel,nexus,Mi A1, Motorola etc devices. You have to include you device specific proprietary and then you have to compile, You can boot AOSP ROM too goto codeaurora doumentation and icludin their patches.

What extra work is needed when compiling Android on real devices

I followed the guide on android.com and compiled the source code. Now it runs well in the emulator. There are some .img files so I think it may be viable to flash them on real devices.
But I see on the guide there is a 4th step, which is to compile some device-specific proprietary files. But my device is not on their list. So what extra work needs to be done if I want to flash the .img files to real devices rather than the emulator? Will the real devices get bricked? Thanks.
well -- that is the "difficult" part of making a custom ROM for a device. You need to have a complex understanding of the particular hardware that you're building for, and adjust and update the codebase accordingly.
That said -- a real device will (probably) not get bricked, but you will need to use the recovery image to put a working ROM back on to use the device again. Make sure you have a rooted device and a decent recovery on it (Clockworkmod)

Guidance regarding Android Kernel Porting from one device to other

I own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh

Is it posible to port Android for a Symbian phone

I have a Symbian based phone with a ARM Cortex-A8 processor (SonyEricsson Vivaz) and was thinking on how hard would it be to try and port the Android OS for it. Obviously Android runs on a myriad of devices with different hardware so I imagine it shouldn't be too hard to adapt it to SE hardware. Could some one give me a clue where to start or if this is even undertakable...
How much information do you have about the hardware in the phone ? Are you starting completely from scratch ?
Porting Android is not simple task. First thing is to have Linux running (preferably 2.6.32 for more compatibility with the latest releases of AOSP.
If you can find a kernel that can run on your phone, that's one big step. After that, you want make sure that the peripherals you want to use also have the right drivers : touch interface, LCD display, SD card, audio, video. The ones that are probably most difficult will be wifi, radio (GSM) and power management module.
If you get that far, you don't have that much to go anymore, a few more changes in the kernel needed for Android, be able to compile Android correctly file system, hook up a few things like buttons and correctly interface with the drivers mentioned above...
But overall, definitely not an easy task (IMHO).

Build android system from source

I've recently purchased Samsung Galaxy Android phone after using Openmoko phone for 2 years.
One of the reasons for choosing Android was is that it's open sourced.
I don't want to depend on phone maker to provide updates for my phone. I'd like to do it myself.
Right now I'm in research stage if it's worth the time or not. So here are the questions:
I found some tutorials for building ROM images from source. They tell that Android build script will ask for make of the phone before building kernel. Does it mean that all the phone specific stuff is handled by the script or I will have to do some voodoo before I can flash it onto my phone?
Drivers. How are they handled? Are they included in the source as binaries and added automatically (question 1) or will I have to dissect old firmware to get them and put in my build? I realize that would mean some problems with module/kernel versions compatibility.
Is there is something I'm not aware of that would prevent me from building my custom firmware or make it very time-consuming?
I'm not afraid of installing SDK's and toolchains, after all I'm an Openmoko owner.
It's gonna be a little more complicated than that.
On any consumer Android phones I've seen, the user doesn't have root access to the OS. So step one, would be finding an exploit to get root.
Even after you get root, all consumer Android phones "lock" the bootloader to prevent unauthorized OS images from being booted.
The Android OpenSource project only contains device drivers for a small number of phones (Google dev phones, possibly the Nexus One?). For other phones, the drivers are proprietary binaries that the manufacturer loads on the phone. They generally aren't available separately.
Even with all of those obstacles, some enterprising smart guys have managed to create custom "ROM's" that blend the OpenSource release with drivers ripped OEM install on the phone, etc. CyanogenMod is one of the best known and is available for several different Android devices, but unfortunately the Samsung Galaxy does not currently appear to be one of the device supported by Cyanogen.
I found an old link here to a guide to getting root on the Galaxy and loading a custom ROM on it, but unfortunately the ROM they link to doesn't seem to be actively maintained anymore. It might be worth doing some more exhaustive google searches to see if you can find anyone doing active development on the Galaxy.

Categories

Resources