Difference between GSI and "normal" ROMs? - Android Q&A, Help & Troubleshooting

Hi guys, could any of you explain to me what is the difference between GSI based and "normal" build ROMs?
I thought most custom ROMs are based on AOSP/GSI, but right now many Android 10 ROMs for one of my devices (Lenovo P2/kuntao) are popping up and most of them are getting a lot of hate for apparently being based on GSI and are not "proper" ROMs. People are not giving any specific criticism, just generally whining, like those ROMs are useless or something.
The only difference I see is for some reason the GSI ROMs need F2FS format instead of EXT4 that is standard for other ROMs for the device.
Thanks.

To my knowledge, GSIs when properly implemented for a device are as good as a Device Specific ROM or what you call a "normal" ROM.
Usually GSIs are made for a wide-audience of devices. So the usual reason is that when a bug only available in a specific device is found. It usually isn't fixed by GSI devs.
However, Device Specific GSIs are actually made for the device it's running on. So small bugs will be fixed.
Usually though problems come from a bad vendor implementation. So if your device has a bad vendor implementation. I guess that would be a cost for concern. You can create your own but you'd have to wait for developers to create it.
They may be mad about limited Magisk Support. Since Magisk currently does not support GSI ROMs. But other than that, I don't see why GSIs get so much hate.

In a Treble world, don't all ROMs technically include a GSI? Because anything living in /system and distributed by a system.img file can actually be run as a GSI on any device that is Treble compatible.
However, right now it's probably like you say, vendors (and enthusiast ROM makers) may not completely adhere to the rules set by Android/AOSP, such as putting the correct things in the system, product, vendor and odm partitions. They include nasty hacks to solve some idiosyncratic bugs for their specific device. Nothing wrong with some nasty hacks, but they should put them in the right place (in product or odm partitions). As such, in theory there should be no need for separate system images any more.
In such a world, I suspect that indeed in the near future we will only load the GSI of our choice for all devices. We will rely only on whole ROM packages when drivers (vendor partition and optionally odm) need to be updated. This is needed for example for increasing the necessary HAL version for future Android releases, possibly shipped with an updated product partition, if the device requires some specific apps or functionality. So instead of full ROMs we can then just have "device support packages" for phones that aren't already fully fit for GSIs, or need updates for future GSI architectures.
In that case we can even have OTA updates for only the GSI, published by the specific OS maker (e.g. AOSP, LineageOS, /e/, GrapheneOS, CalyxOS and many more). Specific ROM developers then need only make sure that their device support package is up to snuff. When releasing a new OS update or version, the same OTA update can then be immmediately pushed to any device that runs it. Wouldn't that be great?

Related

Rooting

