Fork AOSP source - android

My team is looking to create our own custom ROM. I would like to base it on AOSP pie. Is there a way to fork or copy the code to GitHub?
I tried just using the Google repo, but it's bigger than my hard drive, so I can't clone it locally to push to GitHub.
We would prefer to base it on a pure Android, not another custom ROM

You can try directly form github:
https://github.com/aosp-mirror
Is mirrored from https://android.googlesource.com/platform/development.git
Hardware requirements:
Your development workstation should meet or exceed these hardware requirements:
A 64-bit environment is required for Android 2.3.x (Gingerbread) and higher versions, including the master branch. You can compile older versions on 32-bit systems.
At least 250GB of free disk space to checkout the code and an extra 150GB to build it. If you conduct multiple builds, you will need even more space.
Note: If you are checking out a mirror you will need more space as full Android Open Source Project (AOSP) mirrors contain all Git repositories that have ever been used.
If you are running Linux in a virtual machine, you need at least 16GB of RAM/swap.

Download the source following the guide here:
https://source.android.com/setup/build/downloading
The source is that big, so if your harddrive is too small you won't even be able to use a custom rom for reference.
For reference, the requirements tell you that you need 250GB for the source and 150GB for building. https://source.android.com/setup/build/requirements

Related

Samsung Open Source for Android, its usage?

I downloaded android device open source from Samsung OSRC.
It was composed with Platform.tar.gz and Kernel.tar.gz
It seems to do with building AOSP, found mk files.
I'm curious whether it can be used(directly or indirectly) to build newer android version for device and whether I have to build new kernel based on this files.
Thank you.
If you want to build for a newer Android version, you do not need to build another kernel. Just use the kernel provided by Samsung for your device (or the prebuilt kernel from your phone).
When porting a device to a newer Android version you need to adjust the init configuration (init.rc files from your product configuration located in device/<vendor>/<your_device>), but not the kernel specific parts of your init.rc files.
You also need to add the hardware specific vendor binaries to your resulting flash image. Therefore you can extract these libraries from your device. Most of them are located in /system/vendor/lib, but there could be also some libraries in /system/lib and all subdirectories.
It is also possible that some vendor binaries does not work within another software stack. Possible reasons are incompatible HAL interfaces and incompatible libraries. The solution for these cases can be very different and should be evaluated individually.
If you are facing such issues you can have a look at the CyanogenMod sources for a hint. There you can find lots of ports. Best place to look is the product configuration of the particular device. You can also look into another of my answers regarding this topic.

Android Source download

Hey guys I am new to porting android os. I am trying to download android source and wanted to know which git repository should I download for kitkat. And alos I want to download the source in GIT windows as I do not want to use linux terminal and repo for downloading the source.
Also, will downnloading https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-r1 give me the source or will https://android.googlesource.com/platform/build/+/master give me the source?
Note: I have a very limited download limit at high speeds so I only want to download the relevant source files. No prebuilt Images or and device Images. I just want to download the source for stock kitkat android and use it in ubuntu for further building.
I think that you don't understand the organization of the Android source. It is a forest of git repositories, maintained, as CommonsWare says, with a tool called "repo". Theoretically, you could clone each of the, approximately, 450 git repos, separately. I suspect it would be pretty hard to do.
When you download the source, you will get all of the versions, tagged appropriately. You need only checkout at the right tag.
You could try github, to download zip files of the branch you require. It also seems to have android kernel files, but you need to search for what you need.
The android kernel msm (for qualcomm) source code
https://github.com/android/kernel_msm
The android source code
https://github.com/android/platform_frameworks_base
The website says it is a mirror of the google server. Which means it should work.

How to understand the directory structure of android root tree?

I have downloaded the android source code. And i want to make some modifications to the source code to embed some functionality which currently does not exist. But the problem here is that i am not able to understand how the source code is organised, what kind of files could be find where. So if someone could help me understand that it would be really helpful.
Here is short version of what you will find when you download the Android source. I will leave out some minor directories and dig deeper into a couple of the important ones. Basically what you will get (based on the current Ice Cream Sandwich release), in alphabetical order:
Bionic - the C-runtime for Android. Note that Android is not using glibc like most Linux distributions. Instead the c-library is called bionic and is based mostly on BSD-derived sources. In this folder you will find the source for the c-library, math and other core runtime libraries.
Bootable - boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.
Build - the build system implementation including all the core make file templates. An important file here is the envsetup.sh script that will help you a lot when working with the platform source. Running this script in a shell will enable commands to setup environment variables, build specific modules and grep in source code files.
Cts - the compatability tests. The test suite to ensure that a build complies with the Android specification.
Dalvik - the source code for the implementation of the Dalvik Virtual Machine
Development - projects related to development such as the source code for the sdk and ndk tools. Normally not a folder you touch when working with the platform for a target.
Device - product specific code for different devices. This is the place to find hardware modules for the different Nexus devices, build configurations and more.
External - contains source code for all external open source projects such as SQLite, Freetype and webkit.
Frameworks - this folder is essential to Android since it contains the sources for the framework. Here you will find the implementation of key services such as the System Server with the Package- and Activity managers. A lot of the mapping between the java application APIs and the native libraries is also done here.
Hardware - hardware related source code such as the Android hardware abstraction layer specification and implementation. This folder also contains the reference radio interface layer (to communicate with the modem side) implementation.
libcore - Apache Harmony.
libnativehelper - Helper functions for use with JNI.
(Kernel) - not part of the default source download but you can get access to this code either by downloading it manually or by adding the repository to the repo tool. Contains the sources for the Android version of the Linux kernel.
Out - the build output will be placed here after you run make. The folder structure is out/target/product/. In the default build for the emulator the output will be placed in out/target/product/generic. This is where you will find the images used by the emulator to start (or to be downloaded and flashed to a device if you are building for a hardware target).
Packages - contains the source code for the default applications such as contacts, calendar, browser.
Prebuilt - contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
System - source code files for the core Android system. That is the minimal Linux system that is started before the Dalvik VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform
tools - Various IDE tools.
Beyond the above you also have the hidden .repo directory that contains the source for the repo utility. It also holds the manifest specifying what git repositories you want to track for this Android source project. If you have your own additions you could automatically track them by adding a local manifest here.
For modifications of the platform framework there are some instructions available in the device/sample folder of the source code tree. That will show you how to add APIs to Android without having to modify the core framework.

