[X]Assistant

[Twaikyont]

пїЅпїЅпїЅпїЅпїЅпїЅ Android пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ download

... He just had his own ideas about how the world should look, and he was powerful enough to try to implement them.

V. Archer

I wonder if anyone, except me, tried to completely get rid of the android on his device and deploy a normal distribution.
If such people exist, then they may want to discuss the results, share their experiences, or boast achievements.

Surely, someone will ask, "What for? Yes, almost any desktop Linux program already has counterparts for android. But maybe someone just does not like the android. Or maybe someone wants to write highly specialized programs for their device and write them not in Java.

Here you can ask questions (or leave instructions) on the following topics:
- Rebuilding the kernel with the new config or drivers;
- Work with ramdisk;
- HAL libraries and libhybris;
- Set up Wi-Fi, 3g;
- Setup and launch of the X server;
- Choice of window manager, environment, virtual keyboard;
- Sound output;
- Development of programs that replace the functionality of the android: control backlight, processor frequency, volume, lights, calls, messages, hibernation;
- Using cameras, sensors.

Init FAQ.
Easy reading for leisure.

If someone is interested, but do not know where to start, you can look here:
Replacing Android on the desktop distribution (Post Pigg # 48927960)

Post has been editedottiwell - 15.06.18, 23:22

[Twaikyont]

Pigg,
I think it is worth a little to open the topic. Some features of the phone can be used without any software.

# Activate vibration for N milliseconds
echo N>/ sys / devices / virtual / timed_output / vibrator / enable

# Turn on the flashlight
echo 1>/ sys / devices / platform / flashlight / leds / flashlight / brightness

# Change brightness. The paths in different firmware are different.
echo 50>/ sys / class / backlight / pwm-backlight / brightness

Post has been editedottiwell - 30.07.16, 20:13

[Azathtot]

Ottiwell @ 01/08/2016, 11:07

1. Rebuilding the kernel

What for?

Pigg @ 01/08/2016, 04:48

2. Work with ramdisk

Yeah, replace init from android to normal, attach chroot. All this has long been implemented in live distributions, take it and copy it.

Pigg @ 01/08/2016, 04:48

3. Launch and Setup Xorg

For starters, get all the documentation from video chip manufacturers. I'll see how you will write the xf86 driver for some PowerVR
And without acceleration - garbage question, xf86-video-fbdev at your complete disposal.

Pigg @ 01/08/2016, 04:48

Writing programs that replace the functionality of Android

Do not think about it ... but you need to think about the development of hardware acceleration, and correspondence software (such as libjpeg, ffmpeg, vlc and other herds) on them.
Total. During the time you complete the last two points, the SoC you selected will take its place in the history dump.

[Twaikyont]

Azathtot
1. Rebuilding the kernel is not particularly needed, Pigg just does not really like Android as a system and in its device tried to bring the kernel to the normal (vanilla) form with the efficiency of work.

2. You can do without chroot, use the usual systemv or busybox init.

3. Here it seems like freeadreno (for Adreno) and libhybris are also already. If you get started of course on separate devices.

And utilities that replace the functions of the android are needed for more or less comfortable use of the device.

[Azathtot]

Pigg,
Well, of course, you control dialing a number through AT commands, but how do you switch the microphone to the GSM module?

[Twaikyont]

I haven’t yet configured WiFi using the Internet like this: I took the pppd-mod file (in the archive) and threw it into / system / xbin, gave it the right to run

adb push ~ / Downloads / pppd-mod / system / xbin / pppd-mod
chmod 777 / system / xbin / pppd-mod

And on a computer with Linux on board I run the android_internet script. True in the script you need to specify the interface to connect to the Internet. And run from the root.

sudo bash android_internet

Attached files

adbinternet.zip(86.14 KB)


Post has been editedottiwell - 07.04.16, 18:09

[Twaikyont]

Pigg,
Pasib, it turned out)

insmod /system/lib/8188eu.ko
ifconfig wlan0 up
touch / dev / rfkill # Otherwise swears
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf # Took from the android, so as not to manually fill all passwords
dhclient wlan0
route add default gw 10.10.10.1 # Without prescribing this line, Network is unreachable

It looks like now I can connect directly from recovery to my WiFi, until I finish the xorg.

Post has been editedottiwell - 08.04.16, 17:30

[Junior Developer]

Can I get full instructions for replacing android? I want to do on megafon login +, if it comes out then on Xperia Z2 I will try

[Twaikyont]

Junior Developer,
Actually, there is no instruction as such. For each, it is individual. If you want the _ clean ли linux_non_be_be_be_be_androids_additives, then you will have to take the kernel sources for your device, compare them with the sources of vanilla Linux, remove / leave changes at your discretion; Compile ramdisk, try to start all the drivers under the Linux environment, and if they are also changed under the android, then also dance with a tambourine to return them to the original virgin clean state; You will have to compile all the utilities that are needed for the normal operation of the device from the sources of android, write a bunch of your programs, such as dialers, SMS messengers and the like. If Linux is clean, you don’t need a mermaid’s tear, and you couldn’t fool around too much with a flashing, then you can run Linux from the recovery using a package, and keep the system on a memory card. But you still have to start all the devices. The driver is actually the biggest problem.

