Creating updater.zip for TWRP from partitions or images - Android Software Development

Utility to create ROM from images of partitions, partitions themselves, or all this mixed up.
For arm/arm64 devices
(For x86 / x64 devices I will do if there are requests for creation)
For experienced users only who can create and restore backups.
It does not have an interface (work with the command line).
Starting from the terminal emulator in the Android OS (you need a root) or the TWRP terminal.
You can quickly create the installer of partitions: TWRP, boot, edited GSI, vendor + boot for GSI, modem, etc.
Supports sparse images.
USAGE:
Help is invoked by running the utility with no arguments, with the -h --help switches, or appears along with an error message. Content:
Code:
Usage:
romi [<comp>] <out_file> <block or file> [<block or file> ...] [<banner>]
<comp> may take the following values:
--fast faster but bigger size
--norm default with no arg's
--good better compression but longer
--high it takes a very long time
<banner> may take the following values:
--sban=<text file> adds text from the specified file to the beginning of the ROM installation
--eban=<text file> adds text from the specified file to the end of the ROM installation
At least two arguments - the result file (output) and the base file (incoming). And in that order. Example:
Code:
romi /sdcard/twrp-installer.zip /sdcard/recovery.img
If you want to change the default compression level for a session, use one of the keys suggested in the quick reference. Example with minimal compression:
Code:
romi --fast /sdcard/twrp-installer.zip /sdcard/recovery.img
There can be as many objects included in the package in ROM as there is enough space for the selected drive and device capacities to create the resulting file. Example:
Code:
romi /sdcard/stock-mod-installer.zip /sdcard/boot.img /dev/block/bootdevice/by-name/vendor system
In the last example, I will try to explain the "smart" principles of sampling.
As you can see, three objects were transferred for processing: the image file of the drive partition, the drive partition, and the "mask" of the drive partition.
The utility will check for the presence of the file and whether there is a block device of the same name; when creating the ROM, boot.img itself is used.
Check for the presence of a block device and use it when creating a ROM.
Check the "mask" of the partition and, if it finds a block device corresponding to it, add this block to ROM.
Adding banners that will be displayed at the beginning and/or at the end of the installation of the generated ROM:
Code:
romi --fast /sdcard/twrp-installer.zip /sdcard/recovery.img --sban=/sdcard/start-message.txt --eban=/sdcard/end-message.txt
You can add only the initial banner, you can add only the banner to complete the installation, you can both, you can add nothing.
XDA:DevDB Information
romi, Tool/Utility for all devices (see above for details)
Contributors
nonamer1990
Source Code: https://drive.google.com/open?id=12gEApT6yk-5R8p8ymOIOL-5PJSiQa1p-
Version Information
Status: Stable
Current Stable Version: 1.0
Stable Release Date: 2020-05-19
Created 2020-05-19
Last Updated 2020-05-19

Related

[HOWTO] "Partitioning" your Nexus S using LVM

