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.
Related
I ask a question because I have been trying to solve problems with the keyboard for quite a long time without success. I want to understand how Android kernel modules are compiled. The task is to connect the USB WiFi adapter from Android via OTG and manage the terminal interface. But as an example for teaching fits perfectly. After reading many articles on the subject, I never came close to a solution.
But from what I read, I learned that:
There are two options: build the module into the kernel when compiling, or compile and load it separately (if it is possible that
the kernel will support this property).
The software required for compilation is: Android NDK, SDK.
You need the source kernels for which the modules are compiled (You can use a clean kernel similar in version and architecture, the
version must match up to the second digit after the dot).
Get the kernel assembly file with the device. (/proc/config.gz)
But that's all, I don't know what to do next. The device I use for testing Xiaomi Mi A1 (Android One) i.e. there are no problems with the kernel sources, plus active support for LineageOS, which is currently the main OS. Module sources that I want to build on GitHub marked "Android Support".
I don’t understand the procedure, is there a way to assemble like assembling a PC, i.e. for desktop it's just make, make install?! But I have no idea what to do in my situation.
If anyone has comments on the above, inaccuracies, errors, or any additional information, please let us know. It is also a very important question how to check whether the kernel supports loading modules on the fly or what needs to be corrected for such features, although without a ready-made module this is not so important, but still ?!
I would be glad for any information, I can’t figure it out myself anymore. information in various sources varies and there is no universal assembly method.
(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 followed official Google`s tutorial to build my own AOSP and succeeded in all steps: I have a "Pure AOSP version" running on a nexus emulator. https://source.android.com/source/building.html
The story is I have some rare device came with some Android version full of a pre-installed app's obviously I don't want. I want to port Pure AOSP to my device - without any improvements or new features (So, for example, I don`t want to know how to build CM git repo).
Is it working just add to my local above master branch correct files into /device/vendor/model and then under cwd of master branch execute $ . build/envsetup.sh ?
If so, what are the files and their content I need to put under /device/vendor/model? I found a lot of guides how to pull already existing tree of CM or something else (http://xda-university.com/as-a-developer/porting-aosp-roms-using-source-code) and including this Android device configuration for AOSP and looking on some git repo's of several devices, I tried to figure out the minimum complete set of files & their content but I didn't find a correlation. I think there must be the minimum complete set and there is programming reason for the existence of each file. And what I saw in existed git repo`s was this set + custom extras each developer added for his own reasons.
Aftermath How do I determine the Build name & Buildtype to execute $ lunch <Build name>-<Buildtype >?
How to integrate $ make otapackage in order to build the familiar one zip file to load via recovery like CWM?
This is following my previous post: Porting AOSP to specific hardware device, But here the questions are more specific.
Process of adding new device to AOSP:
First the device definition should be placed in device/vendor/model path. and then you should add AndroidProducts.mk file with COMMON_LUNCH_CHOICES which specify the name and the build type of your AOSP (Eng,userdebug,release) and PRODUCT_MAKEFILES which should point to you main device makefile.
What goes to device/vendor/model:
device/vendor/model contains the core configuration of the device itself such as Bluetooth configs, audio_policy configs, wpa_supplicant configs, device-tree, prebuilt hardware firmware or prebuilt images for boot or recovery. Also it contains The framework overlays that you can configure some of the framework parameter and for example decide the your android should have a navigation bar or what type of status bar you want. It also contains the SELinux policies that you can make rules for different processes, defines new contexts, and even ban some processes of running or having access to some resources. and at last it contains the makefiles that you can include what packages you need for you AOSP (aosp.mk) or what is you device configuration (BoardConfig.mk) for example what is the cpu architecture, gpu driver name or should it use hardware composer or does you system have wifi, bluetooth and if it has what is the address and the name of the required drivers. Also we have the init (in case that you want to add some additional changes to android boot process), fstab (describes the android partition and how should they be mounted) and ueventd and some udev rules that should be in this directory.
Look at the number 1.
For OTA update packages, first you need to generate the required keys that is essential for generating a zip for ota updates. if you are starting now , I suggest that you use fastboot. but if you want I put a link that shows how you can encrypt the required packages. when the encryption is done, you can generate your OTA image by this command:
img_from_target_files signed-target-files.zip signed-img.zip
OTA update guide: https://source.android.com/devices/tech/ota/sign_builds
I think what you are looking for are not OTA packages, but how to form the unified zip. OTA packages will have changes made after the system was installed once. My OTA package has ~500mb of files (payload) etc. This was Full Update. Incremental Updates are much smaller. However when I build a flashable package, I get ~2.6gb of files. Flashing varies device to device. QCom (Qualcomm) requires QFil Tool to flash the full system. Or you flash the individual images through fastboot. So I don't know how 4. works for you.
Looks like the original Answer was based on the poor documentation from Google. When it comes to AOSP, experience is must, documentation is never enough
I was inspired by this previous question, but I didn't get the whole picture.
I'm developing a kernel and Android system for a new device which is based on a commercial chipset platform.
The chipset vendor provides me with a 'fixed kernel code zipped','android proprietary sources','modem sources'.
All these parts are paired, E.G., I can't change(to some extent) one of the platform elements(kernel,modem,system) without effecting other parts.
It's also quite limiting, what will happen if there is a need for a newer version? I can't be sure i'll get vendor's sources for it.
So here are some flows I made:
=============================================================
Workflow1: - I don't need newer version, i need release device now!
1.Download the latest public kernel the chipset provider and his system
2.Add my own drivers into the kernel
3.Add proprietary source into the build
4.compile -> everything is already configured
5.debug -> little
6.patch -> little
7.release -> fast
8.give an update? -> fail!? - i need new kernel/system from chipset vendor.
==================================================================
Workflow2: I dont need the vendor
1.Download a clean android system from google/cyanogem etc..
2.Add my drivers to the kernel
3.Get kernel patches from the chipset vendor's sources
3.Build device directory for proprietary files
4.configure/patch the proprietary to compile with the system -> hell
5.face alot of low level bugs -> hell
6.debug/patch
7.miss deadline and get fired
Any idea how this actually works in major mobile device manufacturers?
Thanks!
I'm working for one of chipset vendors. We provide reference kernel and reference android sources for our costumers. But we provide them not as "zipped source", but as git repository, so costumers can see all patches we put in kernel/AFS/etc and merge them into theirs repositories.
So, in your case I recommend you to ask your vendor for access to a git repository. If it is impossible, I reccomend you to use workflow 1. If you need a major update (like switch from GB to ICS), you'll need new vendor's sources anyway. Minor updates can be done on top of existing sources.
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