Android on Desktop tutorials/resources

I'm aware of the android-x86 project and as far as the end result (bootable live/install iso), I am looking to do the same thing. The difference is, I'm looking to do this with the ice cream sandwich branch from android master repo. Ice cream sandwich adds full support for x86 hardware and even sports a build target specifically for running the OS in virtualbox. So my question is, is anyone aware of any documentation for building and deploying to that target?
Just in case it's not clear, I'm not just using the android-x86 project because they haven't yet put up a build for anything later than android 3.
Okay so I was going to just delete my question because a few minutes after posting it, I found a tutorial! So, I figured I'd share this info here rather than just deleting, since that's a bit of a waste. Here is a link, plus an excerpt from the tutorial in case the link is ever lost:
http://ricston.com/blog/?p=1705
The second approach gives you direct access to the latest Android
code. However, it’s barely documented due to the fact that previously
you couldn’t build ‘out of the box’ an Android VDI (Virtual Disk
Image) with the AOSP. To build the Android VDI and install it in your
VM, follow these steps:
Get the Android source code from the AOSP site and follow the online
instructions to setup the environment.
When you are ready to build the project, execute the following command to set the environment variables for Make: “lunch vbox_x86-eng”.
Run “make installer_vdi” to
build the project. Make will build the project and produce a VDI named
“installer.vdi” located in “out/target/product/vbox_x86″. This VDI
contains Android plus its installer.
Create a Linux VM and add the
“installer.vdi” as an extra HD to the VM.
Start the VM and press “F12”
during bootup.
Select the HD which represents the “installer.vdi”.
Choose the first option, that is, “Android Install to /dev/sda from
/dev/sdb”.
When installation is complete, enter the command “reboot”.
After that, you should be able to launch Android from your VM.
I want to expand on this approach and end up producing a live CD rather than a VDI so I'm going to post this answer as a community wiki so it can be expanded by myself and others in the future.
Edit Nov 26/11
The above method of building right from the source alone is lacking features like proper keyboard and mouse support. Here is a link to an article (in Japanese but you can use google translate) of an individual who has compile the ICS sources with added in keyboard, mouse and network support. http://d.hatena.ne.jp/td2sk/20111125/1322192772
The precompiled VDI disk can be downloaded from here:
http://kie.nu/26G

Android Kernel modifying

I'm a Android application developer. For some reasons, I should change the Android kernel a bit. But I don't know anything about kernel. I will be appreciated if someone introduce me a website who explain android kernel modules and other info about it.
In the standard Android open source distribution the kernel is distributed as a pre-built binary in the mydroid/prebuilt/android-arm/kernel folder and the source code is not included. The kernel source was removed from the default manifest for two reasons as I take it. One is that it takes a lot of bandwith and diskspace for a platform component that most people will not work with much. The other reason is that since the kernel is built with the kernel build system and not as part of the aosp build system it makes sense to keep it separated. The common branch for the kernel is the one used by the emulator. There are also branches for experimental, msm (Qualcomm platforms) and Omap (TI platform) and maybe some more. If you want to use the Android kernel with hardware these may be more interesting to you.
Get the Android kernel either by adding it to your repo manifest or manually by running:
git clone git://android.git.kernel.org/kernel/common.git
The kernel built this way should end up in the arch/arm/boot folder of your kernel tree (where you put the code from git clone)
Note that I have used the default paths in the above description, you need to change them to what applies to your setup. It has been a some time since last time I tested this but I think it should work.
Go through the following sites which will also give u some ideas.
Android Porting, Android Platform, Android-Pdk,
Android porting in real target, Build-compile-linux-kernel-android
I guess that since you are talking about kernel programming you are also looking for ways to hook up new hardware with the platform and expose that functionality using your framework extensions to the applications. Hardware is basically added as a standard Linux driver so getting it to work under Linux is a good first step. How to hook it into the Android framework after that depends on what type of hardware it is. You could either use a native process to control it (compare the camera service or radio daemon in the current platform) or just spawn a thread in the application that uses your framework extension. For hardware that does not require that much attention plugging it in using an Android HAL library could also be an option

Categories

Resources