Do Not Post Question in General Post in Q&A CLOSED
I'm not super educated, but I'm pretty sure I can explain the fundamentals of it (correct me if I'm wrong anyone)...
The Android operating systems runs ontop of a linux kernel... and just like any other linux distribution, there is a particular set of low level system files that you, the user, by default, don't have access too. This is to prevent you from breaking anything, as well as to prevent malicious software/intruders to compromise the security of your file system.
These same low level system files, however, are useful for many things. In order to make changes to a lot of things (overclock your processor, tweak speed and battery life, sometimes sideload applications outside the market; although most devices let you do this without rooting now, and in most cases install a non-stock system image).
This system image is known as a ROM; a rom can be pulled from another device and then modified to work on your own, or in some cases can be an original release from Google (Known as an AOSP) which is then 'cooked' by a developer to work on your device.
If you're familiar with reinstalling or installing Windows, it's a pretty easy concept. Once a device is rooted, a custom recovery can be flashed to the device. This custom recovery allows you to flash over your stock system image with a new ROM.
Rooting is basically taking control over your device for what can be installed, deleted, or altered.
Here is a link to give you much more info on rooting:
http://m.androidcentral.com/what-rooting

[Android ABC] What's a Bootloader,ROM,Kernel,Firmware,ADB,Root etc

Android ABC​
I've gathered some info for newcomers to the Android world.
Copied over from my thread at androidforums...
I've tried to keep it relatively simple. So if you want more info, follow the links!
And please if you want anything added, do post!
I hope this helps someone....
Inventory:
Bootloader
Kernel
CWM
Firmware
Flashing
Rooting
Custom ROMs
ADB
Baseband
Dalvik
init.d​
What's A Bootloader?
Taken from: Android 101: What is a bootloader? | Android-Does.com
In literal terms, the bootloader is code that is executed before any Operating System starts to run. Bootloaders basically package the instructions to boot operating system kernel and most of them also have their own debugging or modification environment. Think of the bootloader as a security checkpoint for all those partitions. Because if you’re able to swap out what’s on those partitions, you’re able to break things if you don’t know what you’re doing.
As the bootloader kicks off before any piece of software on your device, it makes it extremely processor specific and every motherboard has it’s own bootloader. This is one reason that all Android phones have different custom ROMS developed due to high variance of processing hardware present on the device.
Android Bootloader
Every Android phone has a bootloader that instructs the operating system kernel to boot normally. But you need to understand one thing here that as Android OS is an open source OS and is available on a variety of different hardware, every manufacturer has their own version of bootloader specific for the hardware present in it’s environment. At its most basic level, your Android smartphone is like a hard drive, made of up several partitions. One of those partitions holds the Android system files, another holds all the app data you accumulate (which is how you’re usually able to update without losing all your stuff), and others to do more behind-the scenes stuff.
A lot has been said about bootloaders being “locked” and even the developer-friendly Nexus devices shipped with a locked bootloader (Nexus devices and a couple tablets are easily unlocked with a single command).In fact, a lot bootloaders are locked and encrypted, meaning simple commands like “fastboot oem unlock”, won’t do a thing.
Why are Bootloaders Locked?
A bootloader is usually locked on an Android device because although it’s an open source OS, still the manufacturers want you to stick to their Android OS version specifically designed for the device. In order to apply this concept, manufacturers lock the bootloader. With a locked bootloader on Android devices, it is virtually impossible to flash a Custom ROM and forced attempts void warranty as well as usually end up in bricks. Therefore, the first step is to always unlock the bootloader.
Why keep a bootloader out of reach? One of the biggest reasons is that the carriers and manufacturers don’t want to have to support hacked phones. The other is that a lot of time and money is spent developing these things. HTC Sense ain’t cheap. Neither is TouchWiz. But Samsung and HTC both have managed to find a middle ground with the modding community, and pressure is on other companies to do so as well.
Also a very good read about bootloaders: http://www.tested.com/news/feature/1879-know-your-android-bootloaderwhat-it-is-and-why-it-matters/
---------------------------------------------------------------------------
What's a kernel?
Taken from: Android A to Z: What is a kernel? | Android Central
A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
---------------------------------------------------------------------------
What's CWM?
Taken from: AddictiveTips » Blog ArchiveWhat Is ClockworkMod Recovery And How To Use It On Android [Complete Guide]
ClockworkMod, abbreviated as CWM, is a popular custom recovery for Android phones and tablets developed by Koushik Dutta (Koush), a well-known name in the Android dev community. ClockworkMod recovery allows you to perform several advanced recovery, restoration, installation and maintenance operations on your Android device that aren’t possible with the stock recovery, and is one of the most common ways used to gain root access, back up device data, install a custom ROMs, kernels, themes, mods and more. However, for anyone new to Android customization and hacking, some of its options might prove to be a tad confusing. In what follows, we will cover all that this recovery is capable of doing, and how to do it.
About Android Recovery
All Android devices ship with a recovery console that is basically a partition on the device’s internal memory and can be booted into. The stock recovery of almost all Android devices provides a few basic yet handy options that allow you to factory reset your device and also to recover its operating system using an official ROM in zip format, but that’s all you can do with it. That’s where a custom recovery comes handy.
A custom Android recovery basically replaces the stock recovery with one that lets you do all you can do with the stock recovery, plus a plethora of more options to give you a lot more control on your device. With a custom recovery, you can install official and unofficial ROMs as well as other updates including apps, themes, kernels etc. using zip files, wipe not just user data but pretty much every partition on your device, mount the storage card for USB mass storage access without leaving recovery, partition your SD card, wipe Dalvik cache and battery stats, fix permissions, perform, manage and restore backups and so on.
Introduction To ClockworkMod
ClockworkMod recovery is one of the most widely used custom Android recoveries that is available for most mainstream Android devices. It is our custom recovery of choice here at AddictiveTips and almost every custom ROM that we install on our devices is done using this recovery.
ClockworkMod recovery has been developed by Koushik Dutta (also known as Koush) – the same guy who brought us the Android ROM Manager. He can be found at his blog hacking away at Android devices and at Twitter.
CWM options explained:
[REF] CWM - Clockworkmode menu options & Partitions– GENERAL KNOWLEDGE - xda-developers
---------------------------------------------------------------------------
What's Firmware?
Taken from: What is Firmware, Rom and Firmware Flashing ? - I Teach Android
What the heck is this firmware? Definition of firmware is permanent software programmed into a read-only memory
In Simple words, you can understand it like windows for pc , in case of android we are going to do same thing – installing firmware (Froyo,Gingerbread, ICS, Jelly Bean etc.) on your phone. All phones have their different firmwares and installing tools regard less to the Andriod version (Froyo,Gingerbred). So never think that we can install any firmware on any android phone like we do in PCs.
Wiki link for even more info: Firmware - Wikipedia, the free encyclopedia
---------------------------------------------------------------------------
What's Flashing?
Flashing refers to the overwriting of existing data on ROM modules present in an electronic device with new data. This can be done to upgrade a device or to change the provider of a service associated with the function of the device, such as changing from one mobile phone service provider to another or installing a new operating system.
In simple words flashing is called installing firmware on your phone.
---------------------------------------------------------------------------
What's Rooting?
Taken from: Rooting for Android: What, why and how? | Ubergizmo
WiKi link: https://en.wikipedia.org/wiki/Rooting_(Android_OS)
When carriers and manufacturers sell you your device, it is almost certain that the device would come with certain software restrictions in place. There are a variety of different reasons why they might do that – some claim that this is done to protect the user, preserve the device’s warranty (this policy will vary from manufacturer to manufacturer), prevent users from getting rid of carrier bloatware apps or simply because the manufacturer would prefer if your device was distinguishable from the competition based purely on its user interface (i.e. Samsung’s TouchWiz, HTC Sense UI, etc).
Whatever their reasoning may be, chances are if you are looking to customize your device on a deeper level, you’d be out of luck and this is where rooting comes into play.
Rooting is essentially a process that allows users of smartphones, tablets or other devices running on Android to gain “superuser” access to the software. This will allow the user to perform administrative tasks such as writing to locations normally restricted by the system which in turn will allow for deeper customization. For iOS users, rooting on Android devices could be thought of as a close equivalent to jailbreaking your device.
---------------------------------------------------------------------------
What are custom ROMs?
Taken from: Custom ROMs For Android Explained - Here Is Why You Want Them
A stock ROM is the version of the phone's operating system that comes with your phone when you buy it.
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way.
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, strip them of garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow.
---------------------------------------------------------------------------
What is ADB?
Taken from: Android 201: What is adb? | Android Central
According to Google "Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device." That certainly sounds like Google, doesn't it? To put it simply, adb is two different applications -- one running on your computer (Windows, Linux or Mac) and one running on your phone. When your phone is connected, and USB debugging is enabled, you can issue commands and communicate with the phone using your computer screen and keyboard.
Your Android phone uses a modified Linux kernel and tools as a base. This means that quite a few Linux commands can be sent via the adb server (the one running on your computer) to the adb client (the one running on your phone) and they will be executed. In our example picture, I've sent the "top" command over the wire to my phone, and my phone sent me back the information and printed it to my terminal.
This can be awfully handy for debugging things that aren't going right, as well sending those weird commands you need when you're hacking away in the middle of the night. Chances are, if you aren't actively debugging something or trying to break hack at your phone, you won't have much use for adb. And that's OK -- there's more than one way to have fun with an Android device.
----------------------------------------------------------------------------
What's baseband?
Baseband is the Radio or Modem version depending upon the Phone Model, Carrier and Android Software Stack version. The Radio/Modem file is flashed via Recovery tool (other options are ADB/ODIN). The mismatched Radio/Modem and ROM will lead to things not working. You need to find the matching Radio/Modem for the particular ROM you are running.
The radio firmware controls basic low-level functions like network connectivity, Wi-Fi, and GPS. Upgrading Radio firmware will fix connectivity issues, increase range or performance, decrease battery usage, etc. Incorrec tRadio frimeware can disable some functions in your phone such as MMS, 3G Data, VM Notifications, etc. Network operators/carriers select the correct version of the Radio firmware that is suitable for the phone, network and bandwidth.
There is also Modem and Baseband Radio Processor chipsets in Mobile phones. Usually, Google, Phone Manufacturers and carriers develop various types of modem firmware/software that controls the functions of these chipsets.
Firmware is the overall version of the Android system on your phone. Baseband version is the version of the radio embedded in the device. Since Android is based on the Linux operating system, they show you the current version of the Kernel used in the heart of the system. The Build number is just an indicator of which numerical version of the current overall system was built by developers for your device.
You cannot update any of these from the official web site. Updates to the Android system are pushed to the phone over-the-air by the manufacturer or the cell phone carrier. The only other way to update or change an Android phone it to install custom modified ROMs in place of the existing system firmware. That usually requires rooting the phone and a fairly considerable knowledge of how to hack hardware.
----------------------------------------------------------------------------
What's Dalvik?
http://www.techopedia.com/definition/4262/dalvik
http://butterflydroid.wordpress.com/2011/09/22/what-is-dalvik-vm-heapsize-benefits-and-downfalls/
Dalvik is named after a fishing village in Iceland where ancestors of Dan Bornstein, the person who wrote the VM’s original code, lived. Dalvik is designed for fast execution speeds and operatation in resource-constrained environments like those in mobile devices (with limited memory, CPU and battery power). A Dalvik VM is designed to run multiple instances of itself with each instance hosted on its own separate process and running one application each. When one instance crashes, other concurrently running applications don’t suffer.
Although Android apps are written in Java, they are first compiled into the Dalvik Executable (DEX) format to make them run on the Dalvik VM. DEX files are generally smaller than compressed .JAR (Java Archive) files, making them suitable for mobile devices.
The main difference between Dalvik and a typical Java VM is that the former is register-based while the latter is stack-based. Register-based VMs require fewer instructions than their stack-based counterparts. Although the register-based VMs also require more code, they are generally considered to exhibit faster startups and have better performance than stack-based VMs.
The Dalvik source code license is based on the Apache license. That means, it is free to modify and hence attractive to mobile phone carriers.
What's init.d?
init.d is a folder located at /system/etc
To keep it simple, it allows the user to run scripts at system startup/ boot.
You can adjust many different things/settings with scripts. You can tweak system settings, prolong battery life etc.
To enable init.d and to get some scripts, go here: http://forum.xda-developers.com/showthread.php?t=1881401
----------------------------------------------------------------------------
great job brother, do much to newcomers become familiar with android and they need to know :highfive:
woooow , thats nice and great thread ...... thx ..... but between that , can u continue explain many things like what each android device need to boot up and what the most commen partitions in android devics , and getting deeper in android world ad then give some tut about adb using
thx so much
Good stuff, thanks!
Great guide for android noobie who want to learn how to root
add CID and MID ... ?
Hey -- a really great resource. great work.
could be nice to include CID, MID, etc.
also, would like to understand why ROM has to be built for specific carrier variant of phone.
Example: HTC ONE M8 has multiple different ROM threads -- ATT, Tmobile, Verizon, etc. While I understand there are some small frequencies support differences between an M8_tmobile and M8_Verison, why doesn't a Rooted with S-off M8 care whether it's a ATT or Verizon model?
thx
Thanks iONEx, this post helped me some. I already have 20 years of experience with Linux on PCs and Macs, so I already understood concepts like Bootloader, Kernel, Rooting, Flashing, Firmware, and init.d. I've had to flash a new BIOS on several PC motherboards, so I understand the difference between nonvolatile storage in firmware mounted on an integrated circuit of the motherboard versus nonvolatile storage in a physical spinning magnetic hard drive connected to the motherboard via a SCSI or SATA bus and controller. I rooted my first Android (a Motorola Atrix) a year ago, so I also understand CWM, Custom ROMs, and ADB. But your explanation of Baseband and Dalvik was new and helpful to me.
Right now I'm running Paranoid Android on my Oneplus One and using the Settings app in it, I see that I have Android version 4.4.4, ParanoidAndroid version 4.6-BETA6, Baseband version MPSS.DI.2.0.1..., Kernel version 3.4.0-ParanoidAndroid (Mon Nov 3 21:55:14 UTC 2014), Build number pa_bacon-userdebug...).
I found your post while trying to understand more about my OPO that I rooted a few days ago. I installed TWRP, F-Droid, Busybox, MultiROM, and a few other major customizations on it, but I feel like there's still a whole lot that I don't understand at all. For example, in this thread [forums.oneplus.net/threads/unofficial-beanstalk-rom-for-bacon-lollipop-5-02-r1.247146/#post-9394373] I commented that I was unable to get Beanstalk 5.0.2 to function reliably on my OPO.
From chineel's reply "The Steps To Have Better Experience With OnePlus One With Lollipop ROMs" though, I realized that I must still be missing some important concepts, so I started searching for a comprehensive picture of my OPO and of Android phones in general, and although your post helped some, I'm still looking for a much more comprehensive understanding of this device.
I do understand that the nonvolatile storage in my phone must be partitioned into several mutually exclusive sections and that's how it's possible for me to wipe (using TWRP) all of the partitions (Dalvik Cache, System, Data, and Cache) except Internal Storage and flash a new ROM like Beanstalk and yet I still have the contents of /sdcard/ as they were before I wiped and flashed. Obviously, /sdcard/ as mounted in ParanoidAndroid and Beanstalk must be on the Internal Storage partition that did not get wiped.
But when chineel wrote that I should download latest “Cm Nightly” and “(CM Nightly Is for Modem and firmware Update only ) you can Just Flash Firm ware Update [s.basketbuild.com/filedl/devs?dev=chineel&dl=chineel/BeanStalk/bacon/Full-CM-12.01.18-modem-flashable.zip] Instead of...”, that's when I realized that when I flashed a new ROM, I was apparently still leaving something aside from the Internal Storage partition untouched: the modem/baseband/radio?
And so if I flash the latest CM nightly from [download.cyanogenmod.org/?device=bacon&type=] then I'll end up doing what I have not been doing before which is to also change the modem/baseband/radio. Is that right?
So then if I flash a new ROM (like Beanstalk) AFTER flashing the CM Nightly, then I'll be replacing the ROM (from the CM Nightly to Beanstalk), but I won't be changing again the modem/baseband/radio that was changed when I flashed the CM Nightly. Is that right?
If so, then where in this partition system is the modem/baseband/radio firmware (which is apparently separate from the whole ROM) stored in nonvolatile storage? Is it also on Internal Storage? Or is it stored on a separate integrated circuit (like the BIOS is on a PC) or on some other hidden partition?
And what about flashing the kernel? When I flashed my PA ROM, I got a new kernel with it, without explicitly installing from TWRP a new kernel. So sometimes flashing a ROM gives you a new kernel and sometimes flashing a ROM does not change the existing kernel? Is that right? And so is it also possible to flash a ROM and then subsequently flash a kernel and that second flash replaces the kernel that was part of the ROM of the first flash?
I just need to understand where all of this information is getting stored (in which partitions). I know I flash a ROM, then I flash GAPPS, then I flash a kernel, then I flash a modem/radio/baseband. But I can't tell; is all that software going to the System partition? If so, then why don't all the later flashes completely write over all the earlier flashes?
TL;DR
My real question here is what to read for a comprehensive explanation of all these pieces and how they fit together and why flashing sometimes replaces something that was there before, but it doesn't replace everything (like the modem/radio/baseband)? I think I need a book or something. Can you recommend one?
Thanks, and sorry for the long post.
iONEx said:
Android ABC​
I've gathered some info for newcomers to the Android world.
Copied over from my thread at androidforums...
I've tried to keep it relatively simple. So if you want more info, follow the links!
And please if you want anything added, do post!
I hope this helps someone....
Inventory:
Bootloader
Kernel
CWM
Firmware
Flashing
Rooting
Custom ROMs
ADB
Baseband
Dalvik
init.d​
What's A Bootloader?
Taken from: Android 101: What is a bootloader? | Android-Does.com
In literal terms, the bootloader is code that is executed before any Operating System starts to run. Bootloaders basically package the instructions to boot operating system kernel and most of them also have their own debugging or modification environment. Think of the bootloader as a security checkpoint for all those partitions. Because if you’re able to swap out what’s on those partitions, you’re able to break things if you don’t know what you’re doing.
As the bootloader kicks off before any piece of software on your device, it makes it extremely processor specific and every motherboard has it’s own bootloader. This is one reason that all Android phones have different custom ROMS developed due to high variance of processing hardware present on the device.
Android Bootloader
Every Android phone has a bootloader that instructs the operating system kernel to boot normally. But you need to understand one thing here that as Android OS is an open source OS and is available on a variety of different hardware, every manufacturer has their own version of bootloader specific for the hardware present in it’s environment. At its most basic level, your Android smartphone is like a hard drive, made of up several partitions. One of those partitions holds the Android system files, another holds all the app data you accumulate (which is how you’re usually able to update without losing all your stuff), and others to do more behind-the scenes stuff.
A lot has been said about bootloaders being “locked” and even the developer-friendly Nexus devices shipped with a locked bootloader (Nexus devices and a couple tablets are easily unlocked with a single command).In fact, a lot bootloaders are locked and encrypted, meaning simple commands like “fastboot oem unlock”, won’t do a thing.
Why are Bootloaders Locked?
A bootloader is usually locked on an Android device because although it’s an open source OS, still the manufacturers want you to stick to their Android OS version specifically designed for the device. In order to apply this concept, manufacturers lock the bootloader. With a locked bootloader on Android devices, it is virtually impossible to flash a Custom ROM and forced attempts void warranty as well as usually end up in bricks. Therefore, the first step is to always unlock the bootloader.
Why keep a bootloader out of reach? One of the biggest reasons is that the carriers and manufacturers don’t want to have to support hacked phones. The other is that a lot of time and money is spent developing these things. HTC Sense ain’t cheap. Neither is TouchWiz. But Samsung and HTC both have managed to find a middle ground with the modding community, and pressure is on other companies to do so as well.
Also a very good read about bootloaders: http://www.tested.com/news/feature/1879-know-your-android-bootloaderwhat-it-is-and-why-it-matters/
---------------------------------------------------------------------------
What's a kernel?
Taken from: Android A to Z: What is a kernel? | Android Central
A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
---------------------------------------------------------------------------
What's CWM?
Taken from: AddictiveTips » Blog ArchiveWhat Is ClockworkMod Recovery And How To Use It On Android [Complete Guide]
ClockworkMod, abbreviated as CWM, is a popular custom recovery for Android phones and tablets developed by Koushik Dutta (Koush), a well-known name in the Android dev community. ClockworkMod recovery allows you to perform several advanced recovery, restoration, installation and maintenance operations on your Android device that aren’t possible with the stock recovery, and is one of the most common ways used to gain root access, back up device data, install a custom ROMs, kernels, themes, mods and more. However, for anyone new to Android customization and hacking, some of its options might prove to be a tad confusing. In what follows, we will cover all that this recovery is capable of doing, and how to do it.
About Android Recovery
All Android devices ship with a recovery console that is basically a partition on the device’s internal memory and can be booted into. The stock recovery of almost all Android devices provides a few basic yet handy options that allow you to factory reset your device and also to recover its operating system using an official ROM in zip format, but that’s all you can do with it. That’s where a custom recovery comes handy.
A custom Android recovery basically replaces the stock recovery with one that lets you do all you can do with the stock recovery, plus a plethora of more options to give you a lot more control on your device. With a custom recovery, you can install official and unofficial ROMs as well as other updates including apps, themes, kernels etc. using zip files, wipe not just user data but pretty much every partition on your device, mount the storage card for USB mass storage access without leaving recovery, partition your SD card, wipe Dalvik cache and battery stats, fix permissions, perform, manage and restore backups and so on.
Introduction To ClockworkMod
ClockworkMod recovery is one of the most widely used custom Android recoveries that is available for most mainstream Android devices. It is our custom recovery of choice here at AddictiveTips and almost every custom ROM that we install on our devices is done using this recovery.
ClockworkMod recovery has been developed by Koushik Dutta (also known as Koush) – the same guy who brought us the Android ROM Manager. He can be found at his blog hacking away at Android devices and at Twitter.
CWM options explained:
[REF] CWM - Clockworkmode menu options & Partitions– GENERAL KNOWLEDGE - xda-developers
---------------------------------------------------------------------------
What's Firmware?
Taken from: What is Firmware, Rom and Firmware Flashing ? - I Teach Android
What the heck is this firmware? Definition of firmware is permanent software programmed into a read-only memory
In Simple words, you can understand it like windows for pc , in case of android we are going to do same thing – installing firmware (Froyo,Gingerbread, ICS, Jelly Bean etc.) on your phone. All phones have their different firmwares and installing tools regard less to the Andriod version (Froyo,Gingerbred). So never think that we can install any firmware on any android phone like we do in PCs.
Wiki link for even more info: Firmware - Wikipedia, the free encyclopedia
---------------------------------------------------------------------------
What's Flashing?
Flashing refers to the overwriting of existing data on ROM modules present in an electronic device with new data. This can be done to upgrade a device or to change the provider of a service associated with the function of the device, such as changing from one mobile phone service provider to another or installing a new operating system.
In simple words flashing is called installing firmware on your phone.
---------------------------------------------------------------------------
What's Rooting?
Taken from: Rooting for Android: What, why and how? | Ubergizmo
WiKi link: https://en.wikipedia.org/wiki/Rooting_(Android_OS)
When carriers and manufacturers sell you your device, it is almost certain that the device would come with certain software restrictions in place. There are a variety of different reasons why they might do that – some claim that this is done to protect the user, preserve the device’s warranty (this policy will vary from manufacturer to manufacturer), prevent users from getting rid of carrier bloatware apps or simply because the manufacturer would prefer if your device was distinguishable from the competition based purely on its user interface (i.e. Samsung’s TouchWiz, HTC Sense UI, etc).
Whatever their reasoning may be, chances are if you are looking to customize your device on a deeper level, you’d be out of luck and this is where rooting comes into play.
Rooting is essentially a process that allows users of smartphones, tablets or other devices running on Android to gain “superuser” access to the software. This will allow the user to perform administrative tasks such as writing to locations normally restricted by the system which in turn will allow for deeper customization. For iOS users, rooting on Android devices could be thought of as a close equivalent to jailbreaking your device.
---------------------------------------------------------------------------
What are custom ROMs?
Taken from: Custom ROMs For Android Explained - Here Is Why You Want Them
A stock ROM is the version of the phone's operating system that comes with your phone when you buy it.
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way.
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, strip them of garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow.
---------------------------------------------------------------------------
What is ADB?
Taken from: Android 201: What is adb? | Android Central
According to Google "Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device." That certainly sounds like Google, doesn't it? To put it simply, adb is two different applications -- one running on your computer (Windows, Linux or Mac) and one running on your phone. When your phone is connected, and USB debugging is enabled, you can issue commands and communicate with the phone using your computer screen and keyboard.
Your Android phone uses a modified Linux kernel and tools as a base. This means that quite a few Linux commands can be sent via the adb server (the one running on your computer) to the adb client (the one running on your phone) and they will be executed. In our example picture, I've sent the "top" command over the wire to my phone, and my phone sent me back the information and printed it to my terminal.
This can be awfully handy for debugging things that aren't going right, as well sending those weird commands you need when you're hacking away in the middle of the night. Chances are, if you aren't actively debugging something or trying to break hack at your phone, you won't have much use for adb. And that's OK -- there's more than one way to have fun with an Android device.
----------------------------------------------------------------------------
What's baseband?
Baseband is the Radio or Modem version depending upon the Phone Model, Carrier and Android Software Stack version. The Radio/Modem file is flashed via Recovery tool (other options are ADB/ODIN). The mismatched Radio/Modem and ROM will lead to things not working. You need to find the matching Radio/Modem for the particular ROM you are running.
The radio firmware controls basic low-level functions like network connectivity, Wi-Fi, and GPS. Upgrading Radio firmware will fix connectivity issues, increase range or performance, decrease battery usage, etc. Incorrec tRadio frimeware can disable some functions in your phone such as MMS, 3G Data, VM Notifications, etc. Network operators/carriers select the correct version of the Radio firmware that is suitable for the phone, network and bandwidth.
There is also Modem and Baseband Radio Processor chipsets in Mobile phones. Usually, Google, Phone Manufacturers and carriers develop various types of modem firmware/software that controls the functions of these chipsets.
Firmware is the overall version of the Android system on your phone. Baseband version is the version of the radio embedded in the device. Since Android is based on the Linux operating system, they show you the current version of the Kernel used in the heart of the system. The Build number is just an indicator of which numerical version of the current overall system was built by developers for your device.
You cannot update any of these from the official web site. Updates to the Android system are pushed to the phone over-the-air by the manufacturer or the cell phone carrier. The only other way to update or change an Android phone it to install custom modified ROMs in place of the existing system firmware. That usually requires rooting the phone and a fairly considerable knowledge of how to hack hardware.
----------------------------------------------------------------------------
What's Dalvik?
http://www.techopedia.com/definition/4262/dalvik
http://butterflydroid.wordpress.com/2011/09/22/what-is-dalvik-vm-heapsize-benefits-and-downfalls/
Dalvik is named after a fishing village in Iceland where ancestors of Dan Bornstein, the person who wrote the VM’s original code, lived. Dalvik is designed for fast execution speeds and operatation in resource-constrained environments like those in mobile devices (with limited memory, CPU and battery power). A Dalvik VM is designed to run multiple instances of itself with each instance hosted on its own separate process and running one application each. When one instance crashes, other concurrently running applications don’t suffer.
Although Android apps are written in Java, they are first compiled into the Dalvik Executable (DEX) format to make them run on the Dalvik VM. DEX files are generally smaller than compressed .JAR (Java Archive) files, making them suitable for mobile devices.
The main difference between Dalvik and a typical Java VM is that the former is register-based while the latter is stack-based. Register-based VMs require fewer instructions than their stack-based counterparts. Although the register-based VMs also require more code, they are generally considered to exhibit faster startups and have better performance than stack-based VMs.
The Dalvik source code license is based on the Apache license. That means, it is free to modify and hence attractive to mobile phone carriers.
What's init.d?
init.d is a folder located at /system/etc
To keep it simple, it allows the user to run scripts at system startup/ boot.
You can adjust many different things/settings with scripts. You can tweak system settings, prolong battery life etc.
To enable init.d and to get some scripts, go here: http://forum.xda-developers.com/showthread.php?t=1881401
----------------------------------------------------------------------------
Click to expand...
Click to collapse
Thanks, good info
teejbee said:
Thanks, good info
Click to expand...
Click to collapse
Strewth! Not only did you quote the ENTIRE OP post in order to reply with a 3 word thank you but 2 people actually thanked you for it. I might print that out and hang it on my wall. :laugh:
Hi, what does the "Allow bootloader unlock" (or similar) mean in advanced settings on s7 and some other devices? My phablet also has this option and I turned it on without any changes after typing oem unlock. With selfmade cwm I can root my phone, if its allowed to unlock or not.. is this setting only a placeholder or did someone get the real function? M a ybe this is important for nexus devices only, or not. I do not know.
Gesendet von meinem SM-G900F mit Tapatalk
Edit: sorry for asking in xperia forums.. used tapatalk and saw the title is matching my purposes.. did not see the xperia section, but my question you can answer, too. Sry
louiscar said:
Strewth! Not only did you quote the ENTIRE OP post in order to reply with a 3 word thank you but 2 people actually thanked you for it. I might print that out and hang it on my wall. :laugh:
Click to expand...
Click to collapse
hahahahahahaha :laugh:
Dear, Can I make a custom ROM for my Android TV that can use the TV remote and IR key?
I mean, after installing a custom ROM like Lineage OS, do the remote and inputs work properly?

[CLOSED][PARTITION][TREBLE] Project Treble for Samsung Galaxy S8 [dreamltexx][15.02.2019]

- T R E B L E Y -
Android Partition Treblerizer
A tool able to seamlessly create / remove the vendor partition from within TWRP​
INTRODUCTION
The creation of a tool able to create and remove the supplier partition from TWRP, so a computer was not required. So I created this flaming TWRP ZIP which can create and remove the vendor partition from the userdata system or partitions without a computer and without deleting the files in the mother partition in the recommended configuration.
Trebley, finally, also expands on our much loved Galaxy S8, bringing with it Project Treble on the much loved device.
The tool will try to resize the mother partition without deleting it, either during the creation and removal of the supplier partition. However, this can only be done when the mother partition is ext4, only when the supplier partition is at the end of the mother partition and when the mother partition is not encrypted. The recommended configuration is the one that is obtained by selecting the first option in each option: subdividing 512 MB from the end of the system partition. A reboot is required after applying the patch to the partition table because the kernel needs to reload it before doing anything else.
REQUIREMENTS
Due to the use of a key detection binary, it is compatible only with ARM and ARM64 devices running TWRP. So far I have tested it in the Samsung Galaxy S8 but It should work in any compatible device. I made it this way so other legacy devices could transition to Treble ROMs + GSI, and Android Pie. Please let me know about other devices using this tool!!!!!
INSTALLATION
WARNING, THIS SOFTWARE COULD WIPE ALL THE DATA IN YOUR DEVICE, INCLUDING THE INTERNAL STORAGE.
IT REQUIRES TWRP CUSTOM RECOVERY IN AN UNLOCKED DEVICE, OTHERWISE YOUR DEVICE COULD BE BRICKED AND IF YOU FOLLOW MY STEPS BELOW, YOU WILL LOSE YOUR WARRANTY, KNOX WILL DISPLAY 0x1! I'M NOT RESPONSIBLE FOR ANY DAMAGED DEVICE!.
!!! Whatever you do, it is at your own risk !!!
Either for creating or removing a vendor partition, follow these steps:
1. Download the TWRP ZIP tool to your External SD card.
2. Boot to TWRP recovery, under Install, flash the ZIP file as any other ROM or MOD file to execute the tool.
3. Reboot to recovery again to ensure the changes are applied properly.
4. In some cases you will need to format the mother partition after adding or removing the vendor partition next to it.
CREATE A VENDOR PARTITION:
So far these are the available options:
Mother partition selection: system / userdata
Split position: Splitting from the end / start of the mother partition.
Vendor partition size: 512 / 915 MB
REMOVE THE VENDOR PARTITION:
Should a Vendor module already exists, Trebley offers to remove it, returning to a Non-Treble partition table. It will return the space to the mother partition, system or userdata. So, older non Treble ROMs could be flashed after the mandatory reboot.
DOWNLOAD
Trebley_APT_v1.0_ARM_20190215-signed.zip
SOURCES
All rights reserved to the project: Party and its creator(@Oki).
CAUTION
Currently, we recommend the use of Trebley, exclusively to developers, as until now there has been no development of material related to the project treble, this project lays the foundations creating the partition vendor, for the support treble.
CREDITS
@someone755 for the keycheck binary
@Zackptg5 for the V4A install script that inspired my version.
@Oki for the base script.
XDA:DevDB Information
[PARTITION][TREBLE] Project Treble for Samsung Galaxy S8 [dreamltexx][15.02.2019], Tool/Utility for the Samsung Galaxy S8
Contributors
DarioRetr
Source Code: https://forum.xda-developers.com/axon-7/development/tool-party-v0-1-vendor-partition-t3831517
Version Information
Status: Alpha
Current Stable Version: V1.0
Stable Release Date: 2019-02-26
Current Beta Version: V0.5
Beta Release Date: 2019-02-15
Created 2019-02-17
Last Updated 2019-02-17
thx the tools makes me now easyer to create and remove my treble partition since i used for the moment all time parted with console on pc. for the one that thinks that is treble. without right vendor partition is useless. i have a partition that boots gsi but with a nice glitched display
geiti94 said:
thx the tools makes me now easyer to create and remove my treble partition since i used for the moment all time parted with console on pc. for the one that thinks that is treble. without right vendor partition is useless. i have a partition that boots gsi but with a nice glitched display
Click to expand...
Click to collapse
It is certainly not Trebley's fault, as it was specified in red, that Trebley is currently recommended for use only to developers, as Trebley, lays the foundations for Project Treble by creating the Vendor partition, after which it will be up to the developers Compile from source the vendor. IMG, the TWRP custom, and the kernel, to allow the startup of Project Treble.
In addition, in layman's terms, Trebley currently creates the vendor partition, after which it will be you dev compile the sources by adjusting them to the treble standards, to allow you to use project treble on the Samsung S8.
Members are reminded that making changes to device partitions is inherently dangerous. With that in mind, exercise caution and if in doubt, DON'T.
LenAsh said:
Members are reminded that making changes to device partitions is inherently dangerous. With that in mind, exercise caution and if in doubt, DON'T.
Click to expand...
Click to collapse
Dear @LenAsh, Trebley, precisely ensures through the scripts, a greater security, as it is all automated and calculated to the milimeter, and above all reduces the risk. Clearly, currently Trebley for S8, it is in its initial state, where it introduces the vendor partition, now it's up to you have developer, compile and propagate the material needed to start project treble in our Samsung S8 device
Any hope on this zip working on s8 phones? Or porting for others?
Rehvix said:
Any hope on this zip working on s8 phones? Or porting for others?
Click to expand...
Click to collapse
This zip is made for the Samsung Galaxy S8, but also works on other devices, because the script is multi platform and arm, currently, but we recommend the use of the zip file to developers, because currently Trebley creates only the vendor partition, but Without the vendor file, and a modified TWRP for treble support, you still can't use the project treble. We need to wait for some dev, compile from source, the appropriate kernel for project treble, and a vendor appropriate to the project treble along with a custom TWRP, allowing the Samsung S8 to use the vendor partition created by Trebley, and finally use Project Treble.
so can we get aosp room sir..??
onMyConquest said:
so can we get aosp room sir..??
Click to expand...
Click to collapse
In order to run a GSI, you have to wait for the scene, wait for some Dev, compile the kernel and the vendor, and place a custom twrp, to allow the project treble to go. In practice Trebley, prepares the partition making it compatible with Project Treble. Now you have to have developer share software, clearly depends on scene to scene, to give you an example on the Samsung Galaxy S6 Edge, with the same method, now they can use the GSI, with project treble.
Plz someon try this. Im afraid to brick
https://www.xda-developers.com/flash-generic-system-image-project-treble-device/
Can somebody take this down or at least force the guy to rename it ? this is clearly a script that'll only make an empty partition, this is NOT treble as stated in the thread also by reading the messages it's clear the OP doesn't know what he's talking about
If I understand, in the case of Galaxy S8, it splits the /system partition to create a /vendor partition and copy the contents from /system/vendor to the new /vendor partition, right?
However, dont the binaries and/or drivers need to be adapted for project Treble? I mean how does the (lets say) new aosp rom know what drivers use for each feature?
Josevega said:
Can somebody take this down or at least force the guy to rename it ? this is clearly a script that'll only make an empty partition, this is NOT treble as stated in the thread also by reading the messages it's clear the OP doesn't know what he's talking about
Click to expand...
Click to collapse
My dear, create the partition to make it compatible with the Project Treble, now instead of talking about things, why do not you go to work, adapting the kernel and the vendor, and send the vendor.img, and the boot.img and twrp .img, to be able to use project treble?
Also before saying, that Trebley, does not know what he is talking about, he learns to read English, why it is written clearly is round, that this script is recommended to use you have developer to ensure project treble also on S8.
If then you want to talk bad, because evidently put project treble on S8, it requires too much work as you have to move the device tree blob and so on, and for question of laziness you want to deny the possibility of having treble to users.
So we know that the developers of the scene samsung S8, does not paste them to adapt the kernel to project treble.
bamsbamx said:
If I understand, in the case of Galaxy S8, it splits the /system partition to create a /vendor partition and copy the contents from /system/vendor to the new /vendor partition, right?
However, dont the binaries and/or drivers need to be adapted for project Treble? I mean how does the (lets say) new aosp rom know what drivers use for each feature?
Click to expand...
Click to collapse
Then, Trebley, takes part of partition either from system or userdata, and then creates a new partition named vendor, and makes the device compatible with project treble, then it needs a developer, move device tree blobs, and systems the configuration , because it is not enough to move the vendor into vendor, you have to compile the kernel so that you take the drivers from the vendor, you have to do some work first at the software level.
You need someone who has Ubuntu, take the device sources from GitHub, and run the device tree, and compile the vendor.img and boot.img which includes the kernel, and then edit the twrp to make it compatible with Treble, after that you can use treble on the device.
Trebley, did not want to compile the vendor for the Samsung S8 users, for one reason, because Trebley's developers are external to the Samsung S8 scene, and compile a kernel or vendor for an S8, as you might compile for an S7 Edge or an S6, it could cause users of the S8, slowdowns, battery that you download easily, GSI where the camera does not work.
So we prefer to be your developer of the scene, to compile the vendor and boot, to ensure reliability even with the project treble. Because we do not want s8 users to consider project treble as an unstable project.
In addition, this project has also expanded on Note 8, we will see who will be faster to adapt kernels and vendors.
Update 18/02/2019
A developer of the S7 Edge scene, he decided to contribute to the project, starting to work on the sources of the device.
https://github.com/KiubeDev
Hello ,Can you make this for s7 edge?
DarioRetr said:
In addition, this project has also expanded on Note 8, we will see who will be faster to adapt kernels and vendors.
Update 18/02/2019
A developer of the S7 Edge scene, he decided to contribute to the project, starting to work on the sources of the device.
https://github.com/KiubeDev
Click to expand...
Click to collapse
In this github account all the repositories are forked from ivan meler, he is galaxy s7/edge developer i can see a universal exynos 8895 repo but there is no device specific code for dream2ltexx and only a highly experienced developer can make this then there will be no need for treble support.
Why are u not using the preload partition???? Would be much easier as its only used for apps to be installed in stock Rom for a carrier or Region...
Can I install this, and then https://forum.xda-developers.com/pr...vice-development/lineage-phh-treble-t3767690?
Will that brick?
qasim799 said:
In this github account all the repositories are forked from ivan meler, he is galaxy s7/edge developer i can see a universal exynos 8895 repo but there is no device specific code for dream2ltexx and only a highly experienced developer can make this then there will be no need for treble support.
Click to expand...
Click to collapse
Dear, that repository is another, he is just a dev, the repository where they are working and gitlab, and is only accessible to developers.

Approaches and prerequisites of a cutom factory image

I'm from a startup, that is working on a Smartphone with a preinstalled Android without Google Apps and Services to protect the user's privacy by default. The focus of our development is an improved system user experience with a technology background in NLP, ML and AI. Android offers a straight forward approach with a custom launcher.
The potential ODMs for our device offer a Stock Android Pie with all Google Apps and Services. So we a re looking for the most cost efficient approach of customizing the factory image. In principle, I see two possibilities:
1. Modifying the factory image of the ODM
Maybe the most efficient way would be to remove Google Apps and Serivces and install a custom launcher and some replacement apps with a script. I'm not sure if this doesn't lead to errors or if this possibility also exists for a recovery image.
2. Providing a custom factory image
I found some tutorials, one at XDA developers and another at Android Authority. Finally there is guide of the AOSP.
One challenge are the technical requirements, as far as I have understood, the device drivers. The AOSP documentation says:
Download previews, factory images, drivers, over-the-air (OTA) updates, and other blobs below. For details, see Obtaining proprietary binaries.
Preview binaries (blobs) for AOSP master branch development
Factory images for supported devices running tagged AOSP release branches
Binary hardware support files for devices running tagged AOSP release branches
Click to expand...
Click to collapse
The Android Authority article says something similar:
Obtain proprietary binaries – The binary drivers should be unpacked in your working directory.
Click to expand...
Click to collapse
What do we exactly need from the ODM respectively PCBA board designer beyond the factory image? The hardware support files as proprietary binaries? It's unlikely, that we get the source code for the drivers. Can we take the drivers from the factory image? How can we identify them?
We think to take LineageOS, but we learned from the related Reddit forum, that a port of LineageOS for a new device would take some man years. Would you suggest to use the AOSP? How many man month should we calculate for a custom build?
Further more we need to think about how to provide OTA updates. Unfortunately, I don't know what is necessary to set up an OTA Update Service and prepare a Custom ROM for it. Is it essentially a fileserver with an encrypted connection and signed files?
Which approach would you suggest? Thanks for each suggestion and links for further information.

Porting AOSP to custom-built device

Hi everyone,
as title suggests, I'd like to "port" clean AOSP to be able to install and run it on the custom device.
Basically, the situation is following: I got a custom device, based on rockchip rk3288 SoC. The device currently runs Android 5.1 successfully. I'd like to update Android to version 6 (got AOSP sources and AWS builder image up and running), but the company that created Android v5 for us no longer exists.
Thus I am here to ask for advice(s) on how to proceed (or whether it even is a good idea to do that myself, given the fact that I have zero experience with Android ROMs development), possibly a step-by-step guide on what to do.
The question is, do I just find drivers for hardware components present in the device (usb hub, ethernet, etc.) and just somehow "link" those to existing sources (of AOSP) and just run the build with different parameters? Or do I need to build a whole new kernel for the given device-OS combination?
Thank you for any advice or opinion!
Well this is an interesting one. There are several routes you can take here.
If you have the kernel source code, and the source code for the drivers, you could probably build the kernel from source and use it to boot Android, however, as that's unlikely, you're looking at a more regular porting process, which usually consists of pulling the vendor blobs from the existing Android system, building AOSP/Lineage with those blobs involved, and hacking together a new ramdisk that HOPEFULLY will be compatible. It's a very long and very tedious process, but it's certainly possible.
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
abtekk said:
Well this is an interesting one. There are several routes you can take here.
If you have the kernel source code, and the source code for the drivers, you could probably build the kernel from source and use it to boot Android, however, as that's unlikely, you're looking at a more regular porting process, which usually consists of pulling the vendor blobs from the existing Android system, building AOSP/Lineage with those blobs involved, and hacking together a new ramdisk that HOPEFULLY will be compatible. It's a very long and very tedious process, but it's certainly possible.
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
Click to expand...
Click to collapse
Thanks for pointing in the right (or at least some) direction! I found some guide on porting ROMs which I followed, basically like you said. So I just replaced some files in System image. Will flash later today, so maybe I will get some results!
abtekk said:
From that you'll then get in to the debugging stage of finding out what works out of the box, you'll very well need to make changes to AOSP for it to work on that SoC.
Click to expand...
Click to collapse
So I was following this tutorial, although found some irregularities, let's say: For example, none of those 2 folders contained init.d/ directory, thus I didn't update it. Also, I haven't found META-INF folder therefore haven't updated updater-script.
Basically, when I did (or at least what I think I was doing was that I took /system partition from our current ROM, that is working on that custom device and replaced stuff in there by stuff from the new system I wanted to port. My idea from what I've read was that i took kernel (and boot/recovery) from the original, working ROM and "injected" the new system onto it. Is that correct? Is that what I needed to do? Because the problem is, I cannot boot into the system (might as well be because of Kernel version, because I am trying to port Android 6 on Kernel 3.10. which was used in the current ROM running Android 5). It looks like the device is stuck in bootloader, or "somehow doesn't know what to start" (sorry, I can't put it better), displaying only my device's logo.
When I connect it to the computer via USB cable, running adb devices shows me that device, but when I try to access shell using adb shell I got error saying that /system/bin/sh wasn't found, which made me thinking that somehow the /system partition isn't "linked" properly, like I stated in the beginning.
Was I doing everything correctly? Do I need to do something above that? (maybe do you know about some tutorial). I am trying to port AOSP 6 Android.
Thank you!

Categories

Resources