There is no detailed instruction and it is unlikely to be. Only a rough overall plan:
1. Work, for example, with LinuxDeploy. This is a program for installing distributions into a folder or into an image and running programs in chroot. Be sure to work through the framebuffer. For problems, you can ask in the LD topic.
2. Learn to use adb. Learn how to mount an LD image and run xorg without the help of LD, via adb shell. It is not difficult. There are 5-6 commands that can be easily combined into a script. If you fail, ask here.
mount example 3. Learn to extract, edit and download ramdisk back. On those devices that I saw, the ramdisk with the kernel is usually stitched into one file and stitched together into the device. Most often, this is boot.img or recovery.img, but there are other options. Removing them from the mobile is not necessary - you can simply take the one that you were stitching. On XDA-Developers, there are all sorts of programs for separating such files and unpacking / packing the ramdisk. Right here
utilities , which I used, and a brief instruction. Most likely, they do not suit everyone.
4. When the ramdisk is unpacked into a folder, it should contain at least the init and init.rc. files. When the kernel boots, it also unpacks the ramdisk in / and / init becomes the first user-space program to be executed.
Most often / init is an Androids binary. It reads and executes /init.rc. In init.rc it is indicated which commands to execute at the early stages of loading, which commands to execute at the later stages, which services to start and so on. Also / init can also be a sh script, which is quite useful.
In desktop distributions, another initialization system is usually used: systemd, for example. But for newbies, I still suggest staying at android init. It is also easier for resources, and you don’t have to port every line of long init.rc scripts to systemd. Well, only every 10th line is really needed there, of course, but all the same, for a start, it is better to leave android init.
5. Now you can edit init.rc and upload it back to the device? Good...
The most interesting thing about init.rc is the service type blocks:
service bootanim / system / bin / bootanimation
class main
disabled
oneshot
These blocks describe the programs that init launches under certain conditions. A class is something like a group. All services of one group can then be started with a single command of the class_start main type.
disabled — means that this particular service will not start when class_start is called for its group. But it can still be started at any moment of initialization, such as start bootanim.
oneshot means that the program is executed once and will not restart if it terminates or dies. If there are no oneshot, then yes, it will be restarted.
More info on init.rc here:
https: //android.google...master/init/readme.txtMost likely, you in init.rc have blocks like "on early-init", "on init", "on fs". This is something like an event. When an event occurs, the commands from the block are executed. In my "on init" after a heap of commands of dubious utility, there was a command class_start main. It is necessary to understand this somehow: when init comes (it comes very early in the initialization process, but I don’t know the exact order), all those commands are executed and services of the main class are started.
There are events like "on property: ro.debuggable = 1". They are called when some kind of property changes. They can be changed by the android and the user by the android setprop program. It is convenient if you need to start / stop / restart services without editing the ramdisk and without restarting the device.
6. The first thing that I personally did was so that adb was launched right away and with root-rights. By default, it may well not run from the root. And then the android switches adb modes using property. I deleted all this and left on adb only what was in the init.rc recovery. By the way, yes, in the recovery of its completely different and shorter init.rc - be sure to look. You can even start with it - you need to understand much less there.
7. If adb works immediately and with root rights, you can now disable the most hated parts of the android. Disabling the service is easy - you can just comment it out in init.rc by adding the # character at the beginning of each line. Disable surfaceflinger, zygote, bootanim, etc. etc. I can’t give an exact list of necessary and unnecessary services with all the desire - it depends on the device. But the zygote and surfaceflinger just need to be turned off.
After successfully completing this item, the android should no longer load, but the adb shell should work. Well, everything else should work (wi-fak, sound, etc.), if nothing extra is turned off.
8. Well, now you can try to mount an LD * image via adb shell and launch xorg. You did not miss point 2? :)
If it works, you can create a script and add it to init.rc.
Yes, well, you need to start with something of this type. It is not very convenient to re-sew boot.img and flash it into the phone after each change of the ramdisk, right? But here we recall that / init does not have to be immediately that Androids init. And here your imagination is not limited. You can insert a script that will mount the memory card and update init.rc. from it.
And you can get rid of all the problems at once and at the same time from the chroot, but this is not very simple:
1. Unpack the ramdisk and copy it to the root of the LD image.
2. You can immediately copy there androids / system, / data. You can temporarily rename the folders of a normal distribution, so that there are no folder and file name conflicts.
3. In init.rc, which is already in the image, you need to comment out the lines mounting / system, / data, / cache. There is no need to mount them already.
4. And then in ramdisk (the one in boot.img) we write our own / init script and add static busybox. This script should create nodes of the devices it needs. Mount image LD, wherever he lay. And then "transfer control to it" (busybox switch_root). After this command, the image is permanently mounted in /, and the ramdisk is dismantled. And already executed / init and init.rc, crap in the image.
The point of all this is that after that you will no longer need to reflash boot.img. If you need to edit init.rc, then this can easily be done via adb shell or from an already running distribution (sudo nano /init.rc). Well, at the same time, you can, for example, make a beautiful dual block.
I will not write further until ... But if suddenly at least one person comes to launch xorg from init.rc, then the discussion will continue. Working xorg is awesome. And even most devices will work. But you need to do so that the device was really used, and not just to boast to friends. You need power management, dialer, internet connection, etc.
I guarantee that none of the items will be without additional problems not described here. If you do not have free MONTHS, drive in. * By "image LD" was meant the image or folder with the file system of the desktop distribution. Of course, it is not necessary to create it in LinuxDeploy.Post has been editedPigg - 07.12.16, 18:31