Development and porting of GSI firmware
Architecture What do you use?
Architecture.
arm64-ab [ 692 ] ** [45,5%]
arm64-a [ 561 ] ** [36,88%]
a64-ab [ 97 ] ** [6,38%]
a64-a [ 39 ] ** [2,56%]
arm-ab [ 11 ] ** [0,72%]
arm-a [ 121 ] ** [7,96%]
Total votes: 1521
 



Rep: (2477)
Development and porting of GSI firmware


Supported Devices


Determination of partition structure

Patch Remover Logov In adb / usb

Manual removal of logs


For those who have not started the firmware without any additional manipulation.


Be sure to read!
Dear users!
I remind you that our section is calledВ«Android - Development and ProgrammingВ» , Which means that the topic is primarily intended for developers.

thereforetoday the topic is prohibited to discuss the nuances of the GSI-specific firmware on devices. All of these issues are discussed in the topics rom your devices in the section В«Android - Firmware."
This is an official warning.For ignoring this warning particularly stubborn will receive read-only mode ( "read only")
.

Thank you for understanding! Have a nice chat.


Read a must.
For the report / review, the problem report.
Development and porting of GSI-firmware (Post derak1129 # 95942923)


Description
What is Project Treble?

Project Treble shares low-level drivers and the rest of the operating system so that manufacturers and third-party developers can release updates faster and easier. For devices with Android 8.x Oreo "out of the box" support for Treble is a must, and for older smartphones and tablets the option is available.

Instructions
Firmware
Template for the design of the post with the firmware

Lite GSI Images- Trimmed Images From firmware zerovoid
Patches for starting firmware gsi.
Android All GSIs

Android 10.x.x
Firmware from Igor ~ s
Collection of firmwareby Igor ~ s


Android 10 release



Android 9.x.x


Android 8.x.x


Problem solving
Useful


Topics Curator rozetkin , for updating and renovation caps apply to the QMS


Post has been editedderak1129 - Yesterday, 06:34
Reason for editing: EvolutionX-4.4



Rep: (6343)
About "A / B" partition structure and "seamless" updates
Or the answer to the question: "What is wrong with my device? Why is it not like everyone else?"


Let's start. You've probably heard that some devices use some kind of outlandish A / B partition structure. It differs from the structure in most Android devices.
It is somehow strange and unusual set updates, chat with the system running (O_o). Inside OTA image of another, unreadable structure. Install TWRP is accompanied by some, earlier met, challenges, additional manipulation and significantly different from all that "I" had seen. Everyone is talking about some of the letter "A", "B", slots, and the two systems, and other, incomprehensible "me" things.Well, let's try to figure it all out.


Let's start with general questions:
Q: Well, who invented all this? Damned manufacturers simple geeks complicate life?
A: New structure " A / B sections "Designed just Google-th as part of the global changes in the Android architecture. It has been successfully used in Google Pixel smartphones, Essential Phone and a variety of other devices. In the future, more and more devices from third-party manufacturers will use it. There is nothing bad and wrong with that, on the contrary It opens many new possibilities.

Q: So what is the A / B partition structure?
A: Speaking quite simply - inside your device there are two at once (and depending on the implementation and more), independent among themselves, systems. Something like MultiROM (if you heard about this), only with a much more thoughtful implementation at a lower level. If you are interested in specific information explaining all aspects, please continue reading.


Section table on the example of Google Pixel:
In order to visually display the theory outlined above, and see the differences compared to other devices, let’s look at the Google Pixel table of sections.
If you are not familiar with the structure of partitions in Linux-like systems, and Android in particular, I advise you to search for information about this in Google, since it is complete.

We are interested in specific sections that exist in two copies for clarity and demonstration.
So (we open the code completely):
/ dev / block / bootdevice / by-name / aboot_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / apdp_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / bootlocker_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / cmnlib32_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / cmnlib64_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / devcfg_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / hosd_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / hyp_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / keymaster_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / msadp_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / pmic_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / rpm_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / tz_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / xbl_a # Partitions of the first bootloader (Slot "a")

/ dev / block / bootdevice / by-name / aboot_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / apdp_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / bootlocker_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / cmnlib32_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / cmnlib64_b # Sections of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / devcfg_b # Sections of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / hosd_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / hyp_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / keymaster_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / msadp_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / pmic_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / rpm_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / tz_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / xbl_b # Second bootloader partitions (Slot "b")

/ dev / block / bootdevice / by-name / modem_a # Section of the first modem / radio module (Slot "a")
/ dev / block / bootdevice / by-name / modem_b # Second modem / radio section (slot "b")

/ dev / block / bootdevice / by-name / boot_a # The first kernel partition (Slot "a")
/ dev / block / bootdevice / by-name / boot_b # Section of the second kernel (Slot "b")

/ dev / block / bootdevice / by-name / vendor_a # First proprietary partition (Slot "a")
/ dev / block / bootdevice / by-name / vendor_b # Second proprietary partition (Slot b)

/ dev / block / bootdevice / by-name / system_a # First system partition (Slot "a")
/ dev / block / bootdevice / by-name / system_b # Second system partition (Slot "b")
As can be seen from the excerpt above, there are two, independent among themselves, slots, namely “partition groups”, which contain the main,upgradeable components firmware.

The two slots presented consist of:
Bootloader (loader) - 28 partitions (14 for each slot).
Radio / Modem (radio module) - 2 sections (one per slot).
Boot (core) - 2 sections (one per slot).
Vendor (drivers) - 2 sections (one per slot).
System (system) - 2 sections (one per slot).

The remaining sections, not listed in the table, are presented in one copy as superfluous as they are divided.
note user storage section (userdata) always alone ! That is why You can not (Without cleaning storage) simultaneously use two completely different firmware, there is a conflict. The simultaneous use of the same type of firmware (and in some cases this is not possible without a reset).


The principal differences compared with other devices:
With overlapping sections, and the structure in general, understood. However, you may have noticed (if viewed full partition table) absence, the usual in any device partition "/ recovery" and "/ cache". Yes, they really do not. But they can also occur in deviations from the norm.

Q: Stop. But if there is no partition for Recovery, and Recovery itself is (He is, right?), Where is he located?
A: The recovery system (Recovery) is included in the kernel image (boot). Therefore, the presence, absence and type of installed recovery directly depend on the system kernel. Switching to it (Recovery), as before, is performed by a special flag in the "/ misc" section.
That this is a hitch install TWRP - it somehow need to "stick" to the kernel. Because TWRP first temporarily loaded (installed its nowhere), and then from the TWRP, a special script on the fly unpacks the kernel and sewn into it TWRP. The same scheme "repacking kernel on the fly" is used in the preparation of "systemless" Ruth rights through SuperSU and Magisk.

Q: Well, what happened to the "/ cache" partition?
A: In familiar devices, it is necessary only for storing OTA updates and system logs of Recovery, in this case, due to the use of the new scheme of these updates (see below), the section simply became “not needed”. That's from him and got rid of.


Manual slot switching:
Naturally, besides the slots themselves, there must be a way to manually interact with them. And he is. To manually switch the current active slot, you need to use the fastboot utility. Commands:
fastboot set_active a # slot activation of "a"
fastboot set_active b # Activation "b" slots
fastboot set_active other # activation slot opposite to the current
You can also switch to another slot in the corresponding TWRP item (Reboot ->Slot A / Slot B).


Results and regulations:
1. Between the slots, both the system and the user can switch.
2. Initially (from the factory) the slots are completely identical with each other. Differences appear after applying any OTA system updates.
3. Slots are isolated between themselves. The state and integrity of one slot does not affect the other. Except for the use of OTA updates. (see below).


"Seamless" update system:
So, the sections and slots are sorted out. But what about the updates, surely they were also affected by the change, in view of the above?
Yes, OTA updates on devices with an A / B structure are completely different from what we can see on other devices.

Results and regulations:
1. All OTA updates are installed in an inactive, opposite slot. I mean - only one slot is updated.
2. All OTA updates are installed in the background with a working system, without rebooting the device.
3. All OTA updates are installed in two steps: "Step 1" - Download the update. "Step 2" - Background application of the update in an inactive, opposite slot.
4. After installing the OTA update, when the device is rebooted, it will automatically be loaded into the updated slot (previously inactive).

Android 8.0+ - broadcast updates:
Starting with the version of Android 8.0, it is possible (but not necessary) to partially implement the broadcast of updates with their simultaneous use (direct recording).
This means that updates do not need to be preloaded, but are applied on the fly.

Post has been editedDisplax - 08.06.20, 01:27



Rep: (1139)
About Treble. The bottom line is that the vendor section, which is usually found under system, shall be made separately from the system and we have a 2 section, system and vendor. What it gives us? It reduces the size of firmware in about 2 times, because in the vendor are almost all libraries, and they (usually) do not change, but everything else in the system are in the new update (file that you download). That's it, that gives Treble. Besides OREO, can work without Treble, in this case the vendor stored in the system: rolleyes:



Rep: (2477)
* powar19, Well, and it will be even easier to switch between the firmware and the so-called will appear. "Universal firmware" with the assembly and porting which will not need to bother ...
* DenZsavagemessiahzine.com, 1+ users have already created a petition asking them to introduce RT support for them. (Infa with xda)



Rep: (1139)
* bullik01 Yes, due to the fact that all your drivers for your device are separate, this gives the versatility of the firmware and a huge number of people can cut them, which will give a huge tree of firmware)



