I've made some progress researching for solution:
1) Wiped all user data from the devices to be used for experiments (Booting in recovery mode > wipe cache / wipe data / factory reset)
2) Looked through unofficial sources
There is a number of articles and forum posts in the net. Some of them are useful. Most of them are rather old and were last updated long ago. The bad thing is that most of them contain info on rooting the devices (i.e. breaking the OS security by deliberately installing a rootkit exploiting a known vulnerability to escalate its privileges) and links to untrusted / low reputation scripts containing such rootkits. This potentially harmful information is mixed with useful parts giving the general overview of the available options.
Many articles are published on xda-developers.com site, its forum section and wiki.
Some useful wiki articles:
Those wiki articles are generally maintained rather poorly (last edits were in 2015).
3) Chose the platform (x86, ASUS Zenfone2)
In my case I was choosing from a pool of my own used Android devices. Most of them have ARM-based CPUs. The latest and most powerful was ASUS with x86 Intel CPU (64bit instruction set). The other reason to choose x86 was better Linux support and the requirement to run x86/AMD64-based lxc containers. Choosing ARM would require development of a separate container branch or utilizing some sort of emulation / conversion tools (not sure that such tools are efficient / well maintained / supported).
4) Realized that the goal might be unreachable with official (vendor supported) tools
I mailed ASUS tech support regarding the usage of their bootloader unlocking tool. But the answer was simple: "The tool just unlocks the bootloader we cannot help you with further steps, we even cannot tell you what happens if you use the tool". I.e. the tool is useless (I even don't know whether it worked somehow in my case and how it is different from
fastboot oem unlock). In order to activate the tool I first had to downgrade to Android 5.0 since it was not supported in newer versions of ROM. All things concerning changing the bootloader and booting other images are unofficial, unsupported, not recommended, warranty breaking etc.
5) [OPTIONAL: NOTE1] Chose and installed the recovery (not supported officially by phone or OS vendor)
'Recovery' - is an android jargon for bootloader / BIOS (a separate partition in device memory keeping a lightweight linux-based system which boots first and presents a bootloader menu with available tools like 'backup', 'wipe cache', 'factory reset', 'load custom ROM' etc.). Original OEM recovery doesn't allow to flash custom ROM or boot custom OS.
The project seems to be mature, well structured, actively maintained and generally makes the impression of a valuable global open source project. The amount of supported devices and vendors is very remarkable. Of course I would prefer to use the recovery version maintained and endorsed by the phone vendor and downloaded from their official site (in my case ASUS).
NOTE1: After installing TWRP and getting more info on SDK Tools I realized that it was probably possible to flash custom ROM without installing a custom recovery (by utilizing adb and fastboot tools from SDK platform-tools package).
NOTE2: The installation process is well documented for each model. I used 'Fastboot Install Method'. Brief description of the method (please refer to the page on TWRP site relevant to your device): 1) Install Android SDK tools (you will need only adb and fastboot components from platform-tools package), 2) Activate 'developer mode' on your device by tapping 7 times on 'Build Number' line in Settings > About menu, 3) In Settings > Developer Options enable 'USB debugging', 4) Connect with your PC through USB, 5) On your PC you may check that the device is connected by passing the command
adb devices, 6) Run
adb reboot bootloader for entering fastboot mode, 7) Place the correct image file downloaded from TWRP site and renamed 'twrp.img' into the folder containing adb and fastboot binaries (normally 'platform-tools' folder), 8) Run
fastboot flash recovery twrp.img. In my case the image was successfully flashed although adb reported an error
FAILED (remote: Permission denied), 9) Run
fastboot reboot. You may reboot your device from TWRP menu as well. The important thing is to let TWRP patch your stock ROM (partition with Android OS) to prevent it from wiping TWRP and replacing it by the stock recovery after it boots. Otherwise you will have to repeat the process. Yeap, that was scary, hence step #1.
6) Dived into official AOSP documentation
After losing hope of using a black-box approach to Android OS for reaching the goal I started reviewing general sections on Android OS architecture and requirements to supported devices.
Good pictures (architecture):
Bootloader and security info:
Main conclusion: Android has definitely introduced useful OS features for running reduced Linux kernel on a diverse range of proprietary (FMCG-world) devices with loose hardware standards. One of the most useful features which could and probably should be adopted by mainstream Linux is HAL layer of abstraction allowing to deal with the zoo of propitiatory drivers in a reasonable way. Modular kernel thing with splitting the kernel into SoC-dependent and board-dependent parts, power saving features and security features are also notable.
Good news: Linux kernel developers and some distro vendors are well aware of all these good parts and are doing their best to introduce the corresponding changes. Official stats (see Figure 2 of the corresponding AOSP doc section) show good evidence of convergence between AOSP code and mainstream Linux. There is a definite positive economic effect from convergence to the both sides (AOSP and Linux communities). When it comes to such stakeholders as Google and hardware producers who are protecting their investments they seem to pull in the opposite direction. Google protects their investments into the ecosystem and user base, hardware producers are protecting their investments into developing and producing hi-end hardware. The friction between these two forces creates some sort of a positive vector. In my opinion there should be some sort of an agreement in place between Google and hardware producers which regulates this friction in a wise manner. For example, hardware producers may delay committing their board-specific driver blobs into the Linux kernel for say 2-3 years (for SoC-specific driver blobs this period perhaps should be shorter). This would guarantee to Google and AOSP developers that Android ecosystem skims all the cream off the market (all new modern hi-end hardware device purchases, ad revenue, paid software and services from hi-end users). After those 2-3 years the devices (no longer considered hi-end) are released into the free by committing the driver blobs into the Linux (highest grade hardware vendors would of course prefer to commit source code). The length of the period is pretty close to the usual warranty period set for most devices by hardware vendors and a period of official Android updates (including security updates) distributed by those vendors. Fair enough.
Bad news: There seems to be really hard to negotiate such a deal (hereinafter - the Deal) in a wise and explicit manner. The main problem is in its global nature. Think of the possible legal considerations (antitrust laws in various jurisdictions, cross-border tax issues etc. etc.), number of hardware vendors (OEMs, ODMs, SoC producers etc. etc.) and other stakeholders involved (Google, AOSP, Android developers, Linux, Linux distro vendors - server, desktop and possibly mobile, other Linux-based projects, GNU, FSF, etc. etc. down to the end users). The lack of a deal is definitely slowing down the convergence between Linux and AOSP to our (users) common regret. From the hardware standpoint full convergence was possible several years ago when mainstream [multi-core x86 CPU / > 2Gb RAM / > 16Gb flash drive]-devices reached the market. The problem is evident when this hardware cannot be used for running a standard Linux kernel (a server distro, not even desktop). Installers are absent, flashing tools are not officially supported by vendors, documentation is scarce and disperse. In June 2019 things could be much better...
7) The next step would be monitoring efforts performed by the leading conversion-driven communities and supporting vendors as well as the steps made by hardware vendors and AOSP / Google to negotiate the Deal.