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.
Related
I am trying to build AOSP for nexus devices.
The following page has a list of Source Code Tags and Builds:
https://source.android.com/source/build-numbers.html
You will notice that there are multiple builds / branches for the same device. What is the difference ? Is it because of hardware differences between different models of a nexus device (Eg: 16GB vs 32GB etc / Different LTE Bands) ?
How does one determine which branch will be compatible with a given device ? For example, if I synced MRA58K, and purchased a Nexus 5 D821, how will I determine that they are compatible ?
To understand what builds goes with what device you might be better off going to the Nexus Factory Images page. Each device has a 'code name' which as you guessed referred to particular models. For example the Galaxy Nexus had 4 versions due to a combination of radios and Google Wallet capability.
Once you know what device/devices you have for building from AOSP you'll need the proprietary drivers from Nexus Driver Binaries. Or extract them from a stock device.
It may also help to read: Android device configuration for AOSP
If you are trying to figure out what was the difference between branches i.e. between say 6.0.0_r1 and 6.0.0_r2 - 'git diff' is the tool. Unfortunately I'm not aware of any official summary of what goes into a branch.
On this page: https://source.android.com/source/build-numbers.html
You can choose any build, that supports your device. It is unclear what the difference between two branches is, but for example, I had no problem building MRA58K and flashing it to my nexus 5. Things seemed to work.
I also directly flashed the factory image for MRA58N on my device - again everything seemed to work.
I guess in general:
If the version number is different, then there are probably bug fixes, optimisations, etc.
If the version number is the same (but the build number is different), then it is unclear what the changes are, but you can probably flash both.
But since downloading a branch consumes a lot of bandwidth, in future I would just download the branch with a HIGHER build number, under there is a specific reason (you would know this if it mattered) to download the branch with a lower build number.
I am working on my hello-android app, which involves using the VpnService class to inspect traffic from specific apps (if anyone knows a better method, please let me know). Doing so requires the TUN/TAP driver, which is not included in the Verizon Galaxy Nexus, emulated Galaxy Nexus, or Verizon Moto X, and is also not available via the Tun.ko installer app.
The android source appears to be a bit of a fragmented mess, and I'm trying to find a good resource for understanding things.
Specifically:
Google maintains 8 kernel source repositories and loosely maps some of the devices to those repositories. Does a more comprehensive mapping exist somewhere?
None of the real-world android devices/emulators I am currently using have a /proc/config.gz. Verizon customer support has encountered this issue before, and indicated that the manufacturer produces the image (Verizon sends their bloatware to them for inclusion). The settings page indicates that the kernel was compiled by a bot within Google proper. The kernel includes some default configs in arch//configs, but using that requires knowledge of the appropriate git branch and also the appropriate config from within that directory. There have been some indications that for a galaxy nexus, one should use tuna_defconfig (though that file is not always present for the arm architecture). Does anyone know of a robust process for determining the correct kernel config to use?
The kernel version (g9f818de in this case) does not appear anywhere in the git logs for kernel source repository (omap in this case, which is supposed to be used for the galaxy nexus). Does anyone know how to map kernel build numbers to a source repository/commit?
Once I find the correct source/version/config, I'll also need to be able to load the module on a non-rooted device. Attempts with test-modules yield either Function not Implemented, or EACCESS (don't recall the message).
edit: The build number -> tag mapping indicated in https://source.android.com/source/build-numbers.html does not appear to apply to the kernel sources (at least not the omap repository)
Any pointers to thorough and accurate documentation would be appreciated.
Edit - Partial resolution to original problem, but questions remain
I spoke with the guy who wrote the OpenVPN app, and he was kind enough to point out that:
Basically all 4.0+ should work out of the box with the VPNService API.
Also the Android 4.4 emulator is broken.
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.
I can't find a clear list of what files needs developer's attention when i'm building a new Android image.
All the guides that i have found until now are way too generic or really old.
I'm supposing that i'm not interested on customize the platform, i just want a vanilla flavour but for my device only.
The answer is a bit complicated. You probably cannot build a vanilla Android for your device, unless your device is one of the google developer phones. Here is a list of the devices you can build Android for. The reason being that the manufactures usually does not publish all the parts needed to actually build Android for their devices.
But do have a look at the cyanogenmod project, and see if they support your device. They are kind of trying to make a "vanilla" android source for the devices which the manufactures themselves does not support. And they are doing quite a nice job, in my opinion. I have a custom build of Android 4.0 for my Galaxy SII running for months now, and it is working perfectly fine.
If you update your questions with the devices your are using, I can probably provide specifics on how you can build cyanogenmod for your specific device.
What are you trying to do ?
Declare some images or layout specific to only one device ?
You can't do it with a selector on a folder (-large, -fr, ...), but with some code. Check this out : http://developer.android.com/reference/android/os/Build.html#MODEL,
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