Rep: (1139)
* sazan123 The bottom line is that you initially sew a new recovery that mounts the system and vendor partition, then sew a full firmware that fills in the boot, vendor and system sections, and then sew any other firmware that will change only the system, and boot and vendor remain from your device)



Rep: (299)
sazan123 @ 03.11.18, 20:39*
What kind of versatility are we talking about?
The vendor is in a separate section. Therefore, it does not affect it during flashing. But you need a new twrp with the support of this section.



Rep: (232)
* powar19 , * DenZsavagemessiahzine.com ,
I get it ....
But again, from the version on the version of the android in this case, do not jump?



Rep: (299)
sazan123 @ 03/11/18, 20:46*
But again, from the version on the version of the android in this case, do not jump?
Since there will be no binding to the hardware drivers for new firmware, then it will be easier to switch to a new android.
This is the essence of this mechanism. But you will need for a simple transition at least the initial firmware with PT support on
device to have.

Post has been editedDenZsavagemessiahzine.com - 11.03.18, 20:50



Rep: (2477)
* sazan123, why? Jump in theory can be ..



Rep: (1139)
* sazan123 , well, it seems to jump, but if it is the manufacturer that will officially make the treble, so that the drivers are universal. In our case, when treble is made by enthusiasts, we will have to refine the driver so that everything works on the new version (in our case it is android p), but it seems to me that Google is not stupid and the new android will work on the old proprietary

