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.
Related
(new to AOSP)
I'm confused about the process of adding assets to AOSP (Android 10+) and using those assets in app development. For example, say I want to create my own AOSP build and add Boost (or anything) as a library, how then can I use this via the NDK when building apps (and share it with my team)? As opposed to creating a package (AAR or something) of boost, where every consumer would have to download it and build it into the apk/apb.
I suspect that the answer is doing this with the VNDK, but I still don't see how once I add a LL-NDK (I think?) library, how other developers would be able to access this with their NDKs.
Another way to ask the question, if some phone manufacturer, "SamPlusXel" creates their own version of AOSP, adds a bunch of vendor libraries, do they have a custom NDK they're developers can use to create apps to take advantage of all the vendor libraries they add (via Android-Studio)? Or is this just not something they do? Or can this only be done if they build their app along side AOSP?
(I think this question is similar in nature to Using NDK header when building vendor module with VNDK enabled)
I came across a new feature "New default packaging tool called zipflinger". Which is used to build your APK in android studio. i want to know what exactly is zipflinger and how does it work.
Zipflinger seems to be a zip utility within the existing toolchain rather than a replacement for the existing toolchain. You can find the ReadMe and source code here.
From the ReadMe:
The two main features allowing high-speed are Zipflinger's ability to edit the CD of an archive and its usage of zero-copy transfer when moving entries across archives.
I am familiar with this android architecture model:
But when I browse android repository at google git I just can't figure out exactly what files should exist in which folder. What exactly is the folder structure of the android git? Also another question, Is there any specific reason why 'Core Libraries' shown in picture inside 'ANDROID RUNTIME' block sits below 'APPLICATION FRAMEWORK' block? Keeping in mind how apps interact with 'Core Libraries' they should sit beside 'APPLICATION FRAMEWORK' block not below it.
I think here is the starting point to dig out the AOSP
abi: Minimal C++ Run-Time Type Information support
bionic: Android’s custom C library
bootable: OTA, recovery mechanism and reference bootloader
build: Build system
cts: Comptability Test Suite
dalvik: Dalvik VM
development: Development tools
device: Device-specific files and components
docs: Content of http://source.android.com
external: External projects imported into the AOSP
frameworks: Core components such as system services
hardware: HAL and hardware support libraries
libcore: Apache Harmony
libnativehelper: Helper functions for use with JNI
ndk: Native Development Kit
packages: Stock Android apps, providers
pdk: Platform Development Kit
prebuilt: Prebuilt binaries, including toolchains
prebuilts: Replacement for prebuilt
sdk: Software Development Kit
system: “Embedded Linux” platform that houses Android
tools: Various IDE tools
I hope it will be helpful for you
reference
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.
I have ported a few useful free/open source tools to Android. One is Octave and the other is gnuplot. They work together in unison to provide Matlab like capability for free (as in speech) and free (as in beer). I have packed them inside apps in an interesting way. Specifically,
1) I include the executable and shared libraries inside the libs/armeabi directory. Have to give them funny name because of android naming conventions.
2) I create directories bin/ and mylib/. I give them full permissions.
3) I create links from bin/ to the executable in the unpacked lib/ directory. I give them the correct names and full permissions.
4) I create links from mylib/ to the shared libaries in the unpacked lib/ directory. I give them the correct names and full permissions.
5) I then use ld-linux.so.3 which is one of the libraries now in the mylib/ directory and the--library-path option to point at the mylib/ directory to launch the executable from the Android Terminal Emulator.
Octave works perfectly in all version of Android doing this, but gnuplot gives this error when I attempt to launch it when running Jelly Bean only:
error while loading shared libraries: gnuplot: failed to map segment
from shared object: Operation not permitted.
So, why would I have this error for one of these two executables made the same way? Why only in Jelly Bean? Also, on JB, if I make myself the super user, it all works again.
Any thoughts on how to debug? I have confirmed that all files are there and have the permissions that I intended they have.
Please help. You would be helping a free, open source, educational and useful app if you do.
The issue was with how the executables were compiled. They needed to be compiled with a cross compiler that properly supported newer arm devices. The compiler I used generated executables that would only work on a subset of arm devices. The issue was not with the different versions of android.