Always wanted a larger /data partition? Want to add a swap partition or an extra partition for your Debian/Ubuntu/Fedora chroot? Want your ROM to have the combined /data and /sdcard of Honeycomb and ICS devices? Then this guide is for you.
Table of contents
This post: background information
(Advanced) users: modifying your phone to use LVM
Developers: adding LVM support to a ROM
Building LVM for Android
The Linux [URL="http://sourceware.org/lvm2/]Logical Volume Manager[/URL] (LVM) is a set of tools which allows you to create virtual disks ("logical volumes", "LVs") backed by a set of real storage devices ("physical volumes", "PVs") organized into "volume groups" ("VGs"). Using LVM, you can:
Create logical volumes which are larger than any of the individual physical volumes available on your device's real storage.
Create an arbitrary number of logical volumes of arbitrary size, regardless of the number of physical volumes or partitions available on your real storage devices. You could, for example, add a dedicated swap partition, or create a separate /system and /data for a dual-boot setup.
Take a snapshot of a logical volume -- a copy of the LV which only stores differences between it and the original (requires additional kernel support). You could, for example, take a snapshot of the external storage LV and export it via USB mass storage to a computer, without needing to unmount the LV from your device.
Grow or shrink logical volumes without unmounting the file system ("online resize", requires filesystem support).
LVM was developed to manage storage on Linux servers and workstations, but was also used by Palm/HP in WebOS devices. It uses the Linux device-mapper technology used in Android for apps installed on the SD card, so any Android kernel will work with LVM.
This guide was developed with the Nexus S in mind, but the technique described should be applicable to many other Android devices as well.
Modifying your phone to use LVM
WARNING WARNING WARNING
While unlikely, you could brick your phone if you do this incorrectly!!!
Read this guide completely before attempting. If you don't understand the procedure, read it again until you do. If you still don't understand, wait for someone else to make this easier. If you're not sure you understand, you probably don't.
BACK UP EVERYTHING ON YOUR PHONE, INCLUDING THE CONTENTS OF /sdcard, BEFORE ATTEMPTING THIS PROCEDURE! This will erase everything on your phone.
The preassembled images attached to this post are for Nexus S GT-i9020T running stock Android 4.0.4 IMM76D ONLY. They may or may not work with other phones and ROMs. (See the next post for how to modify any ROM to use LVM.)
You will need:
A Nexus S with unlocked bootloader
A computer with fastboot and adb installed and working
A USB cable
Factory images for your phone, in case something goes wrong
Procedure:
Take a nandroid backup of your phone and copy it to your computer. We'll use it to restore the ROM later. You MUST copy the backup to your computer! This procedure will erase EVERYTHING on your phone, including the contents of /sdcard.
Download the boot and recovery images attached to this post. Reboot your phone into the bootloader, then flash the recovery to your phone using fastboot:
Code:
fastboot flash recovery recovery-lvm-clockwork-5.0.2.0-crespo.img
(GPL information: this is the stock kernel image from ClockworkMod 5.0.2.0. For LVM source, see this post.)
Boot into recovery.
Enter the shell on the device:
Code:
adb shell
In the shell on the device, do the following (# is your prompt):
Code:
# /lvm/sbin/lvm pvcreate /dev/block/mmcblk0p1 /dev/block/mmcblk0p2 /dev/block/mmcblk0p3
# /lvm/sbin/lvm vgcreate lvpool /dev/block/mmcblk0p1 /dev/block/mmcblk0p2 /dev/block/mmcblk0p3
This marks the partitions normally used for /system, /data, and /sdcard for use with LVM, and creates an LVM volume group named "lvpool" using those devices.
In the shell on the device, set up your desired logical volumes (partitions).
Code:
# /lvm/sbin/lvm lvcreate -L 320M -n system lvpool
# /lvm/sbin/lvm lvcreate -L 1G -n userdata lvpool
# /lvm/sbin/lvm lvcreate -L 10G -n media lvpool
[...]
This creates the mandatory logical volumes named "system", "userdata", and "media", which will be mounted on /system, /data, and /sdcard, respectively. Replace the argument to -L with the desired size of each partition. (/system needs to be at least 300 MB to fit the stock ROM.) You can create additional volumes similarly:
Code:
# /lvm/sbin/lvm lvcreate -L [size] -n [name] lvpool
replacing [size] with the desired size and [name] with the desired name. You have a little less than 15 GB space in the volume group to work with; depending on how many partitions you want to create, you can adjust the size of the "media" and "userdata" logical volumes as required.
Reboot back into recovery. Mount the USB storage on your computer. On your computer, format your phone's USB storage as you would a USB flash drive.
Copy your nandroid backup from your computer onto your phone.
Reboot back into recovery. Restore the nandroid backup.
Reboot into the bootloader. Flash the boot image to your phone via fastboot:
Code:
fastboot flash boot boot-lvm-crespo-IMM76D.img
(GPL information: this is the stock kernel image for IMM76D. Source is available from AOSP git. For LVM source, see this post.)
Reboot. You should have a working device running on LVM.
Additional tips and hints
To see the logical volumes you've created, use
Code:
# /lvm/sbin/lvm lvs
and to see how much free space you have remaining in the volume group, use
Code:
# /lvm/sbin/lvm vgs
If you want to delete a logical volume (for example, if you screwed up), use
Code:
# /lvm/sbin/lvm lvremove /dev/lvpool/name
(replacing "name" with the name of the LV you want to delete).
It's often useful to leave a bit of free space in the volume group (512 MB to 1 GB or so). This gives you a bit more flexibility to modify the layout or grow partitions in the future, and allows you to take snapshots of logical volumes.
Removing LVM from your phone
Flash a standard recovery such as the regular ClockworkMod recovery to your phone.
Do a full wipe/factory reset.
Restore your phone from a backup.
If things go really wrong, flash the factory image to your phone via fastboot.
Modifying an existing ROM to use LVM
(This is a condensed version of the full guide: https://raw.github.com/steven676/android-lvm-mod/master/HOWTO-MOD)
You will first want to grab a copy of the binaries and config files by cloning my git repository: https://github.com/steven676/android-lvm-mod.
Unpack the ramdisks from your boot and recovery images. Make the following changes:
Copy the contents of lvm-bin/ in the git repository to lvm/ in the ramdisks.
Copy devices/crespo/lvm.conf to lvm/etc/lvm.conf in the ramdisks.
For the boot image, integrate the changes in devices/crespo/boot/init.herring.rc-changes.diff into your init.herring.rc.
For the recovery image, integrate the changes in devices/crespo/recovery/init.rc-changes.diff into your init.rc.
For the recovery image, copy devices/crespo/recovery/recovery.fstab to etc/recovery.fstab.
Repack the ramdisks and create new boot and recovery images with them (the original kernels are fine to use).
If creating a flashable zip to install your ROM, you will also want to modify the installer script to set up the LVM volume group and logical volumes (see the previous post).
If you're building your own kernel, consider enabling CONFIG_DM_SNAPSHOT in your kernel's build configuration, to allow taking snapshots of logical volumes.
Remember that LVM is released under the terms of the GPL v2 (same as the Linux kernel), so you are required to comply with the GPL's source distribution requirements with respect to LVM.
More extensive modifications (such as changing the devices used to form the volume group) are possible; see the full HOWTO guide for details.
Building LVM from source for Android
The LVM source was written for standard glibc-based GNU/Linux systems, and doesn't build agains Android libc. We could invest time and effort into porting it to Android, but it's easier to just statically link the LVM binary against glibc (we already have to use a statically linked binary, since the boot image doesn't ship shared libraries).
To build LVM with glibc, you will need either an actual GNU/Linux ARM system with a development environment (gcc, make, and glibc header files) set up, or a GNU/Linux ARM cross-compiler toolchain (more difficult to set up). The binaries in lvm-bin/ were compiled with an Emdebian squeeze/armel toolchain running on a Debian squeeze/amd64 machine; this procedure has also been tested with a Nexus S running a Debian squeeze chroot (though any recent Linux distribution and any device should do). The Linaro prebuilt GCC toolchain and the CodeSourcery CodeBench Lite toolchain for ARM GNU/Linux should work; the Android NDK toolchain will not.
Getting the source
Clone the lvm-mod git repository. Then, in the newly cloned repository, do
Code:
git submodule init
git submodule update
You will have a copy of the LVM source (as used to build the binaries in lvm-bin/) in lvm-src/.
(Alternately, clone https://github.com/steven676/lvm2 and checkout branch android-lvm-mod. You can also use upstream's git repository or source tarballs; see their website for details.)
Building the source
(This is a condensed version of the full guide: https://raw.github.com/steven676/android-lvm-mod/master/HOWTO-BUILD)
These instructions are written for a native build (building in a Debian/Ubuntu/Fedora chroot on an actual ARM device).
Configure the LVM source:
Code:
$ ./configure --prefix=/lvm --enable-static_link --disable-readline \
--disable-selinux --with-pool=none --with-cluster=none \
--with-confdir=/lvm/etc --with-default-run-dir=/data/lvm/run \
--with-default-system-dir=/lvm/etc \
--with-default-locking-dir=/data/lvm/lock \
--with-optimisation="-Os -march=armv5te -mtune=cortex-a8 -mthumb"
For a cross build, you need to set up the system to run ARM binaries using QEMU (see the full HOWTO for details). (For extra credit, fix the build so that it works with the configuration produced by running configure without qemu-arm enabled.) Then configure the source with:
Code:
$ export CC=arm-linux-gnueabi-gcc # replace with your cross compiler
$ ./configure --host=arm-linux-gnueabi \
--prefix=/lvm --enable-static_link --disable-readline \
--disable-selinux --with-pool=none --with-cluster=none \
--with-confdir=/lvm/etc --with-default-run-dir=/data/lvm/run \
--with-default-system-dir=/lvm/etc \
--with-default-locking-dir=/data/lvm/lock \
--with-optimisation="-Os -march=armv5te -mtune=cortex-a8 -mthumb"
Build the source:
Code:
$ make
Grab the pieces you need: the statically linked, unstripped lvm binary is located in tools/lvm.static, and a sample configuration file is in doc/example.conf.
(reserved)
Hello steven676,
This post is helpful to me!
But I have some questions on LVM as I am new to it.
1. Is it possible to use LVM only on one pv, say /sdcard?
2. If 1. yes, will lv's on a pv be linear mapped, that is, lv's in a pv are placed one after one?
3. now that removing lvm is possible, is it also possible to backup lvm setting, and switching between non-lvm and lvm environment?
Thanks
solarispika said:
1. Is it possible to use LVM only on one pv, say /sdcard?
Click to expand...
Click to collapse
Sure. Just modify the arguments to pvcreate and vgcreate accordingly:
Code:
# /lvm/sbin/lvm pvcreate /dev/block/mmcblk0p3
# /lvm/sbin/lvm vgcreate lvpool /dev/block/mmcblk0p3
solarispika said:
2. If 1. yes, will lv's on a pv be linear mapped, that is, lv's in a pv are placed one after one?
Click to expand...
Click to collapse
Probably, but in general it is not safe to assume this. Imagine the following sequence of commands:
Code:
# /lvm/sbin/lvm lvcreate -L 1G -n vola lvpool
# /lvm/sbin/lvm lvcreate -L 1G -n volb lvpool
# /lvm/sbin/lvm lvresize -L +1G /dev/lvpool/vola
What's likely to happen here is that vola is going to be split into two segments on disk, like this:
Code:
[ 1GB vola ][ 1 GB volb ][ 1 GB vola ][ remaining free space ]
There are ways in which you can give LVM hints as to what on-disk layout you want, and the LVM tools will generate information about the current layout in /data/lvm/backup if that directory's available (and mounted read-write) at the time, but in general, it's best to treat the on-disk layout of a logical volume as unknown. In practice, unless you have physical volumes with widely varying characteristics in the same volume group (say, an SSD and some spinning-platter hard disks), you shouldn't need to worry about the actual layout.
solarispika said:
3. now that removing lvm is possible, is it also possible to backup lvm setting, and switching between non-lvm and lvm environment?
Click to expand...
Click to collapse
If /data is mounted read-write, running
Code:
# /lvm/sbin/lvm vgcfgbackup
will create a human-readable backup of the current LVM volume group metadata in /data/lvm/backup (if that directory is available and mounted read-write).
I'm not sure what you mean by "switching" between non-LVM and LVM environments. If you mean going between an unmodified stock boot image and an LVM boot image, the answer is yes, but you won't have access to any of the data in your LVM logical volumes while running an image not configured for LVM, and you need to be careful not to accidentally format the LVM physical volume.
If you're asking about having two or more ROMs on the phone, one installed to the normal /data and /system eMMC partitions, and another on LVM logical volumes, the answer is also yes, but both ROMs will need modified ramdisks. The one for the eMMC-installed ROM should only mount /sdcard from LVM, while the others should be set up to mount /data and /system from LVM as well.
Good write up;-)
wonder if lvm swap could be connected as extra memory .
Sent from my Nexus S using XDA
wizardslovak said:
wonder if lvm swap could be connected as extra memory .
Click to expand...
Click to collapse
Sure, of course. From my phone:
Code:
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/mapper/lvpool-swap partition 65532 28196 -1
It works just fine, even if it's not a setup I'd use on a mission-critical server.
Hey Guys,
Thanks for this awesome guide.
I just have a quick question, what are the advantages of using LVM instead of the normal partitioning?
I just want to know cause i might added to my rom.
Thanks
mandaman2k said:
I just have a quick question, what are the advantages of using LVM instead of the normal partitioning?
Click to expand...
Click to collapse
Primarily flexibility in deciding the number and layout of partitions -- see the first post.
Sounds good . Ill try it once home ;-)
Sent from my Nexus S using XDA
I just pushed a couple of changes:
Updated prebuilt binaries and LVM source to 2.02.96.
Fixed the instructions for cross compiling LVM.
The boot and recovery images attached to the second post have been updated accordingly.
Is this the only way to make the device function like HC/ICS/JB devices that ship with combined storage?
Are the images from Google partitioned with internal/external storage or are the latest images partitioned with a layout similar to the Galaxy Nexus?
CocoCopernicus said:
Is this the only way to make the device function like HC/ICS/JB devices that ship with combined storage?
Click to expand...
Click to collapse
If you want a setup that's exactly as on a 3.0+ device with "SD card" data stored in /data, then yes, this is the only way I know of. If you just want MTP functionality, then no.
CocoCopernicus said:
Are the images from Google partitioned with internal/external storage or are the latest images partitioned with a layout similar to the Galaxy Nexus?
Click to expand...
Click to collapse
Official Google software builds use separate userdata and media partitions and continue to offer the 2.x-style USB mass storage access. I'm not sure the partition layout is adjustable in software -- the eMMC presents an EFI partition layout which no one seems to have figured out how to change.
Cool, thanks. Yea, I'm not too interested in the MTP functionality, I just don't want to deal with internal/external storage after using the Galaxy Nexus.
Swap partiton
Hi..
how i can to create a swap partition of 1G and added to system??
I had create a 1G partition "swap" but system no activated this partition.
xxmurdocxx said:
Hi..
how i can to create a swap partition of 1G and added to system??
I had create a 1G partition "swap" but system no activated this partition.
Click to expand...
Click to collapse
You'd need to format the swap partition:
Code:
# mkswap /dev/lvpool/swap
Also, you need to make sure that your kernel has swap support (CONFIG_SWAP=y -- the default kernel does not have this) and that your init scripts are enabling the swap partition (swapon /dev/lvpool/swap).
One other note: you might find lag to be somewhat severe with a 1 GB swap partition -- I'd suggest smaller.
I'm finally getting around to messing with my NS. From what I understand I can't just modify an existing rom(stock JB in this case) to use the larger partitions without compiling an entire new rom, right?
Which would mean I'd be at the mercy of whoever created the ROM to update when an OTA rolls around?
CocoCopernicus said:
I'm finally getting around to messing with my NS. From what I understand I can't just modify an existing rom(stock JB in this case) to use the larger partitions without compiling an entire new rom, right?
Which would mean I'd be at the mercy of whoever created the ROM to update when an OTA rolls around?
Click to expand...
Click to collapse
No, you can modify an existing ROM yourself. It's most definitely not the simplest process around, though -- see the documentation at the top of the thread for instructions. As I say there ... read thoroughly and understand before attempting.

[ROM-x86] Bliss-x86 [oreo 8.x] for PC's

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Team Bliss is pleased to present to you
Bliss based on Android Oreo
Our focus is to bring the Open Source community a quality OS that can run as a daily driver, syncing your apps, settings and customizations across all platforms you run Bliss on.
Bliss OS comes with a wide selection of customization options, functions, and is even themable out of the box using rootless Substratum. With so many options available, you will soon find out why we call it Bliss.
Notice
- Please do not ask for ETA's;
- We will not tolerate any rudeness or anyone being disrespectful in this thread. Moderators, feel free to enforce anything you feel is necessary to stop bad posts;
- We will do our best to answer your questions or concerns as soon as possible.
AIO Thread​
Bliss Source
https://github.com/BlissRoms
Bliss-x86 Source
https://github.com/BlissRoms-x86
BlissRoms Devices Source
https://github.com/BlissRoms-Devices
BlissRoms Kernel Source
https://github.com/BlissRoms-Kernels
BlissRoms Vendor Source
https://github.com/BlissRoms-Vendor
OpenGapps are included in Bliss-x86. YAY!!
Our Official downloads have been cleaned in preparation for Android Pie
Bliss OS x86 - Current Releases
All recent builds have been moved to Sourceforge
Bliss OS x86 - Sourceforge Archived Releases
Bliss OS x86 - AFH Archived Releases
Team Bliss is not responsible in any way for anything that happens to your device in the process of flashing.
Please familiarize yourself with flashing and custom rom use before attempting to flash the rom.
Please make sure you download the correct version of Bliss for your specific device. The links are labeled clearly.
Please scroll down to second and third posts for install instructions and downloads
one build, thousands of potential component combinations, so not everything will be working on every machine, and we know this.
If you have a major bug to report that has not been reported already, please take the following steps to report it to us. It will save you and our team quite some time.
-Download the Catlog app from the Play Store.
There is also a donate version which you can purchase to show appreciation.
-After downloading the Catlog app, go to the app settings, and change the log level to Debug.
-Clear all previous logs and take the exact steps to produce the error you are receiving.
-As soon as you receive the error (probably a force close), go straight into Catlog and stop the log recording.
-Copy and paste the entire log either to Hastebin or Pastebin
-Save the log, and copy and paste the link into the forum with a brief description of the error.
-You can also open trouble tickets on our website for bugs.
A huge thanks to Chainfire, CM/LineageOS, Android-x86, Jide, @farmerbb & all the other developers who work hard to keep all the great features coming!
We really appreciate all your knowledge & hard work!
If someone takes it upon themselves to donate to us, of course it will be appreciated, and all funds will be used to pay our server and upkeep fees.
If someone wants to donate, our PayPal link is below.
PayPal Link
Very Important Information
Team Bliss will allow some minor off-topic comments in our development threads.
Please post in the general forums for off-topic comments and/or questions.
Overall, please keep comments relevant to development, as this better helps you and our team
when trying to determine problems that users are having.
We appreciate all levels of knowledge in our threads, and therefore we ask that
the seasoned members be helpful to those with less knowledge.
Most importantly, do NOT troll those with less knowledge than yourself.
Should you feel inclined to not abide by our request, the XDA Moderators may be called in to remove posts.
We thank you for adhering to our thread rules.
Thank you for using Bliss! And have a Blissful Experience!​
XDA:DevDB Information
Bliss-x86, ROM for all devices (see above for details)
Contributors
electrikjesus, rwaterspf1, ElfinJNoty
Source Code: https://github.com/BlissRoms-x86/kernel_common
ROM OS Version: 8.x Oreo
ROM Kernel: Linux 4.x
ROM Firmware Required: Read the Instructions
Based On: AOSP
Version Information
Status: Stable
Current Stable Version: Bliss-x86 7.1.x Stab
Stable Release Date: 2017-03-19
Current Beta Version: Bliss OS 10.0 PC Bet
Beta Release Date: 2017-03-21
Created 2017-01-09
Last Updated 2018-09-01
Reserved
The Instructions
**These instructions are based on the Android-x86 project's installation guide. We have not changed the installer, so all actions still apply. Also thanks to @bg260 for his contributions, this guide was adapted partially from his work**
*** Team Bliss will not accept any responsibility for users who have not read or understand the instructions, or any damage done to user machines due to lack of understanding all risks involved. You accept all responsibility by continuing beyond this point. ***
*** Any questions, install issues, bug reports, etc will be delightfully ignored unless accompanied with a log, device info, build info, install method, and any other information required to diagnose your issue as NOT user error ***
Please note that our Archived build instructions can be found in the fourth post. Many of the processes may still apply to our newer builds too, so please read and follow the links provided to learn more about each step. Thank You
Easy Install For Bliss-x86 8.x/10.x UEFI/ESP (64bit)
** This method might be the easiest currently **
For the overall instructions on using this method, please refer to the tools original thread: https://forum.xda-developers.com/android/software/winapp-android-x86-installer-uefi-t3222483
I have taken some time to update the tool for easy install on UEFI/ESP machines. The builds I produce can be found here:
https://github.com/BlissRoms-x86/Androidx86-Installer-for-Windows/tree/master/bin
And the source for those builds can be found here: https://github.com/BlissRoms-x86/Androidx86-Installer-for-Windows
This tool should work on RemixOS as well, but I have not tested it yet (been too busy on this project)
Part 1 - Using the Installer
The installer has been updated, and it will accept the .iso files for our 8.x/10.x releases. Just follow the prompts the installer gives. Refer to the orig thread for any questions, and please search before asking.
Part 2- Switching the UEFI/EFS boot entry
Open the EasyUEFI tool mentioned above, then switch the UEFI/EFI entry it created to boot first. Close and reboot.
How to "prep" a USB using syslinux EFI to run Bliss 7.x/10.x
Thanks to @IcedCube
IcedCube said:
For those who are a little too bleeding edge and like to adventure outside the recommended method that @electrikjesus recommends, here's how to "prep" a USB using syslinux EFI to run Bliss 7.x/10.x.
Also, I'd appreciate it if he could link it in the first post as a "experimental syslinux EFI" method, because this is what I recommend if some Chinese tablets don't want to boot grub.
DO NOT BLAME HIM IF YOUR DEVICE CATCHES FIRE AFTER DOING THIS. BLAME ME INSTEAD.
I strongly recommend using a Linux VM or a Linux box for this. Ensure you have the latest version of unsquashfs (part of squashfs-tools) too. Grab the latest build of Bliss x86 7.x/10.x before continuing!
Grab the ZIP file from my original post, https://forum.xda-developers.com/showpost.php?p=74977694&postcount=1237, and extract it to the root of your USB drive. This will bootstrap syslinux EFI onto it.
Make a folder, if you haven't already done so, called "android".
Now, open up the ISO in an archiver. Extract from the root directory of the ISO image the following to your USB drive's "android" folder: initrd.img, ramdisk.img, kernel.
Extract system.sfs to a folder somewhere, maybe in /tmp.
Open a terminal and change directory (using 'cd') to /tmp. Run 'ls' and confirm you see system.sfs shown in the file list. If you get no output, start over as you misplaced a file.
Code:
cd /tmp && ls -al system.sqs
Run the following code:
Code:
unsquashfs ./system.sqs
This will make a new directory called "squashfs_root".
Bliss 7.x users, this is important: If you are using Bliss 10.x then skip just this step. Change directory to squashfs_root and run a 'ls'. You should have only one file, a system.img inside that directory. Copy that file to your USB's "android" folder.
Bliss 10.x users, this is important: If you are using Bliss 7.x then skip just this step. If you take a look inside squashfs_root, you will notice it's a complete android root filesystem. What we need to do is to move the stuff into a system image. The following will make a 2GB system.img file, format it, mount it and copy the contents of the extracted squashfs into that new disk image.
Code:
mkdir /mnt/tempMount
truncate /tmp/system.img --size=2G
mkfs.ext4 -m0 /tmp/system.img
sudo mount -o loop /tmp/system.img /mnt/tempMount
sudo cp -prv /tmp/squashfs_root/* /mnt/tempMount/
sync
sudo umount /mnt/tempMount
The sync process might take some time. Now copy the /tmp/system.img file to your USB's android folder.
Alright, now that's the system image done. Now you need to make a data image. That's easier than system image. First, find where your USB drive is mounted, it might be at "/media/icedcube/DROIDUSB" or something and cd to the android folder on it:
Code:
cd /media/icedcube/DROIDUSB/android
. If you're using Ubuntu or any other good distro and have a "Open location in Terminal" option in your File Manager, use that as a shortcut. Now run these commands to make a 3GB data image file - you could try with 4GB but FAT32 maxes out at 4GB per file and I prefer using FAT32 as I'm not sure if the kernel supports exFAT or NTFS properly.
Code:
truncate data.img --size=3G
mkfs.ext4 -m0 data.img
sync
This will be an completely empty ext4 disk image, but will be enough to kickstart Bliss.
Finally, check to ensure everything is in check like so:
Code:
<ROOT>
- syslinux.cfg
- android/
-- kernel
-- system.img
-- data.img
-- ramdisk.img
-- initrd.img
- EFI/
-- BOOT/
--- bootia32.efi
--- bootx64.efi
--- ldlinux.e32
--- ldlinux.e64
Need to add some kernel parameters? Don't panic. Just open syslinux.cfg and add them onto the append before the "initrd=/android/initrd.img" statement.
Unmount the USB from your computer. Carefully plug it into your tablet or laptop and use the BIOS to boot UEFI from USB Drive, partition 1. If all goes well, you will get a black screen with small white text saying "Booting Android..." followed by loading files. You should get the Linux kernel text, then see the Bliss Oreo animation play after a few seconds/minutes depending on your USB drive read/write speed.
Click to expand...
Click to collapse
Custom Install For Bliss-x86 8.x/10.x UEFI/ESP (64bit)
***Again, Team Bliss is not responsible for any damage, tears, lost time, alien abductions, experimental relationships or anything else if things go south with this install. Don't even think about blaming us. You automatically agree to these terms upon continuing the install.***
Part 1 - Mounting Your UEFI/ESP Partition
You will want to make sure you can view hidden and system files in Explorer options (if you need to , google it), Once you do that, hit the start menu, and type in CMD, and then right click, and open as administrator. It should look like the window image attached to this post.
Once that is open, type in:
Code:
mountvol X: /S
Then check to see if it is mounted already
Start Task Manager; a) CTRL+ALT+DEL -> Task Manager b) CTRL+Shift+ESC c) Right click the taskbar and select Task manager.
Click "File" tab -> "Run new task" -> "Browse" -> "This computer" -> SYSTEM (X or type in "x:" in the filepath bar"
If you cannot access X:, then that could mean one of three things. 1) You have an ESP setup, and just need to scroll down to the ESP System Partition setups section, or 2) You have a legacy MBR setup and just don't know it. or 3) Your setup falls within the other category. Check below for some insight, or the second post for more links to help you figure things out.
ESP System Partition setups
Windows 10 has EFI partition sometimes already mounted under Z: letter, but it's hidden.
A very quick and easy way to access ESP (EFI System Partition) in Windows 10: (no command line use needed!)
Start Task Manager; a) CTRL+ALT+DEL -> Task Manager b) CTRL+Shift+ESC c) Right click the taskbar and select Task manager.
Click "File" tab -> "Run new task" -> "Browse" -> "This computer" -> SYSTEM (Z or type in "z:" in the filepath bar"
Now go to boot/grub/grub.cfg and edit it accordingly with Notepad++ or other editor
Save the file and your're ready to go
If this still doesn't work - try this:
Run CMD.exe as Admin <- IMPORTANT Then enter following commands:
Code:
taskkill /im explorer.exe /f
This will kill explorer.exe process - don't be surprised It's needed, because by default it's ran by "currently logged in user" and it has to be run as Administrator in order to view the mounted system drive. Administrator account is not the same as an account with administrative privileges.
Code:
Code:
mountvol X: /s
This will mount the system partition that usually consists of uefi related files. X: is the letter of the drive - you can use whatever letter you want, but it has to be free.
Then type:
Code:
explorer
This will run explorer as Administrator and will allow you to browse the mounted system partition.
The above may not work for all devices, as some handle UEFI differently.
Part 2 - Run Explorer as Admin
Run CMD.exe as Admin <- IMPORTANT and enter following commands:
Code:
taskkill /im explorer.exe /f
This will kill explorer.exe process - don't be surprised It's needed, because by default it's ran by "currently logged in user" and it has to be run as Administrator in order to view the mounted system drive. Administrator account is not the same as an account with administrative privileges.
Then type:
Code:
explorer
This will run explorer as Administrator and will allow you to browse the mounted system partition.
Part 3 - Roll You Own UEFI Install
Let's start by downloading the needed files. Here is a customized UEFI boot for 32 & 64 bit machines. https://www.androidfilehost.com/?w=files&flid=143191
**NOTE: If you came from our nougat builds to our Bliss-x86 8.x builds, you will have to edit the grub.cfga bit. Please see below **
If you are using Bliss-x86 8.x/10.x, please use the grub entry below as a guide:
Code:
menuentry 'Bliss-x86' --class android {
search --file --no-floppy --set=root /AndroidOS/system.sfs
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive quiet DATA=
initrd /AndroidOS/initrd.img
}
(EXT3/EXT4 installs) (NOTE: Due to a bug on ext3/ext4 installs, please use the grub setup below)
Code:
menuentry 'Bliss-x86' --class android {
search --file --no-floppy --set=root /AndroidOS/system.sfs
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive quiet DATA=
initrd /AndroidOS/initrd.img
}
Now that we have the partition mounted, we can copy that BOOT dir to your UEFI partition using Explorer as admin or using the New Task dialog from Task Manager. (look up for a refresher on both of those) Once it is copied, go back to the admin CMD prompt and type:
Code:
mountvol X: /D
or if you used Z:, type:
Code:
mountvol Z: /D
This will dismount the UEFI/ESP volume for safe reboot. we then suggest you use EasyUEFI here to create the UEFI boot entry. Open the app, and create a new entry. Select your UEFI partition, and in the File Path, click Browse and use the file manager window to browse to your BOOT/grub/grubx64.efi file. Click OK, and then choose the new grub entry and move it to the top. Make sure secure boot is turned off or else it likely will just boot back to Windows.
Part 4 - The Manual Blissification of Your PC
To do a manual "Wubi like" install of Bliss-x86 after you install the UEFI entry, you will need to open the Bliss-x86 .iso/img with 7zip, and then drag all the .img & .sfs files to C:/android-x86 or whatever your target drive is (make sure your grub entries match where you are putting these). Then create your data.img, we suggest using a tool like one from XDA called RMXtools (use ver 1.7) to create it. Check the tool's thread for how to use it, but when you figure it out, you will want to create your data.img inside that android-x86 folder.
You can now reboot, if you have installed the custom UEFI entry right and selected it using EasyUEFI, you should boot right to the Android-x86 grub theme. There you can use up and down to select, and return to boot that entry. You can also hit e to edit the selected entry. You will want to pay attention to which entry you select, since there will be one for Bliss-x86(32bit) and one or Bliss-x86_64(64bit).
Install Bliss-x86 using a VM (virtualbox)
This method does require some beefy PC specs, so it might not work for all. (Info provided by Chih-Wei Huang, from Android-x86 Project)
We could fill up an entire section on this part alone, so here's a couple videos to help you figure things out.
If things still aren't working right for you, chances are it's hardware related.
( check cat /proc/cpuinfo )
USB based install of Bliss-x86 8.0/10.x (32bit or 64bit)
Part 1 - Gather Your Tools
** Please note that our Bliss-x86 builds do not currently support this install method for all machines **
For this method, we are going to want to download Rufus, and the 32bit .iso or 64bit .iso/.img file of Bliss-x86. And you are going to need a decent speed USB drive (4gb or larger is recommended). Once we have those tools, we can move on.
Part 2 - Flashing Bliss-x86 to the USB drive
Plug in your USB drive, and load up Rufus. Once loaded, click on the icon next to the ISO Image dropdown menu. Now browse to where you have your Bliss-x86 (32bit) .ISO, or your Bliss-x86_64 (64bit) .ISO/.IMG file. Once chosen, the dropdown should switch to the correct image type, and fill the rest in for you. Once you are ready, click Start.
Part 3 - Testing Bliss on your system !!IMPORTANT STEP!!
### If you as a user do not test the OS first to make sure it is compatible with your device, please do not expect us to support you if you happen to just install it and something goes wrong. You continued to scroll past all of our warnings about reading and understanding what you are doing, so it's all on you###
From here, you can choose to reboot your machine, and make sure it can boot to USB from BIOS. Once that is set, reboot and choose the USB. If everything went smoothly on the install process, you should see a Grub boot screen. Select the "Live CD" option, and if your machine is compatible, you should then see a little bit of text, and then the Bliss bootanimation. This will go on for a few minutes, but should eventually boot to Bliss-x86. If the system never boots to Bliss-x86, this is a good sign that your system might not be able to run it. If it does boot, and you would like to install it, continue to the next step.
Part 3.5 - Using Bliss-x86 from your USB drive
If you so choose to use Bliss from the USB drive, your data will be saved in a temporary state unless you create a data.img to store the data. We can create a data.img in the root dir of the USB drive (make sure you have a minimum 4-5gb free). We suggest using a tool like one from XDA called RMXtools to create it (we suggest you use version 1.7). Check the tool's thread for how to use it, but when you figure it out, you will want to create your data.img inside the root directory of your USB drive, with all the other .img files. From there, just boot into live mode, setup your system the way you want. and the data should be persistant across a reboot now.
Part 4 - Setting up and Installing Bliss-x86 on your HDD/SSD/SDcard
***Team Bliss is not responsible for any damage, tears, lost time, broken marriages, hallucinations or anything of the sort if things go south with this install. Don't even think about blaming us. You automatically agree to these terms upon continuing the install.***
This is where things start to get a little tricky, especially with how PC's vary. Make sure you have a backup plan in case something goes wrong.
Start off by opening your favorite Partition Management software, and create a new partition, making it the size you want (suggested minimum is 8gb.). Just format it to NTFS for now, because it will be changed by the installer later anyways. Remember what drive you setup here, it's important. For Windows machines, it will typically be Sda4 or Sda5. Also create another 300mb FAT32 partition for Grub to install to. (This part might require a third-party partition manager, Windows disk manager won't let it be that small)
Boot up the Bliss-x86 USB, and select the Installation option from Grub. (second one down)
The installer will load, and you will have an option to choose which partition you created earlier. Pick it, and select Ext4. ***You don't want to get this step wrong. If you are unsure, please boot back to Windows, and write it down this time. It will be Sd** typically.***
When it asks if you want to install System as R/W, select YES.
When it asks if you want to install Grub, select Grub for Legacy BIOS boot type, Grub2 for UEFI boot type, or neither if you are already running a Linux system.
If you chose to install a Grub option, the installer will allow you to choose. Make sure you select the 300mb partition you setup earlier for Grub.
The process will install and create the data directory/img, so go get a drink or something and come back to it.
When finished, the installer will then ask if you want to run Android-x86, you can just reboot here, and make sure you remove the USB drive.
If we have followed all the directions correctly, you should be presented with a Grub boot menu. You can choose your bliss_android_x86 option (or android-x86), and it will boot into Bliss-x86. If you feel the need to customize your grub boot entry, please search the web first. We use the same grub setup that Android-x86 project uses. so their forums will contain just about all the info you will need.
Common command line options (Grub commands)
With Bliss OS on the PC, we tend to use quite a few command line options to get things working right. we've gathered a few of them here to explain them a little bit.
sleep=1
This will enable the system.prop value for sleep.earlysuspend=1, and on some machines, it enables the proper sleep state.
acpi_sleep=s3_bios,s3_mode
Sometimes needed for older machines to enter sleep mode properly
SETUPWIZARD=0
This command will skip SetupWizard on boot. (Only needs to be run once)
AUTO_LOAD=old
This will load android-x86 variants using the old modprobe method to init devices. We sometimes use this to debug devices not starting.
DEBUG=1 & DEBUG=2
These enable verbose console debugging, giving another command shell after loading kernel modules, but before Android init
vga=xxx & video=
These are the common video modes that you can boot into if it doesn't pick the best choice automagically
You can also use video= as resolution parameters: video=LVDS-1:d video=1366x800 , learn more from our own
Henri Koivuneva: https://groups.google.com/forum/#!msg/android-x86/jSF3RnADnqA/1sfYdGV_AQAJ
nomodeset
This will load mostly everything in software rendering/support mode. No hardware acceleration. Good for debugging.
HWACCELL=1
This will disable graphics hardware acceleration, enabling rendering through Swiftshader. (Must use this if running headless)
buildvariant=eng, user, userdebug
This is the command line perimeter to run the current build as eng, userdebug, or user
DPI=xxx
This will manually set the DPI on init. Use this if things are too big/small for you.
As an example, here are a few of the boot options I use in testing:
Code:
menuentry 'Bliss-x86 Test-Oreo' --class bliss {
search --file --no-floppy --set=root /AndroidOS/android.boot
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng quiet sleep.earlysuspend=2 DATA=
initrd /AndroidOS/initrd.img
}
menuentry 'Bliss-x86 Test-Oreo AUTO_LOAD=old' --class bliss {
search --file --no-floppy --set=root /AndroidOS/android.boot
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng quiet DATA= AUTO_LOAD=old
initrd /AndroidOS/initrd.img
}
menuentry 'Bliss-x86 Test-Oreo - SETUP_WIZARD=0' --class bliss {
search --file --no-floppy --set=root /AndroidOS/android.boot
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA=
initrd /AndroidOS/initrd.img
}
menuentry 'Bliss-x86 Test-Oreo - debug=1' --class bliss {
search --file --no-floppy --set=root /AndroidOS/android.boot
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=1
initrd /AndroidOS/initrd.img
}
menuentry 'Bliss-x86 Test-Oreo - debug=2' --class bliss {
search --file --no-floppy --set=root /AndroidOS/android.boot
linux /AndroidOS/kernel root=/dev/ram0 SRC=/AndroidOS androidboot.selinux=permissive buildvariant=eng SETUPWIZARD=0 quiet DATA= DEBUG=2
initrd /AndroidOS/initrd.img
}
Downloads:
!!!!BEFORE YOU SCROLL DOWN!!!
We offer a few different types of downloads for Bliss-x86. Stable, EDU, & Bleeding Edge builds. Below is a short run-down of what that means to you.
Stable Builds - kernel-4.9.x/etc
These builds use the most stable branches we have for the kernel & OS. This is usually right in line with what the Android-x86 project has unless there are some incompatibilities. These are updated regularly, but least often.
EDU Builds (discontinued for now) - Kernel-4.4.x/kernel-4.9.x/4.11.x
These builds are a rootless version of Bliss, packaged with rootless Substratum and a ton of features to still allow customization without compromising security. Perfect for not only the classroom, but the corporate environment as well. These builds are released with both kernel-4.4 & kernel-4.10/4.11 for a broad compatibility range. This branch is still a work in progress
Bleeding Edge Builds - kernel-4.9.x/Kernel-4.10.x/4.11.x/4.12.x/4.14x/4.15x/4.16x/4.17x
These builds will usually contain one of the newer kernels we are working on, and these builds could be almost weekly, as this will be used as our testing branch. This also means, these builds will see features that may or may not be included in the stable releases. Eventually, once this branch is stable enough, it is what gets pushed to the Stable branch for release.
Nightlies - kernel-4.9.x/4.15x/4.16x/4.17x
These are where our most recent changes can be seen. We use Jenkins for tasking these builds, so some may have issues, some may not. !!These builds may break things!! So please tread carefully when testing the nigltlies.
What do all the extra things in the filenames mean?
Our builds include a ton of changes between each build, so to make things easier for all of you, we try to add some extra info to the filenames.
Typical build name: Bliss-v10.0-Beta-android_x86_64-OFFICIAL-20180312-1933_k4.15-sb-ga-jwd_m17.3.6_surface-book.iso
So, we will break this down into parts for you. We always list it by Kernel ver, then Mesa ver, followed by abreviations for the changes in that build or trailed with a target device label.
Kernel ver: k4.15-sb-ga-jwd
This represents the kernel branch name used in this build. But what do the acronyms mean? Well, when I add any number of commits from a given remote, I usually use a three letter acronym for the remote. For example, jwd stands for this remote: https://github.com/jwrdegoede/linux-sunxi Or when I use ga, it is short for GalliumOS: https://github.com/GalliumOS/linux
Mesa ver: 17.3.6
This represents also, the branch name for mesa
Trailing notes (not always)
These are usually the last word or two of the filename. The represent any device specific commits that have been added to the builds.
!!Please Note!!
Just because you see a target device in the filename, doesn't mean that build won't work for other devices. It only means that that build contains specific commits or firmware files for that target device. In the case of our Surface builds, they will ALL work on other devices. The drivers and firmware is still there for those to work.
Bliss OS for PC Downloads - Stable, EDU, Nightlies & Bleeding Edge Builds
Current Releases: https://downloads.blissroms.com/BlissOS/
Archived Releases: https://sourceforge.net/projects/blissos-x86/files/Official
https://www.androidfilehost.com/?w=files&flid=136638
n7x / mm6.0 - Bliss-x86 - 6.4-7.x - NO LONGER SUPPORTED
**Development on our Bliss-6.4 through 7.x builds have stopped in favor for oreo builds. Please do not ask for any further development on our marshmallow builds. You will be answered with sarcasm**
Archived Released: https://www.androidfilehost.com/?w=files&flid=127970
LATEST UPDATE:
https://forum.xda-developers.com/showpost.php?p=77160012&postcount=2209
!!New Bliss-x86 v10.1 PC Beta - 07/16/2018
We have a somewhat transitional update for you all today. I rebased BlissOS off our GSI project (Bliss-Bass), and the outcome is actually pretty stable. Some old issues have returned, and some have been resolved. Most of the details can be found below in the Updates/Additions or the Changelog. Build might take a while to upload, so keep checking back.
Have FUN!!
Bliss-v10.1-Beta-android_x86_64-OFFICIAL-20180716-1838_k4.15.18-ipts_18.1.0-devel_w14_dev-kernel.org.iso - This contains firmware for all current devices included in kernel.org. - THIS BUILD INCLUDES OpenGapps
Updates / Additions:
Kernel 4.15.18 - reworked for all devices, and added IPTS commits *Surface devices will require manual firmware update*
Moved to old way of packaging the system image. (for root to work, you must extract the system.img file from within the system.sfs, then delete the system.sfs file)
Rooted with Superuser. Access Superuser settings from Settings>Users (R/W works if you extract system.img, read above)
Substratum Service mode enabled (now fully working, but reboot required after you build/enable a theme. select from Settings>Display>Advanced>Themes)
A few fixes and updates for Bluetooth
Fixes for some devices that didn't boot right
Using Android-x86's newest updates to bootable/newinstaller (this comes with a new UEFI grub menu)
Maybe more... I've been busy
Bugs / Issues:
Android Service Has Stopped dialog is back. It does not harm anything though.
Bluetooth issues still exist on some devices
you will get Play Store and process crashes until WiFi is connected. Just dismiss these for now. Once connected to WiFi, things should work properly. **ONLY ON OPENGAPPS BUILDS**
Sound or keyboard might not work, try to boot using the secondary modprobe option
Expect more. It's only a beta release. Report your issues, but make sure you SEARCH the thread first to make sure it hasn't been answered. And post logs too (I know, WTF are logs anyways??)
As always, check the Bliss download site for the newest builds. The rest are all on AFH as a backup archive. Hope you all enjoy this one
https://downloads.blissroms.com/BlissOS/bleeding_edge/
Archived Instructions for old versions of Bliss OS for PC
**These instructions are based on the Android-x86 project's installation guide. We have not changed the installer, so all actions still apply. Also thanks to @bg260 for his contributions, this guide was adapted partially from his work**
*** Team Bliss will not accept any responsibility for users who have not read or understand the instructions, or any damage done to user machines due to lack of understanding all risks involved. You accept all responsibility by continuing beyond this point. ***
*** Any questions, install issues, bug reports, etc will be delightfully ignored unless accompanied with a log, device info, build info, install method, and any other information required to diagnose your issue as NOT user error ***
For Bliss-x86 6.4/7.x USB based installs (32bit or 64bit)
Part 1 - Gather Your Tools
** Please note that our Bliss-x86 n7.x builds do not currently support this install method for all machines **
For this method, we are going to want to download Rufus, and the 32bit .iso or 64bit .iso/.img file of Bliss-x86. And you are going to need a decent speed USB drive (4gb or larger is recommended). Once we have those tools, we can move on.
Part 2 - Flashing Bliss-x86 to the USB drive
Plug in your USB drive, and load up Rufus. Once loaded, click on the icon next to the ISO Image dropdown menu. Now browse to where you have your Bliss-x86 (32bit) .ISO, or your Bliss-x86_64 (64bit) .ISO/.IMG file. Once chosen, the dropdown should switch to the correct image type, and fill the rest in for you. Once you are ready, click Start.
Part 3 - Testing Bliss on your system
From here, you can choose to reboot your machine, and make sure it can boot to USB from BIOS. Once that is set, reboot and choose the USB. If everything went smoothly on the install process, you should see a Grub boot screen. Select the "Live CD" option, and if your machine is compatible, you should then see a little bit of text, and then the Bliss mm6.0 bootanimation. This will go on for a few minutes, but should eventually boot to Bliss-x86. If the system never boots to Bliss-x86, this is a good sign that your system might not be able to run it. If it does boot, and you would like to install it, continue to the next step.
Part 3.5 - Using Bliss-x86 from your USB drive
If you so choose to use Bliss from the USB drive, your data will be saved in a temporary state unless you create a data.img to store the data. We can create a data.img in the root dir of the USB drive (make sure you have a minimum 4-5gb free). We suggest using a tool like one from XDA called RMXtools to create it (we suggest you use version 1.7). Check the tool's thread for how to use it, but when you figure it out, you will want to create your data.img inside the root directory of your USB drive, with all the other .img files. From there, just boot into live mode, setup your system the way you want. and the data should be persistant across a reboot now.
Part 4 - Setting up and Installing Bliss-x86 on your HDD/SSD/SDcard
***Team Bliss is not responsible for any damage, tears, lost time, broken marriages, hallucinations or anything of the sort if things go south with this install. Don't even think about blaming us. You automatically agree to these terms upon continuing the install.***
This is where things start to get a little tricky, especially with how PC's vary. Make sure you have a backup plan in case something goes wrong.
Start off by opening your favorite Partition Management software, and create a new partition, making it the size you want (suggested minimum is 8gb.). Just format it to NTFS for now, because it will be changed by the installer later anyways. Remember what drive you setup here, it's important. For Windows machines, it will typically be Sda4 or Sda5. Also create another 300mb FAT32 partition for Grub to install to. (This part might require a third-party partition manager, Windows disk manager won't let it be that small)
Boot up the Bliss-x86 USB, and select the Installation option from Grub. (second one down)
The installer will load, and you will have an option to choose which partition you created earlier. Pick it, and select Ext4. ***You don't want to get this step wrong. If you are unsure, please boot back to Windows, and write it down this time. It will be Sd** typically.***
When it asks if you want to install System as R/W, select YES.
When it asks if you want to install Grub, select Grub for Legacy BIOS boot type, Grub2 for UEFI boot type, or neither if you are already running a Linux system.
If you chose to install a Grub option, the installer will allow you to choose. Make sure you select the 300mb partition you setup earlier for Grub.
The process will install and create the data directory/img, so go get a drink or something and come back to it.
When finished, the installer will then ask if you want to run Android-x86, you can just reboot here, and make sure you remove the USB drive.
If we have followed all the directions correctly, you should be presented with a Grub boot menu. You can choose your bliss_android_x86 option (or android-x86), and it will boot into Bliss-x86. If you feel the need to customize your grub boot entry, please search the web first. We use the same grub setup that Android-x86 project uses. so their forums will contain just about all the info you will need.
Easy Install For Bliss-x86 6.4/7.x MBR (32bit or 64bit)
** This method is the easiest install method for MBR/GPT boot setups, but it does require Windows to install. **
For the overall instructions on using this method, please refer to the tools original thread: https://forum.xda-developers.com/showthread.php?t=2142563
I have taken some time to update the tool for easy install on UEFI/ESP machines. The builds I modified can be found here: https://www.androidfilehost.com/?w=files&flid=185778
Part 1 - Using the Installer
The installer has been modified, and will read and install any 32bit or 64bit Bliss-x86 build onto a GPT/MBR type setup. Just run the installer, pick the Bliss-x86 .iso file, and select your size data.img. If you require a size data.img larger than what is available, please use the RMXtools v1.7 mentioned in this post elsewhere.
Easy Install For Bliss-x86 6.4/7.x UEFI/ESP (32bit or 64bit)
** This method might be the easiest currently, but there's a trick to get proper root for now. **
For the overall instructions on using this method, please refer to the tools original thread: https://forum.xda-developers.com/android/software/winapp-android-x86-installer-uefi-t3222483
I have taken some time to update the tool for easy install on UEFI/ESP machines. The builds I produce can be found here:
https://www.androidfilehost.com/?w=files&flid=140019
And the source for those builds can be found here: https://github.com/BlissRoms-x86/Androidx86-Installer-for-Windows
This tool should work on RemixOS as well, but I have not tested it yet (been too busy on this project)
Part 1 - Using the Installer
The installer has been updated, and it will accept the .iso files just fine now, as well as allow proper root with one simple trick. If you do not want to use root (which is needed for Substratum to work), then just install as normal.
If you do want root, go through the directions like normal, and after install is finished, browse to the AndroidOS directory it created and delete the system.sfs file.
Part 2- Switching the UEFI/EFS boot entry
Open the EasyUEFI tool mentioned above, then switch the UEFI/EFI entry it created to boot first. Close and reboot.
Custom Install For Bliss-x86 6.4/7.x UEFI/ESP (32bit or 64bit)
***Again, Team Bliss is not responsible for any damage, tears, lost time, alien abductions, experimental relationships or anything else if things go south with this install. Don't even think about blaming us. You automatically agree to these terms upon continuing the install.***
Part 1 - Mounting Your UEFI/ESP Partition
You will want to make sure you can view hidden and system files in Explorer options (if you need to , google it), Once you do that, hit the start menu, and type in CMD, and then right click, and open as administrator. It should look like the window image attached to this post.
Once that is open, type in:
Code:
mountvol X: /S
Then check to see if it is mounted already
Start Task Manager; a) CTRL+ALT+DEL -> Task Manager b) CTRL+Shift+ESC c) Right click the taskbar and select Task manager.
Click "File" tab -> "Run new task" -> "Browse" -> "This computer" -> SYSTEM (X or type in "x:" in the filepath bar"
If you cannot access X:, then that could mean one of three things. 1) You have an ESP setup, and just need to scroll down to the ESP System Partition setups section, or 2) You have a legacy MBR setup and just don't know it. or 3) Your setup falls within the other category. Check below for some insight, or the second post for more links to help you figure things out.
ESP System Partition setups
Windows 10 has EFI partition sometimes already mounted under Z: letter, but it's hidden.
A very quick and easy way to access ESP (EFI System Partition) in Windows 10: (no command line use needed!)
Start Task Manager; a) CTRL+ALT+DEL -> Task Manager b) CTRL+Shift+ESC c) Right click the taskbar and select Task manager.
Click "File" tab -> "Run new task" -> "Browse" -> "This computer" -> SYSTEM (Z or type in "z:" in the filepath bar"
Now go to boot/grub/grub.cfg and edit it accordingly with Notepad++ or other editor
Save the file and your're ready to go
If this still doesn't work - try this:
Run CMD.exe as Admin <- IMPORTANT Then enter following commands:
Code:
taskkill /im explorer.exe /f
This will kill explorer.exe process - don't be surprised It's needed, because by default it's ran by "currently logged in user" and it has to be run as Administrator in order to view the mounted system drive. Administrator account is not the same as an account with administrative privileges.
Code:
Code:
mountvol X: /s
This will mount the system partition that usually consists of uefi related files. X: is the letter of the drive - you can use whatever letter you want, but it has to be free.
Then type:
Code:
explorer
This will run explorer as Administrator and will allow you to browse the mounted system partition.
The above may not work for all devices, as some handle UEFI differently.
Part 2 - Run Explorer as Admin
Run CMD.exe as Admin <- IMPORTANT and enter following commands:
Code:
taskkill /im explorer.exe /f
This will kill explorer.exe process - don't be surprised It's needed, because by default it's ran by "currently logged in user" and it has to be run as Administrator in order to view the mounted system drive. Administrator account is not the same as an account with administrative privileges.
Then type:
Code:
explorer
This will run explorer as Administrator and will allow you to browse the mounted system partition.
Part 3 - Roll You Own UEFI Install
Let's start by downloading the needed files. Here is a customized UEFI boot for 32 & 64 bit machines. https://www.androidfilehost.com/?w=files&flid=143191
**NOTE: For our Bliss-x86 n7.x builds, you will have to editr the grub.cfg and remove the androidboot.hardware... command. I will update this post more in the future with more details **
If you are using Bliss-x86 n7.x, please use the grub entry below as a guide:
Code:
menuentry 'Bliss-x86' --class android {
search --file --no-floppy --set=root /AndroidOS/system.img
linux /AndroidOS/kernel root=/dev/ram0 androidboot.selinux=permissive quiet DATA=/AndroidOS
initrd /AndroidOS/initrd.img
}
(EXT3/EXT4 installs) (NOTE: Due to a bug on ext3/ext4 installs, please use the grub setup below)
Code:
menuentry 'Bliss-x86' --class android {
search --file --no-floppy --set=root /AndroidOS/system.img
linux /AndroidOS/kernel root=/dev/ram0 androidboot.selinux=permissive quiet DATA=
initrd /AndroidOS/initrd.img
}
Now that we have the partition mounted, we can copy that BOOT dir to your UEFI partition using Explorer as admin or using the New Task dialog from Task Manager. (look up for a refresher on both of those) Once it is coppied, go back to the admin CMD prompt and type:
Code:
mountvol X: /D
or if you used Z:, type:
Code:
mountvol Z: /D
This will dismount the UEFI/ESP volume for safe reboot. we then suggest you use EasyUEFI here to create the UEFI boot entry. Open the app, and create a new entry. Select your UEFI partition, and in the File Path, click Browse and use the file manager window to browse to your BOOT/grub/grubx64.efi file. Click OK, and then choose the new grub entry and move it to the top. Make sure secure boot is turned off or else it likely will just boot back to Windows.
Part 4 - The Manual Blissification of Your PC
To do a manual "Wubi like" install of Bliss-x86 after you install the UEFI entry, you will need to open the Bliss-x86 .iso/img with 7zip, and then open the system.sfs inside 7zip, and extract the system.img file to C:/android-x86 or whatever your target drive is. After that, extract the rest rest of the contents to the android-x86 folder. Then create your data.img, we suggest using a tool like one from XDA called RMXtools (use ver 1.7) to create it. Check the tool's thread for how to use it, but when you figure it out, you will want to create your data.img inside that android-x86 folder.
You can now reboot, if you have installed the custom UEFI entry right and selected it using EasyUEFI, you should boot right to the Android-x86 grub theme. There you can use up and down to select, and return to boot that entry. You can also hit e to edit the selected entry. You will want to pay attention to which entry you select, since there will be one for Bliss-x86(32bit) and one bor Bliss-x86_64(64bit).
Bliss-x86 6.4/7.x Custom UEFI/ESP Method Update Instructions:
To do this you will have to make some sacrifices to let this go through successfully. This will of course cause a few of your ROOT apps and tweaks that were written to system to vanish, so after we are done, you will have to reapply/reinstall those
Using the .iso/.img from the Bliss website
You need to grab the .iso/img file for the updated version of Bliss-x86, then we can upgrade manually with no issues usually, but you will have to do this from Windows (or your OS of choice). Open the Bliss-x86 .iso/img with 7zip, and then open the system.sfs inside 7zip, and extract the system.img file to C:/android-x86 or whatever your target drive is, overrighting the existing file. After that, extract the rest rest of the contents to the android-x86 folder:
initrd.img
ramdisk.img
kernel
I also replace the install.img and isolinux.sys files, but I don't think they are needed. I'm just lazy and drag it all over from the .zip
Once that is done, you can reboot
Bliss-x86 6.4 Xposed Install Instructions (32bit or 64bit):
*** There is the potential to screw up your Bliss-x86 install by installing Xposed. Do not continue if you do not know what you are doing. Team Bliss will not be held responsible.***
Part 1 - Installing Xposed APK:
Start off from your Bliss-x86 installation by heading to this thread and downloading DVDandroid's XposedInstaller. Once you have it downloaded, install the .apk file.
Part 2 - 32bit Xposed Install (scroll down for 64bit):
You need to grab this Xposed.zip while using the 32bit Bliss-x86 (Thanks to Martin over on the Android-x86 Google Groups for this). Once you have the download, use SolidExplorer or a simular file explorer to extract the contents to your data partition. We recommend extracting it to sdcard/xposed . Now we need to open a terminal app, and type:
Code:
su
Grand it permissions, and then type:
Code:
cd sdcard/xposed
Then type:
Code:
sh flash-script.sh && reboot
If everything goes smoothly, your PC should finish the install, and reboot. Choose your version of Bliss-x86 upon reboot, and wait. It might take a little longer to boot up this time. **Please note that this does not work on all machines. There are some that it will not work for. If you are using one, you will need to extract the system.img file from the iso back to the system partition or directory you have Bliss-x86 installed on**
Part 2 - 64bit Xposed Install:
You need to grab this Xposed64.zip while using the 64bit Bliss-x86 (This one comes from HypoTurtle over on XDA). Once you have the download, use SolidExplorer or a simular file explorer to extract the contents to your data partition. We recommend extracting it to sdcard/xposed . Now we need to open a terminal app, and type:
Code:
su
Grand it permissions, and then type:
Code:
cd sdcard/xposed64
Then type:
Code:
sh flash-script.sh && reboot
If everything goes smoothly, your PC should finish the install, and reboot. Choose your version of Bliss-x86 upon reboot, and wait. It might take a little longer to boot up this time. **Please note that this does not work on all machines. There are some that it will not work for. If you are using one, you will need to extract the system.img file from the iso back to the system partition or directory you have Bliss-x86 installed on**
Adding ARISE Sound Systems to Bliss-x86 n7.1.1 (64bit only)
**NOTE: This might not work as intended on some 32bit installs, and it also will break standard AOSP audio visualization. You have been warned!! **
(Basic Tutorial)
To start off, I would like to state that this can mess things up if you don't know what you're doing, or if you have already added stuff to your system.img, or if you copy/delete the wrong files, etc. You get the point. Team Bliss is not responsible for your mistakes. If your having second thoughts, please ask first and provide as much detail as possible. This isn't a Twitter post.
Now that we're through the ugly part, let's get on to making Bliss-x86 sound better First you will need to grab the files. [URL]https://www.androidfilehost.com/?fid=24651430732237629
All the work done on this is due to A.R.I.S.E. Sound Systems™, so make sure you thank them properly if you like what you hear
PART 1
Once you download the .Zip, use a root file manager, like SolidExplorer to extract it to a folder on your SD. Open that folder up and navigate to the numbers directory. Select all the contents of that directory and copy it to the /root/system/ folder. Overight and files and merge any folders needed.
View attachment 4023464
PART 2
Now we have to navigate to the priv-app folder in /root/system/, and create a new folder called ViPER4Arise . Then navigate back to the root of the extracted zip, and go to /customize/app. Copy the two .apk's there, along with the x86 folder to the new directory you created in /root/system/ then install each one and reboot.
View attachment 4023478
PART 3
Once reboot is complete, load up the ViPER4Arise app, and it will ask to install the driver. Grant it su permissions and any other permissions it might ask. Install might take a few, but it will complete if you let it. Once it completes, it will tell you to reboot. Do it. And when you come back to Bliss, it will have some nice sound controls
View attachment 4023486
Enjoy!!
Setting Taskbar v3.3+ as default navbar in Bliss-x86 n7.1.x
!!WARNING!! This must be done after first boot and setup is complete. Setup wizard uses default navbar.
Follow this link to read the walkthrough: https://forum.xda-developers.com/showpost.php?p=71757350&postcount=290
https://drive.google.com/open?id=0B2hjuvxuncgYQ3Z2dUE1YUo3TX not found
Can I use D:\android-x86 ?
Dunard said:
https://drive.google.com/open?id=0B2hjuvxuncgYQ3Z2dUE1YUo3TX not found
Can I use D:\android-x86 ?
Click to expand...
Click to collapse
My bad... I will move that to my AFH as well. And yes, you can use whatever folder/drive combo you want. Just make sure you edit the grub.cfg to match the location, or keep the folder name the same as I describe, and change the drive. It will search the mounted drives for the first folder matching that name
EDIT: Updated the link
@social-design-concepts would this work on baytrail android tablets?
Wow looks great. Thanks for all the hard work. @electrikjesus et al.
---------- Post added at 06:48 AM ---------- Previous post was at 06:15 AM ----------
Madlad003 said:
would this work on baytrail android tablets?
Click to expand...
Click to collapse
There's only one way to find out. My guess is you'll have a few minor incompatibilities.
Thank you very much @electrikjesus . All working fine. Amazing rom.
UPDATE
I have pushed an update to the Android-x86 UEFI installer, it should work for root now with one simple trick. I updated the second post accordingly as well. Thanks peeps for all the support on this project so far
Second Update:
There is now also a 32bit n7.1.1 build in the download folder. Only known difference so far is root is not working right. I'll fix that here soon.
UPDATES:
Bliss-x86 32bit - I have fix the issue with how supersu is integrated on the 32bit builds, so a new build can be found in the Bliss-x86 n7.1.x folder
I also had a couple people asking questions about how to use Taskbar and Substratum. So I went and made a couple short videos on that too.
Taskbar:
Substratum:
UPDATE - 01.11.17 - OS is now in line with 7.1.1r12, all the Surface patches have been correctly applied. So support for all M$ Surface product up to Surface Book should be there. 32-bit version didn't have any touch issues on my end. 64-bit still did eventually though. Could be my hardware I'm testing with though too. (I'll eventually be able to afford something new)
Builds are available in the Bliss-x86 n7.1x folder for my AFH. ENJOY!!
Xposed instructions are a bit wrong - despite the screenshots from groups
As you are replacing critical system files, you need to run the script in debug mode: DEBUG=1 rather than from a running system.
Feel free to verify but pretty sure on that.
Getting reboots as soon as android text on black screen appears, checked debug option and it got stuck at this point
It happens after I update apps or install new apps
HypoTurtle said:
Xposed instructions are a bit wrong - despite the screenshots from groups
As you are replacing critical system files, you need to run the script in debug mode: DEBUG=1 rather than from a running system.
Feel free to verify but pretty sure on that.
Click to expand...
Click to collapse
I use the local terminal accessed from Dev Options. My instructions work fine from there once I request su
muzab a said:
Getting reboots as soon as android text on black screen appears, checked debug option and it got stuck at this point
Click to expand...
Click to collapse
How odd. It says it can't access the local time... Never seen that before. Try to change persist.rtc_local_time in build.prop to persist.rtc_local_time = 0
electrikjesus said:
I use the local terminal accessed from Dev Options. My instructions work fine from there once I request su
Click to expand...
Click to collapse
You sure? Xposed installed and running correctly. There are some system libs and bins that I'm pretty sure can't be replaced while in use.
HypoTurtle said:
You sure? Xposed installed and running correctly. There are some system libs and bins that I'm pretty sure can't be replaced while in use.
Click to expand...
Click to collapse
I've done it my way since I put them up there. Just make sure you're superuser and reboot afterwards. If it gives you trouble, then do it your way. If they both work, I'll add your method to the instructions as well.
If I had to guess, it is because of how we reworked how SuperSU is built into Bliss-x86. Android-x86 Project uses a variation of CM's AppOps/Privacy Manager, and that was tied to the root terminal like you describe, as well as the filesystem, buildtype, etc. You likely had to access it using DEBUG=1 grub boot option. With Bliss-x86 (and remixOS I think) just using the root terminal with proper su access should do the trick.
@HypoTurtleI installed xposed as @electrikjesus mentioned. All fine, no problem to install. After reboot I could install youtube adaway. I tried it in Remix os for pc as well. It worked.

[Recovery][TWRP-Based]TTYRP Recovery

Hi all,
I've created a new recovery based on TWRP:
it is called TTYRP, and it has only a terminal interface.
Basically you can do everything you normally do with TWRP, but with commands written in the terminal interface, so, there isn't any GUI in TTYRP,
so, no buttons no pages, and no themes. In fact when you boot TTYRP, you see the TWRP splash screen (with TTYRP images and text) and then,
you will see a terminal interface, where the only present button is a very small button for showing/hiding the keyboard, useful if you want to see a longer log.
I've also created a command: it is called "ttyrp_help". This command, launched with --command, where 'command' is the command name e.g. ls, rm, cp..., will display a short description of that command, took from the man page of the command or written by me, and it is useful for beginners who don't know what is a certain command, and/or what is it used for.
Here is a quick example of ttyrp_help command
~ # ttyrp_help --chmod
chmod changes the file mode bits of each given file according to mode
which can be either a symbolic representation of changes to make
or an octal number representing the bit pattern for the new mode bits.
~ #
Also, if you want to see the list of all commands supported by ttyrp_help, use --list option
This recovery is also very useful for people who want to learn more about linux and his commands, and to learn how to survive without the GUI
SOURCES:
TTYRP sources are obviously open, and you can find them here: https://github.com/DeadSquirrel01/ttyrp-recovery branch android-7.1
Porting method is the same as twrp, just delete twrp's bootable/recovery dir and put ttyrp sources in bootable/recovery, or simply put ttyrp sources in something like bootable/recovery-ttyrp and add in your BoardConfig.mk: RECOVERY_VARIANT := ttyrp
Also, feel free to port it to your device and publish it
Special Thanks:
All the TWRP team, for made the fantastic TWRP and for sources (as I said TTYRP recovery is based on TWRP)
CHANGELOG:
03/15/2017: TWRP to TTYRP
03/17/2017: clean up code from GUI functions useless for ttyrp
Replaced twrp splash image (logo+teamwin logo text) with ttyrp ones
Add ttyrp_help command which displays short ttyrp commands' descriptions
03/18/2017: new android-6.0 and android-7.0 branches: ttyrp is now compilable on android 6.0 and android 7.0 sources, too
03/18/2017: new 'copylog' command which copies recovery log to a desidered destination. It is like 'Copy Log' button in twrp with the difference
that you can copy it to your preferred destination, and not only to /sdcard
Reserved
That is cool
Sent from my ONE E1003 using Tapatalk

[Tutorial] Custom boot logo on 8227L head units

Greetings,
I'm new to these forums, but have been into the Android development/customization scene since the original Motorola Droid. I recently purchased one of the (in)famous Chinese 8227L head units and have started doing some things to it. I was surprised to find that there are a lot more people out there with questions than answers when it comes to these things. So I figured I'd introduce myself with a quick tutorial, a small utility release for now. I have work in progress on a ROM release for these things. There are quite a few issues to get past as well as different boards to account for, so stay tuned for that sometime in the coming weeks. For now, let's get started with customizing the boot screen.
One of the simplest, yet most satisfying modifications one can do to any Android device is changing logo image that is displayed when the unit boots. For units like ours, running MediaTek hardware there are a couple of extra steps involved, but the process is still very simple. I was able to find a few different utilities that could be downloaded online to do this, but none of them seemed to work for these head units. I suspect our units use a slightly different header than the MediaTek phones those utilities are designed for, but that is a technical issue beyond the scope of this tutorial.
Disclaimer: These steps have been tested repeatedly on my device, and it's my assumption that they will work on any head unit based on the ac8227l, but I have obviously not tested every single one of them. There is always an inherent risk when you modify the software on any device that you own. This risk is your own, and I am not responsible for any damage you do to your device by following this tutorial!
Your unit does not need to be rooted to do this mod, but you will need to have the bootloader unlocked.
Pre-requisites:
logo.bin file from your ROM backup (You DO have a backup, don't you?)
Ability to read and follow directions
Access to a Linux command line OR the ability to run python applications on your system
SP Flash Tool or one of its equivalents, or a custom recovery installed, such as TWRP.
The boot logo is contained in the logo.bin file from your ROM. More accurately, the logo.bin file IS the boot logo for your ROM, with a 512 byte header attached to it. We need to separate the two in order to change the image that gets displayed.
This can be done very simply from the linux command line via the following command:
Code:
dd if=logo.bin of=logo.bmp skip=1
This command simply reads in the logo.bin file and writes it back out after skipping the first 512 bytes. dd has an optional argument bs= which stands for block size. It defaults to 512 bytes. So the skip=1 is simply
telling dd to skip the first 512 bytes when it writes the file back out. The result is a 1024x600 pixel bitmap image. However, we're going to need that header in a later step, so write it out to its own file using:
Code:
dd if=logo.bin of=header.bin count=1
This command simply writes the first block (remember block size is 512 bytes by default) out to a file and then stops, so we have our 512 byte header saved for later.
Now, you can either edit the logo.bmp file or replace it with your own image file. However you do it, just ensure that you end up with a 1024x600 pixel bitmap image in 8-bit RGB color. The following steps assume we have generated such an image in the same directory we were just working in, and named it newlogo.bmp. To join the header file to your new image, use the following command:
Code:
cat header.bin newlogo.bmp > newlogo.bin
This command concatenates (puts together) the two files back into one file. The order is important. The header needs to be at the start of the resulting file, so it must be the first argument you pass to cat! The resulting newlogo.bin is ready to be flashed to your head unit. Congratulations, enjoy your new boot screen! If you save the header.bin file, you can always use it to make more boot logos later.
Alternative method for Windows users or Linux users who would prefer to have a utility:
I have written a simple command line utility in python to do this process for you. You will need to have python installed to utilize it. It's written in python 3.8 but will work on some earlier versions, I think. You can get it from my github repository at https://github.com/threadreaper/logobin.git or from your command prompt using the PyPi repository through pip3. pip3 should be installed automatically when you install python 3. Use this command to fetch the utility:
Code:
pip3 install logobin
If you've elected to clone the git repository instead of using PyPi, you need to cd to the directory you downloaded it to (this should be the directory with the setup.py file) and install using:
Code:
pip3 install .
Whichever method you used, if everything went correctly, the "logobin" utility should now be available to you from your command line. To unpack an existing logo.bin image:
Code:
logobin -u logo.bin
And to pack an image with a header file back into a flashable bin file:
Code:
logobin -p header.bin logo.bmp (filename)
The filename argument above is optional and defaults to logo.bin if you don't select one. The utility can also be used to check a file for the presence of a valid header, using the -c switch:
Code:
logobin -c logo.bin
In this manner, you can check your stock logo.bin file to make sure it will work with this method before you start. You can also use it to check an extracted header to make sure it's correct, and you may also want to use it to verify that your logo.bin file has been packed correctly before you flash it to your phone.
I have attempted to make both the utility and this tutorial as simple to follow as possible, but if you have any questions, feel free to ask.
Excellent tutorial? I have a non rooted Enon 8227 unit and I’m having problem with it, could you be so kind to point me to a tutorial to make a rom backup please? all the stuff in my unit are blocked and I can t almost change anything.
Thank you.
Sent from my iPhone using Tapatalk Pro
Good day sir.
Could you guide me as to how to extract the logo.bin file please? I couldn't really find it.
I have a PX6 STM32 device.
Thanks!
arturojgt said:
Excellent tutorial? I have a non rooted Enon 8227 unit and I’m having problem with it, could you be so kind to point me to a tutorial to make a rom backup please? all the stuff in my unit are blocked and I can t almost change anything.
Thank you.
Sent from my iPhone using Tapatalk Pro
Click to expand...
Click to collapse
I'm planning to do a full tutorial on this too, but the short version is as follows:
Get SP Flashtool, and find a scatter file that will work for your device. That can be difficult sometimes, as there is a quite a bit of variance between units. Fortunately, to make your initial backup the only info you need in your scatter file is for the preloader, and as far as I know that is always the same. So if you don't already have a scatter file copy this:
Code:
#########################################__WwR_MTK_2.50__###################################################
#
# General Setting
#
#########################################__WwR_MTK_2.50__###################################################
- general: MTK_PLATFORM_CFG
info:
- config_version: V1.1.2
platform: MT3367
project: 8227l_demo
storage: EMMC
boot_channel: MSDC_0
block_size: 0x20000
############################################################################################################
#
# Layout Setting
#
############################################################################################################
- partition_index: SYS0
partition_name: preloader
file_name: preloader_8227l_demo.bin
is_download: true
type: SV5_BL_BIN
linear_start_addr: 0x0
physical_start_addr: 0x0
partition_size: 0x40000
region: EMMC_BOOT_1
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: BOOTLOADERS
is_upgradable: true
empty_boot_needed: false
reserve: 0x00
And save it as scatter.txt
Select this file as your scatter file in SP Flashtool, and click on the memory test tab. Uncheck all the options under memory test except for RAM test. Remove external power from the unit entirely, click start on the memory test, and then connect the 4 pin usb to your PC. It should sync up and do the memory test. Once the memory test is complete you will have the sizes of BOOT_1, BOOT_2 and EMMC_USER. Use these values with the readback option to make your backup. Use 0x0 as the start address each time, and the size value you got from the memory test. Back up BOOT_1, BOOT_2 and EMMC_USER and save them somewhere. This is the most basic backup that you can always use to go back to stock. Using tools like MTK Droid Tools and WWR MTK it is possible to split EMMC_USER backup into all of your separate partition backups.
Good luck, and keep an eye out for a more detailed walkthrough coming up soon!
kingdew11 said:
Good day sir.
Could you guide me as to how to extract the logo.bin file please? I couldn't really find it.
I have a PX6 STM32 device.
Thanks!
Click to expand...
Click to collapse
See my reply above about making a backup of your device. You get your logo.bin file from the extracted backup.
Please add your PayPal account to your xda so we can buy you some beer for the amazing work you're doing
Sent from my MI 9 using Tapatalk
zetlaw01 said:
Please add your PayPal account to your xda so we can buy you some beer for the amazing work you're doing
Sent from my MI 9 using Tapatalk
Click to expand...
Click to collapse
I don't drink beer, but you can always buy me a coffee
Thanks for information.
I want to backup with Flastool or similar program, is that possible?
and how do I root.
thank you
bicer79 said:
Thanks for information.
I want to backup with Flastool or similar program, is that possible?
and how do I root.
thank you
Click to expand...
Click to collapse
I posted instructions on backing up a unit two posts above your reply ^^. To root, find a compatible twrp image and flash it, then install magisk from twrp. I will be doing more detailed tutorials on these steps in the near future, but as I mentioned there is a crash course on SP-flashtool backup in this very thread, and the root process is pretty much the same for these units as it is for many others, assuming you find a working twrp image for your particular device, so you shouldn't have too much trouble finding a walkthrough if you need one.
threadreaper said:
Greetings,
I'm new to these forums, but have been into the Android development/customization scene since the original Motorola Droid. I recently purchased one of the (in)famous Chinese 8227L head units and have started doing some things to it. I was surprised to find that there are a lot more people out there with questions than answers when it comes to these things. So I figured I'd introduce myself with a quick tutorial, a small utility release for now. I have work in progress on a ROM release for these things. There are quite a few issues to get past as well as different boards to account for, so stay tuned for that sometime in the coming weeks. For now, let's get started with customizing the boot screen.
One of the simplest, yet most satisfying modifications one can do to any Android device is changing logo image that is displayed when the unit boots. For units like ours, running MediaTek hardware there are a couple of extra steps involved, but the process is still very simple. I was able to find a few different utilities that could be downloaded online to do this, but none of them seemed to work for these head units. I suspect our units use a slightly different header than the MediaTek phones those utilities are designed for, but that is a technical issue beyond the scope of this tutorial.
Disclaimer: These steps have been tested repeatedly on my device, and it's my assumption that they will work on any head unit based on the ac8227l, but I have obviously not tested every single one of them. There is always an inherent risk when you modify the software on any device that you own. This risk is your own, and I am not responsible for any damage you do to your device by following this tutorial!
Your unit does not need to be rooted to do this mod, but you will need to have the bootloader unlocked.
Pre-requisites:
logo.bin file from your ROM backup (You DO have a backup, don't you?)
Ability to read and follow directions
Access to a Linux command line OR the ability to run python applications on your system
SP Flash Tool or one of its equivalents, or a custom recovery installed, such as TWRP.
The boot logo is contained in the logo.bin file from your ROM. More accurately, the logo.bin file IS the boot logo for your ROM, with a 512 byte header attached to it. We need to separate the two in order to change the image that gets displayed.
This can be done very simply from the linux command line via the following command:
Code:
dd if=logo.bin of=logo.bmp skip=1
This command simply reads in the logo.bin file and writes it back out after skipping the first 512 bytes. dd has an optional argument bs= which stands for block size. It defaults to 512 bytes. So the skip=1 is simply
telling dd to skip the first 512 bytes when it writes the file back out. The result is a 1024x600 pixel bitmap image. However, we're going to need that header in a later step, so write it out to its own file using:
Code:
dd if=logo.bin of=header.bin count=1
This command simply writes the first block (remember block size is 512 bytes by default) out to a file and then stops, so we have our 512 byte header saved for later.
Now, you can either edit the logo.bmp file or replace it with your own image file. However you do it, just ensure that you end up with a 1024x600 pixel bitmap image in 8-bit RGB color. The following steps assume we have generated such an image in the same directory we were just working in, and named it newlogo.bmp. To join the header file to your new image, use the following command:
Code:
cat header.bin newlogo.bmp > newlogo.bin
This command concatenates (puts together) the two files back into one file. The order is important. The header needs to be at the start of the resulting file, so it must be the first argument you pass to cat! The resulting newlogo.bin is ready to be flashed to your head unit. Congratulations, enjoy your new boot screen! If you save the header.bin file, you can always use it to make more boot logos later.
Alternative method for Windows users or Linux users who would prefer to have a utility:
I have written a simple command line utility in python to do this process for you. You will need to have python installed to utilize it. It's written in python 3.8 but will work on some earlier versions, I think. You can get it from my github repository at or from your command prompt using the PyPi repository through pip3. pip3 should be installed automatically when you install python 3. Use this command to fetch the utility:
Code:
pip3 install logobin
If you've elected to clone the git repository instead of using PyPi, you need to cd to the directory you downloaded it to (this should be the directory with the setup.py file) and install using:
Code:
pip3 install .
Whichever method you used, if everything went correctly, the "logobin" utility should now be available to you from your command line. To unpack an existing logo.bin image:
Code:
logobin -u logo.bin
And to pack an image with a header file back into a flashable bin file:
Code:
logobin -p header.bin logo.bmp (filename)
The filename argument above is optional and defaults to logo.bin if you don't select one. The utility can also be used to check a file for the presence of a valid header, using the -c switch:
Code:
logobin -c logo.bin
In this manner, you can check your stock logo.bin file to make sure it will work with this method before you start. You can also use it to check an extracted header to make sure it's correct, and you may also want to use it to verify that your logo.bin file has been packed correctly before you flash it to your phone.
I have attempted to make both the utility and this tutorial as simple to follow as possible, but if you have any questions, feel free to ask.
Click to expand...
Click to collapse
did you build twrp from source or port it for your device?
I was able to build TWRP from source, but I haven't released it due to some rather annoying bugs I haven't had time to sort out with it just yet.
threadreaper said:
I was able to build TWRP from source, but I haven't released it due to some rather annoying bugs I haven't had time to sort out with it just yet.
Click to expand...
Click to collapse
which bugs?
I am so delighted to see someone hitting on the hot iron. Looking forward to the detailed tutorial to take backup, unlock bootloader, customize my radio.

[GUIDE] HOW TO BUILD ANDROID FROM SOURCE [2020 Edition]

[NOOB-FRIENDLY] HOW TO BUILD ANDROID FROM SOURCE CODE [2020 EDITION]
Introduction
Hi, my name is Varun, during the times I was building I faced some trouble building, and I thought it would be helpful if I put together a guide that covers every aspect of building. Many roms fundamentally differ so this is a generic guide, but when it comes to modifying device specific files you are going to have to refer to your rom developer or your device tree maintainer.
I see a lot of lead devs referring to older guides on xda, and felt like there should be a good reference thats more recent.
I have heavily depended upon Nathan Chance's Guide which can be found HERE. I feel like this may be a little intimidating for new builders hence this thread. I will slowly upload screenshots here as I find time. But for now this is what I have. You can find my guide HERE. If there are any changes to be made in this thread then it also needs to be changed on gh, so please do comment or make a pr and fix what is requested.
Table of Contents
1) Getting started
2) Prerequisites
3) Understanding the DOC
4) Preparing Linux environment
5) Getting the source
6) Getting device specific files
7) Building
GETTING STARTED
• This guide will help you understand the basics of rom building.
• You must have exprience with linux and terminal
• You must read everything at least once
• If you get stuck at any step, google is your best friend.
If you still struggle, these are places you can get help
1) This thread
2) GitHub
3) Other XDA threads
4) Telegram (Your SOC groups or Android Builders Help)
• Build only if you have time to spare, never rush through the learning stage
• Never think about skipping a step
• If you are planning to modify a ROM, always ask for permission
• If you are planning on including other peoples work in your rom always ask for permission
Prerequisites
• Your system should have at least 8GB RAM and 4 cores (Use Zram for 8gb ram devices)
• Strong internet connection. You will be downloading 50GB+ worth of files
• Ubuntu - this should be installed alongside a primary OS. NOT VM
• Minimum 250GB of free disk space (you can sync 1 ROMs and build for 3 devices at once)
• Git - Read some documentation
• Command Line - get yourself familiar, learn with CodeAcademy
Understanding This Doc
• Notes with background information will be given in italics
•
Code:
is used to represent a command that is run from terminal
PREPARING LINUX ENVIRONMENT FOR BUILDING
• Now the you have finished setting up, a special environment is required for building.
• Preparing the environment is as easy as double clicking .exe in Windows or .dmg in MacOS
thanks to developer Akhil N.
• We need to clone his scripts (installer) from his GitHub
NOTE:
A script is a file which contains multiple commands that run sequentially when executed
Code:
git clone https://github.com/akhilnarang/scripts
• This should copy the scripts to directory /home/username/scripts
• Cd into the directory called setup
Code:
cd scripts/setup
• List out directory
Code:
ls
• Find the file that corresponds to our Linux build. Since we are using Ubuntu it will be android_build_env.sh
For other Distros refer to the readme that has also been cloned
• Run the script
Code:
. android_build_env.sh
• Setup GitHub using on screen instructions
• Congratulations you set up your computer for building
• Go back the previous dir that you were originally on (/home/username)
Code:
cd
NOTE:
cd will always take you to home/username
GETTING THE SOURCE
• This is probably one of the worst steps, you have to wait a while
• GCloud users will be able to download source in 15 minutes
• Other users may have to wait longer (depends on internet connection speed)
• Make a directory for your ROM
Code:
mkdir “ROMNAME”
NOTE:
this will make folder in directory home/username/romname
• Cd in and initiate repository, this basically tells your computer where to download source files from.
The repository initiation command can be found on the GitHub page under “manifest” then scroll down to
repo initialisation and copy command
• It should look like
Code:
repo init -u git://github.com/crdroidandroid/android.git -b 10.0
HINTS
NOTE:
1) Linux users can paste into terminal using Ctrl + Shift + V
2) Linux users can copy from terminal using Ctrl + Shift + C
3) GCloud users can paste into window using Ctrl + V
4) GCloud users can copy from window simply by highlighting
5) GCloud users using ssh from terminal can just follow terminal commands
• Once repo is initialised, you can begin download using
Code:
repo sync -f --force-sync --no-clone-bundle --no-tags -j$(nproc --all)
• Let everything download
GETTING DEVICE SPECIFIC FILES
• As most of you know the kernel acts as the translator between the OS and your actual hardware
• The files mentioned above are android version specific and will only work with that android
version
• The developer for your device aka dt maintainer will have these files on their GitHub and its
usually linked at the end of the op of other rom threads in the source code section
• You have to make sure that the rom version you downloaded matches up
• If the device tree is for an older version then wait until your dev. releases the latest trees, if no
developer is working on your device then it is possible to modify the tree to work with newer
version of android but it may take some effort.
• In case your tree doesnt match with the rom version that you have downloaded, the easiest and best option is
to scrap everything and download the source version that your tree is designed for
• To scrap everything, use
Code:
rm -rf “folder containing rom"
• To modify the init command to download an older version you need to pick out the branch you
need (the branch is basically the version the newer version is added to a new branch)
• Change the init command after -b to include desired branch. For example
repo init -b ten to repo init -b seven
• To get the device specific files, we need to fork them to your GitHub.
Find the stuff (kernel vendor device tree hardware) and fork them
NOTE:
Forking basically copies them to your GitHub
• At this point we need to know if we need to modify the device tree as some ROMs don’t require
you to modify it (CrDroid)(LOS)
• Some roms require only partial modifications, this is rom specific so I wont be going too much into detail
• If modification is required follow these steps , otherwise skip to the end of this section
• After forking we need to modify the files we will do this from the browser for ease of
understanding
•There are three files that need modification and they are located your device tree
• Some tree developers may split your device tree into two parts if there is more than one phone
running the same SOC, so keep an eye out for that. (devices that have the same soc are like the op3/op3t and the op7/op7p)
• The files that we need to modify are under your "device codename" device tree, not "device SOC-common" device tree.
• For example; we need to go to "device_samsung_crownlte" tree not "device_samsung_universal9810-common"
• In here the three files that need modification are
1) Android Products.mk
2) lineage.dependencies
3) lineage_"device codename".mk (example:lineage_crownlte.mk)
• First open AndriodProducts.mk Here replace wherever you see lineage with name of ROM in lowercase only.
• Second, open lineage dependencies.mk and rename file to "romname".dependencies (ecample: aim.dependencies)
• Third, open lineage_"codename".mk and rename to "romname"_"codename".mk and replace
lineage with "romname in the code. (Remember,use lowercase)
NOTE:
If you are building an older version of android make sure you branch out the right branch for your trees
People who do not need to modify can join us here
• Now that all your files are in your GitHub, we need to download them
• There are two easy ways
1) Fast and easy Room Service
2) Slow and boring manual cloning
• Room Service
1) cd into .repo from romsource
Code:
cd .repo
2) Make directory local_manifests
Code:
mkdir local_manifests
3) Make room service file
Code:
nano roomservice.xml
(follow next bullet point on how to make roomservice.xml)
4) Return to ROM folder
Code:
cd && cd "romfolder"
• Making the roomservice.xml is as easy as copy paste.
Visit
https://github.com/vrnsoma/local_manifests/blob/lineage-17.1/roomservice.xml
and copy and paste it into a text editor and edit it then paste it into the terminal window (step 3 in above point)
Hint for Device Tree
Example: link= userabc/repositories/device_samsung/crownlte (location on github)
path= device/samsung/crownlte (Where it should download to)
remote= github (where files are stored)
revision= branchname (which version you want)
• Resync Repo like I mentioned before
Code:
repo sync -f --force-sync --no-clone-bundle --no-tags -j$(nproc --all)
BUILDING
• Run
Code:
. build/envsetup.sh
• Then
Code:
brunch codename
• Make sure to clean build by running this in between builds
Code:
make clobber && make clean
• If you are using a slow system and want to improve build speeds, use the following command
for making partially clean builds for incremental updates
Code:
make installclean
• Building without cleaning is called dirty building and is never advised and do not do this unless
you know what you are doing
KEEPING SETUP UP TO DATE
• Repo sync will keep your rom and device specific files that have been deined in roomservice up to date
CREDITS
NathanChance
All threads on XDA
All guides on Github
All devs found on Telegram
If you want specific credits plz do notify me!
XDA:DevDB Information
BUILDING ANDROID, ROM for all devices (see above for details)
Contributors
vsoma
ROM OS Version: Android 10
ROM Firmware Required: NOOB
Version Information
Status: Stable
Created 2020-10-03
Last Updated 2020-10-03
I need rom porting guide for android 10....can you make thread on it?
I tried the tutorial, after the step repo sync -f --force-sync --no-clone-bundle --no-tags -j$(nproc --all). I get message error: RPC failed; curl 56 GnuTLS recv error (-24): Decryption has failed.
i can't finish compiling because java.lang.outofmemoryerror : heap size but i have already set the heap size to 8gb

Categories

Resources