0

The history of the question can be found here:

1) How to install ubuntu server for lxc on a smartphone (ARM or x86)?

2) Ubuntu Touch (UBports) and Android support for LXC/LXD containers (for running Ubuntu): current state

Sub-questions:

1) What SDK components should be used?

2) How to prepare / convert a bootable image for loading?

3) How to replace the original bootloader to boot another kernel (how to point it to the new path)?

4) What other steps should be performed?

I will try to answer this question myself but would generally prefer some guidance or information from those who have already followed this path. I found the links to previous attempts but they are rather old. The process of linux server installation is very well documented (I am relying on Debian and Ubuntu documentation). Smartphone vendors (like Asus) have tools for unlocking the bootloader on their sites but it is not sufficient for completing the task. The tool just unlocks the bootloader but doesn't change booting menu which means that external SDK tools should be used (there is simply no option in the menu to boot from SD card or network). I.e. the bootloader itself should be changed by SDK. Any links or information would be appreciated.

  • 1
    Android questions allowed here just be about the connection of the mobile device with a computer, Android Studio and similar questions. Android specific questions are off-topic. There's Android Enthusiasts which seems more adequate. – GabrielaGarcia May 21 at 15:00
  • @GabrielaGarcia Thank you for mentoring. I was thinking about that, but decided to leave it here. The reason is simple: it is NOT about Android development - it is about booting of another OS using Android SDK (or any other tool). It would be like asking MS Windows certified professionals on how to install Linux on a laptop running Windows. Ok?))) – Dmitry Somov May 21 at 15:05
  • 1
    Start by browsing xda-developers.com forum and flashing custom ROMs, custom kernels etc. You'll gain some understanding of how Android devices work on the low level. – gronostaj May 21 at 20:20
  • @gronostaj Thank you, I will. However I am not feeling quite right about flashing custom ROM if I am not in full control of the process (this is a basic thing). I should be in control of the bootloader and rom (kernel) in order to be sure that the phone is going to run standard linux, not a spysuite implanted by some "generous skillful guys from the net". Before diving into it I would like to know, whether it is generally POSSIBLE to reach the goal by using the OFFICIAL (i.e. "safe") tools. – Dmitry Somov May 22 at 5:31
  • 1
    @DmitrySomov Android internals are a complex topic. Dealing with them in a practical manner is a great learning opportunity. I think you don't understand the fundamental structure and flashing procedure of an Android device and this knowledge is a must for more advanced topics, such as building custom kernels. That's why I recommend to learn by small steps. – gronostaj May 22 at 5:51
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.