Can I test my AOSP built (Custom Os) on redmi5a phone (rooted)? And How (Explaination will be appreciated) ? Does it requires some specific built?
Usually, Android build for a specific device includes a huge amount of modifications by SOC vendor and OEM (OEM is Xiaomi in your case).
AOSP is a general SW project. And every device model has a different HW.
OEMs integrate SoC and board-specific SW drivers and configs into AOSP to make it run on a particular device.
Most probably you can't get access to the device-specific parts.
So the simple answer is: you can't make this kind of test.
AOSP vs Android:
The AOSP contains everything developers need to build Android but it doesn’t include everything you need for a finished smartphone. First, Google and the AOSP can’t provide kernel device drivers for every hardware configuration out there. By device driver, we mean the firmware required for a phone’s hardware, such as the processor or cameras. Phone and SoC manufacturers, such as Qualcomm and Samsung, have to incorporate these drivers into their Android build. This is partly why updates take time to trickle down from AOSP to the smartphone in your hand.
Related
I'm curious to know what changes are made to the Android Common Kernel before the final version of a device's kernel is built.
Secondly, I'd like to know if there are any devices that could run an unmodified Common Kernel.
1)Any changes the OEM wants. This can range from nothing, to bug fixes, to feature additions. Years ago it was common for them to patch RTL text so it would work, but only on models that they knew were going to those regions. Modern examples would be custom support for split screen before Google added it, or folded devices, or notches
In short- this question is unanswerable. An OEM can add anything they want.
2)If you really want that, build your own. That's the only way to be sure.
The changes made to the Android Common Kernel before being shipped on a device are typically done by two organizations: the SoC manufacturer (most commonly Qualcomm) and the device manufacturer. The SoC manufacturer adds drivers for the SoC, and may modify the kernel in other ways to use these drivers. The device manufacturer modifies the kernel to add any additional drivers (such as for the display, touchscreen, etc.) and also to create device tree source files that specify what hardware is in the device, and how the hardware in the device is connected. Additionally, the manufacturer can modify the kernel however they want to. Typically this is done to add support for special software "features" (which certain OEMs like Samsung are known for), or to add support for new kinds of hardware - which may have been necessary for the first Android devices with things like fingerprint readers, display cutouts, or foldable screens.
Yes, there are devices that can run the Android Common Kernel. The Android Common Kernel is just a fork of the mainline Linux kernel. Therefore, if a device's drivers and device tree are in mainline Linux, then the Android Common Kernel should run on it. Let's be more specific though. When it comes to Qualcomm SoCs, the Snapdragon 410, 450, 625, 630, 632, 636, 808, 810, 820, 835, 845, 850, 855, and 865 all have some amount of support in Linux kernel v5.12 (though this is not a conclusive list). This means that any Android device with one of those SoCs and a device tree in mainline Linux could theoretically boot the mainline kernel, and thus the Android Common Kernel. So, which Android devices actually have device trees in Linux 5.12? There are too many to list here, but here are a few: Google Nexus 6P, Samsung Galaxy A5, Xiaomi Poco F1, OnePlus 6T, Sony Xperia Z5. The device tree source files for these devices and their SoCs can be found in linux/arch/arm64/boot/dts/qcom/.
I see that many Android kernels comes without a loadable module support, how i can write and load a driver in this scenario?
For example i have a codebase for a driver that works under a vanilla linux kernel, how i can port this to Android?
You can't -- that's the exact reason there is no support for modules in the commercial phone. If the OEM disables module support, you have no option but to replace the kernel first. If you could just provide a driver, you would have instant unfettered access to the phone, which is what OEMs want to avoid.
If you are talking about a commercial phone and an existing piece of hardware, you are presumably talking about something connected via usb (or else bluetooth or wifi, etc). For these you can perhaps use the appropriate userspace api. For example, on phones/tablets that support usb host there is a host api which lets you access a device somewhat like you would with libusb, though there are limitations.
You should of course be able to get the source to the kernel for any device running a linux kernel; that's in the kernel license. Many vendors are unfortunately slow to make the releases - the glaring problem with source releases is with a bunch of off-label tablets based on chipsets whose manufacturer apparently does not supply kernel and toolchain sources to the device manufacturers, leading to a hand-me-down license violation.
But returning to commercial hardware, typically (in the tradition of Tivo) having the kernel sources doesn't mean that the device will allow you to install the compiled result, or that the bootloader will be willing to execute it even if you manage to flash it. Fortunately some of the phone manufacturers are getting better about offering developers and power users ways to unlock the bootloader of personal or test devices - devices sold by Google itself being the leading example.
I am new to android technology. Can somebody answer few of my question:
What are the similarities and differences between linux kernel and android kernel?
What is the minimum hardware requirement for mobile device to have android support?
Whether it is required to have a touch-screen mobile to run android technology?
Q1. The Android kernel is the Linux kernel with added device drivers for the hardware components that are not supported by the pure Linux kernel. However, there are also other differences. Quoted from here, and here:
The Android kernel code is more than
just the few weird drivers that were
in the
drivers/staging/androidsubdirectory in
the kernel. In order to get a working
Android system, you need the new lock
type they have created, as well as
hooks in the core system for their
security model. In order to write a
driver for hardware to work on
Android, you need to properly
integrate into this new lock, as well
as sometimes the bizarre security
model. Oh, and then there's the
totally-different framebuffer driver
infrastructure as well.
You may also refer to this page for an opinion on this matter.
Q2. You may take a look at the Android 2.3 Compatibility Definition
(I haven't read it). For 3.0 the requirements are (quoted from here):
1GHZ processor, 512MB RAM, a display
screen that is at least 3.5-inches in
size
Q3. No, your device does not need to have a touchscreen to be compatible with Android. Refer to the compatibility guide above, but this is also evidenced by the first Android testing devices, that were running android (picture).
I am using the default simulator, Can I make simulator identical to some common device
I mean one identical to HTC, one identical to droid motorla, one of samsung, dell, acer,..etc
Here identical I mean all the features that it provide.
Thanks
Yes labbeb Brother, you can download the various devices skin as Htc, samsung and mortolo droid from the following url
http://teavuihuang.com/android/
and unzip the skin which is downloaded and put in the android sdk directory/platform/android3/skins.
Like that do the same for android4,7,8 too
These different devices can be determined by the sets of capabilities that they have as well as which version operating system they support. That's what the "Android SDK and AVD Manager" is for. When you create a new device in the manager, you can select the target API version, screen resolution, and hardware supported in order to emulate a certain type of phone.
For instance, if I was developing on an HTC Hero I would want to ensure that I specify the target API as Android 2.1-update1 - API Level 7 since it is the highest that the Hero supports without a custom ROM at the moment.
Another example is the upcoming Motorola i886. It is an Android OS phone that does not have a touch screen, so for it's hardware you would add the property "Touch Screen Support" = "No".
Generally speaking, a simulator is just that -- it can't provide full and true emulation of the target hardware. To get all features, nuances, bugs, skins, add-ons, pre-installed apps, and whatnot that the target hardware comes with you must acquire the target hardware. There's no full-proof alternative to this yet.
You can, however, simulate many of the important characteristics of the target device. Tilsan linked to a good resource for downloading a whole bunch of skins. You can create your own, too (see
http://mobile.tutsplus.com/tutorials/android/common-android-virtual-device-configurations/).
The default or generic simulator is to display the general functions and may not be specific to any present or future model in the final form. Only authorised developers, manufacturers and industry organisations like OHA the open handset alliance are permitted to develop for specific models as some of the internal hardware including the processor may be proprietory or patented for use in specific countries and open access to the internals could be a breach of rights protection. When using API and APP type environments as application programmers and hobbyists then the development kit can be specific to models and is provided by the brand name or manufacturer by download or on CD and is a concession to the user community.
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.