Post has been editedpowar19 - 11.03.18, 20:50



Rep: (232)
* bullik01 ,
I don't know. Interested in: D
* powar19 ,
The driver is fine. And the core?



Rep: (1139)
* sazan123 and what's wrong with him? Update it once when upgrading to a new version and that's it)



Rep: (232)
* powar19 ,
I ask about this. That is, when switching from O to P, you will need to rebuild the kernel. Unless of course the manufacturer does not "roll out"!



Rep: (1139)
* sazan123 may not be necessary



Rep: (232)
* powar19 ,
Clear. We will follow

Regarding TWRP. Is it the same and the other markup should be?

Post has been editedsazan123 - 11.03.18, 20:56



Rep: (299)
sazan123 @ 03.11.18, 20:54*
That is, when switching from O to P, you will need to rebuild the kernel.
You may have to apply several commits for compatibility with the new android.
(as it was recently: to raise the version of selinux and binder to patch for example or in the ramdisk something to add).
sazan123 @ 03.11.18, 20:55*
Regarding TWRP. Is it the same and the other markup should be?
Yes

Post has been editedDenZsavagemessiahzine.com - 11.03.18, 20:59



Rep: (2283)
sazan123 @ 03.11.18, 20:55*
Is the same markup should be different?

And the magisk will also have to be remade for yourself, if it is not supported yet for your device.
And with twrp there will be some minor difficulties when returning to 7 or lower, you will have to install the old version and re-do the partition for the vendor (for example, cust selected for it at mido).

Post has been editedRazziell - 11.03.18, 21:01



Rep: (232)
If the manufacturer supports it, well, if not, it still works like this: rolleyes:

Posted 11/03/2018 21:03:

Razziell @ 03/11/18, 19:59*
under it cust allocated

In this case, after all, it is not necessary to redevelop it. Just mount bush as vendor



Rep: (2477)
* Razziell magisk is almost universal;)



Rep: (2283)
bullik01 @ 03/11/18, 21:03*
magisk is almost universal

Then they would not do sohttps://github.com/The…ddc91555938d4f6a191e67 ))
sazan123 @ 03.11.18, 21:01*
Just mount bush as vendor

Yes, just a tambourine when you return will have to knock a little to the average user.
And the main thing is that in the future Google will not abandon the demand or radically reconsider the ideology, otherwise there will be no sense.

Post has been editedRazziell - 11.03.18, 21:09


Full version    

Help     rules

Time is now: 03/07/20, 00:37