[Junior Developer]

I'm going to study in C ++, I don't want to use textbooks. Then I will live here. And so I know java, but from it here beztolku

[Densavagemessiahzine.com]

Guys, just do not swear. I do not understand one thing - why ?! :)

google launched android. Externally with a turn allegedly more to the user. Like, like openness. And, in fact, rightly estimated my strength and capabilities as insufficient for developing my own core from scratch. And the elements are all standard. All that is fundamentally closed. Such cunning from Google. Are you trying to crack the android, or rather the manufacturers of iron? With all their patents, licenses and armies of lawyers. What for? This is their main interest - the technical solution of a specific hardware element and its control program. Millions of people oppose you - exactly in the opposite direction to what you want to do.

What you are trying to solve here, obviously - to me), you need to do something completely different:

Pick up the equipment on which the GNU / Linux distribution works. This is a variant of a conventional desktop computer. There are options and open equipment. So far, of course, weak.

If it’s fundamentally iron, then it's better to navigate, for example, on similar projects.Yocto ProjectandDragonBoard ™ 410c. There are already quite a lot of similar ones with more or less openness.

In extreme cases - I figured it out now - correct it, if I am mistaken - you need to take the source code of twrp - in fact, the android openers. The twrp blessing is open. Kernel twrp, of course, you can customize as you like. Everything for the base of building your own GNU / Linux distribution for the android device in it, including the normal out-of-the-box frame buffer. At least it should be so in her. Further already, if it is very necessary - on a clean and clear system, you can try to tie up any different graphics.

[Twaikyont]

Densavagemessiahzine.com,
We do not argue and do not swear :) Just find out the sequence of actions)
Hack what is closed or not going to license) Just want to use what is.

Densavagemessiahzine.com @ 15.04.2016, 00:51

Pick up the equipment on which the GNU / Linux distribution works.

This is the main problem. There is no money, so you have to work with what you have.
And there are no twrp sorts under my device: (And besides, the frame buffer works, hardware acceleration does not work.

Post has been editedottiwell - 20.07.16, 01:42

[Densavagemessiahzine.com]

[email protected], 08:00

Hack what is closed or not going to license)

This is me slightly inaccurate. It is unlikely that anyone will argue that the main obstacle now is speed in the graphic part. It is clear that where the framebuffer is not deliberately broken in the canonical sense, it will work. But, if my knowledge on the topic is not outdated - now there is not a single open set of native full-fledged graphics management programs for modern, conditionally android devices, as an option - the graphics of their systems on the chip. That is, all such available programs that can be used now are approximations in one form or another and do not provide complete optimization for hardware. Roughly speaking - "crutches". And on them, no matter how overclocked - not run away.

[email protected], 08:00

Just to use that which is.
Densavagemessiahzine.com @ 15.04.2016, 00:51 *
Pick up the equipment on which the GNU / Linux distribution works.
This is the main problem. There is no money, so you have to work with what you have.

Clear. But in general, developer fees are often quite adequate. Prices are not high, reasonable. Working with such a board is fundamentally more noble :) approach. Academically correct. Perhaps, practically, of course, less suitable. Conceptually) I am with you, but for me personally, in principle, it’s disgusting to "pour water on the mill" of Google and others who have joined it. Well, they want to get out there with their graphics - let them live in their little world. What time to spend on them.

[email protected], 08:00

And there are no twrp sorts under my device: (And besides, the frame buffer works, hardware acceleration does not work.

Here for the case of android and twrp, then it is really necessary to choose a specific device for which there is an open code twrp. When I wrote ->to try to bind any different graphics - implied, into a clean working system, in which, of course, graphics output via FB works - then try to integrate specialized graphics hardware control programs to get the same hardware acceleration. Although, I dislike this term. There is no hardware acceleration. There is a full-time job with the highest possible speed of the code accurately and as closely as possible to the conditional characteristics of the projected characteristics of the chip.

Post has been editedDensavagemessiahzine.com - 15.04.16, 21:49

[Densavagemessiahzine.com]

Pigg @ 04/15/2016, 10:29 PM

Che, I did not understand what the "program management of the graphic part." Where does the term come from?

The management program is a name that I consider more correct and understandable than the name that the driver left for the people from someone’s light hand.

[Densavagemessiahzine.com]

Pigg @ 04/15/2016, 10:36 PM

Android devices have all the necessary libraries for using hardware to the fullest. libhybris is a little crutch, yes ... But it does not affect the usefulness of using iron.

Seriously? I am without any hobby. I do not like android. And not really understand it. Recently, simpletons) forced himself to buy an android device after a long break. It is necessary to remember leisurely, that here now.

Here, for example, in my 1 + X in SoC Qualcomm: GPU - Adreno 330. Can you provide a link to the source code for self-assembly of the graphics output management program on this device?

Post has been editedDensavagemessiahzine.com - 15.04.16, 23:16

[Densavagemessiahzine.com]

Pigg,
Thanks for the detailed comment. Here is a lot of useful information for me. I'm really not familiar with the current situation in android. In general, I read, I will figure it out - ask questions), if left.

[Densavagemessiahzine.com]

Ran, updated knowledge. It makes little sense to analyze the current state of the main graphics system in detail ... well) - the GNU / Linux subsystem - I don’t see any sense. First, it will be necessary to demonstrate publicly the knowledge on the topic, and in case of any inaccuracy, this can and will be used against me. I do not see a particular problem in this, rather the opposite. However, taking into account that, in essence, it is a mess - from a certain point of view - in which the graphic part is located - one must conditionally live with all this problematic in order to argue clearly and accurately about all its features. But not a place, and not the time here. On the other hand, the fact that it actually functions and performs its functions deserves respect. I do not refuse the word “mess” - this is my personal interpretation of the situation. I also admit my mistake. I'm a little carried away by the topic. But now I remembered that I didn’t like the principle of building a Linux kernel; I don’t like a lot of everything about the type of open operating systems based on it. I note that I have not used closed since the last century - android does not count. But who is interested in all this: D.

Pigg @ 04/15/2016, 11:01 PM

Proprietary drivers are customized by the manufacturer and there is usually no source for them.

Yes. I am about the same.

Pigg @ 04/15/2016, 11:01 PM

For Android devices, manufacturers compile these libraries with a link to bionics. That's the problem.

The problem does not begin here. In my opinion. Why should we, in principle, mention certain elements specific to android, such as bionic, if we consider replacing android with GNU / Linux.

Pigg @ 04/15/2016, 11:01 PM

They cannot just be used from programs compiled by normal gnu compilers, and they (these libraries) are still a bit tied to the android. Why is it - I do not know.

If it were possible to install not a blob into the kernel, but a module based on open source code and documentation, then the entire avalanche-growing porridge from the mix of support layers would not be required. Here we do not even take into account that in this blob elements can also perform extraneous tasks. It makes no difference - if the iron is closed, it is clear that their execution can be transferred to the microcode level and conditionally lower). The logic is the following: there is a control program of its own - there is no dependence on bionic, there is no dependence on bionic - the compatibility layer in the form of libhybris is not required. Or: the documentation is open - there is a device control program. There is a management program — no reverse engineering is required to get some freedreno. Such programs, in general, are not complete, reliable, effective in a general sense. That is, with the right approach, there is no situation when we are forced to solve problems determined by the initially incorrect basis.

Pigg @ 04/15/2016, 11:01 PM

But there is a crutch of libhybris, which once again solves this question. Oops, that's all. We can build programs with a normal compiler and use three-dimensional acceleration. I only changed a couple of lines in the program with gears and it worked normally with all possible acceleration. And while using the full driver "from the developer."

It is interesting. And, probably, great. But ... from another area in relation to my approach to the topic.

Pigg @ 04/15/2016, 11:01 PM

There are still free drivers. This is when some bodies gather and begin to reverse-engineer proprietary drivers. That is, they are trying to understand how they work and reproduce. What the hell do this? Well, for example, so that libhybris was not needed. Source codes are always available from free drivers (and they are free) - you can compile them right away with a normal compiler. For many GPUs (even mobile ones) there are already such ones. But they really can not be complete. Do not support any functions of iron or something.

This part can be separately considered for a long time, but in principle everything is clear here. Personally, I am against :). Everything is according to the previous scheme - yes, well done, of course - for somehow it is necessary to decide. But first, in fact, we invent a problem for ourselves, then heroically solve it. Fortunately, not everything is so sad here - if you search, you will most likely find a couple of examples where the tests showed better performance than the original.

Pigg @ 04/15/2016, 11:01 PM

Well, here are some very caring processor manufacturers posting their proprietary drivers, but not only the android versions, but also the normal ones. And not only the three-dimensional acceleration libraries mentioned above, but also modules for xorg with two-dimensional acceleration. Take care! Respect (This is me right now about, for example, NVIDIA and its Tegra series).

Thank you - reminded about nvidia. Better than nothing.

In general, I'm sorry that slightly got into the topic. A microcomputer precisely, unambiguously programmed on the basis of complete documentation is one thing, and the transformation of the android phone by some means of tweaks and combinations of certain tools simply because now there are just such - the situation is, of course, different.

[Junior Developer]

Pigg, can you give instructions on how to run the distribution. What to enter in init to run? And install rootfs or img file?

[Pigg]

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 hereutilities, 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.txt

Most 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

[Twaikyont]

Just leave it here. Without adb it's still very sad, especially when it is clear that init is working fine, and xorg does not start)
ADB without Android - device offline

Post has been editedottiwell - 17.04.16, 18:51

[Junior Developer]

adb root displays:
adbd cannot run as root in product builds
So from under the root do not connect?