[ROM][7.1.2_r8][UNOFFICIAL] LineageOS 14.1 for Nexus 7 2012 (grouper)
*** Disclamer
By downloading and installing this ROM you agree that you do so at
your own risk, and that you understand that it probably voids your
warranty. (But does anyone still have an active warranty on this 2012
device?)
Introduction
@AndDiSa's AOSP 7 builds look pretty nice, but I needed something that seamlessly upgrades from CM13. @GtrCraft who provided our CM13 builds has moved on to other devices, so we need a new CM maintainer. I may not be the right person for that job... but I can at least share the build I made for myself. Perhaps someone will be motivated to join the fun or even take over.
[Images on screenshots tab.]
Installation instructions
Back up your data and previous ROM with TWRP 3.0.2 or 3.1.0.
Download from link below.
Wipe system, cache, dalvik.
Also wipe data unless you are coming from CM13.
Install the ROM.
Optionally add opengapps-pico.
With default settings it will give an error about insufficient space. To avoid that, first copy this gapps-config-grouper.txt file, perhaps edit it to your taste (instructions here), then copy to the device in the same directory as the opengapps zip. The opengapps updater-script will look for it there when you install opengapps.
Reboot.
WAIT for system to settle before you decide it is slow. Some of the app optimization which used to happen during initial boot now seems to happen in the background. When it's finished, responsiveness will improve.
If you use ext4, run fstrim.
There are ways to automate this, but I just run this app after each ROM upgrade, plus roughly once a week, after large batches of app updates from Play Store, or whenever my tablet starts to feel sluggish.
Download
lineage-14.1-20171122-UNOFFICIAL-aaopt-grouper.zip (AndroidFileHost)
Credits / Thanks
Google / AOSP
CyanogenMod LineageOS
@AndDiSa for AOSP 7.1 -- I use his kernel tree directly, and many of his device tree mods
@GtrCraft for the CM13 tree upon which mine is based
XDA:DevDB Information
Unofficial LineageOS 14.1 for Nexus 7, ROM for the Nexus 7
Contributors
aaopt, AndDiSa,GtrCraft
Source Code: https://github.com/aperomsik/lineageos_android_device_asus_grouper/
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.1.x
Based On: LineageOS
Version Information
Status: Testing
Created 2017-01-02
Last Updated 2017-12-19
Changelog
Nearly all builds include LineageOS sync -- only mentioned specifically when it was the main point of the build.
(TESTING)20181209 (AndroidFileHost)
@AndDiSa's kernel and device tweaks since my last build and LineageOS sync.
(TESTING)20181104 (AndroidFileHost)
@AndDiSa's kernel and device tweaks since my last build and LineageOS sync.
(TESTING)20180708 (AndroidFileHost)
Added @AndDiSa's kernel and device tweaks since my last build and LineageOS sync with June patches.
(TESTING)20180121 (AndroidFileHost)
@AndDiSa's January performance tweaks. LineageOS sync with January patches.
older entries:
20171122 (AndroidFileHost)
LineageOS sync with November patches.
(TESTING) 20171112 (AndroidFileHost)
@AndDiSa's latest kernel and device tweaks.
(TESTING) 20171020 (AndroidFileHost)
LineageOS sync including October patches and KRAKN fix.
Kernel updates and latest device performance tweaks from @AndDiSa .
(TESTING) 20170811 (AndroidFileHost)
LineageOS sync including August patches.
20170717 (AndroidFileHost)
LineageOS sync brings us to 7.1.2r24 ; perf tweak from @AndDiSa
20170702 (AndroidFileHost)
LineageOS sync
20170609 (AndroidFileHost)
LineageOS sync including June patches; Following @AndDiSa's lead to intelliactive governor, for hopefully improved battery life with minimal performance impact.
20170507 (AndroidFileHost)
Following @AndDiSa's lead to pick up a better fix for RenderThread issues from UnlegacyAndroid.
20170503 (AndroidFileHost)
LineageOS sync brings us to 7.1.2_r8
20170423 (AndroidFileHost)
LineageOS sync brings us to 7.1.2_r2
Updated with @AndDiSa's kernel and device tree updates, including the RenderThread app crash fix he got from @Ziyann.
20170315 (XDA)
Updated with @AndDiSa's kernel and device tree updates.
20170308 (AndroidFileHost)
LineageOS sync includes March security patches. For unknown reasons this build seems to be somewhat crashy.
20170226 (AndroidFileHost)
LineageOS sync includes Feb security patches
20170212 (AndroidFileHost)
AndDiSa's kernel updates
20170129 (AndroidFileHost)
AndDiSa's kernel updates
20170122 (AndroidFileHost)
LineageOS sync, including boot animation and settings updates and various other fixes here and there.
20170108 (AndroidFileHost)
Switch to Snap camera, at least for now.
20170101 (AndroidFileHost)
First LineageOS 14.1 build for grouper.
Unofficial CM 14.1 (XDA)
Previous history in my CM 14.1 thread.
More detailed history: my device tree, AndDiSa's kernel, LineageOS .
Try this at home
(a.k.a. Build instructions)
There are plenty of guides to building CM. Those guides are still relevant with the possible exceptions of their URLs. Assuming you have read enough such guides to have the general idea of how to build a ROM from source, here is one way you can set up your source tree to mimic mine.
In a clean directory, perhaps ~/android/lineageos-14.1/ :
Code:
repo init -u git://github.com/LineageOS/android.git -b cm-14.1
git clone https://github.com/aperomsik/lineageos_local_manifests.git .repo/local_manifests -b cm-14.1
repo sync -c
. build/envsetup.sh
brunch grouper
fantastic Job! We now have a new ROM
aaopt said:
(a.k.a. Build instructions)
There are plenty of guides to building CM. Those guides are still relevant with the possible exceptions of their URLs. Assuming you have read enough such guides to have the general idea of how to build a ROM from source, here is one way you can set up your source tree to mimic mine.
In a clean directory, perhaps ~/android/lineageos-14.1/ :
Code:
repo init -u git://github.com/LineageOS/android.git -b cm-14.1
git clone [email protected]:aperomsik/lineageos_local_manifests.git .repo/local_manifests -b cm-14.1
repo sync -c
. build/envsetup.sh
brunch grouper
Click to expand...
Click to collapse
Recent version of repo doesn't seem to explicitly support '-c' parameter any more to reduce the download size (mine have been around 30GB). Thanks for these instructions; still, I would like to know how you integrated the required changes for 14.1 grouper.
nixuser1980 said:
Recent version of repo doesn't seem to explicitly support '-c' parameter any more to reduce the download size (mine have been around 30GB). Thanks for these instructions; still, I would like to know how you integrated the required changes for 14.1 grouper.
Click to expand...
Click to collapse
It's all in the local manifests.
Sent from my Nexus 7 using Tapatalk
Thank you aaopt for keeping our old Nexus 7 alive !
Can someone tell me the perfect settings for Kernel Adiutor to get the maximum performances ? Even if the battery life is shorten.
Thanx in advance
aaopt said:
It's all in the local manifests.
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
Just took a look at those. I have been using TheMuppets at github for the proprietary components, having needed to patch the nvidia components due to an old GNU-ism (gcc extension that was eventually formalised).
Saw that you got the broadcom et al components from your "ads" git repo and wanted to know if there was any reason not to use TheMuppets (or if, indeed, you sourced them from there and modified them), that I can learn from.
Thanks again.
aaopt said:
(a.k.a. Build instructions)
There are plenty of guides to building CM. Those guides are still relevant with the possible exceptions of their URLs. Assuming you have read enough such guides to have the general idea of how to build a ROM from source, here is one way you can set up your source tree to mimic mine.
In a clean directory, perhaps ~/android/lineageos-14.1/ :
Code:
repo init -u git://github.com/LineageOS/android.git -b cm-14.1
git clone [email protected]:aperomsik/lineageos_local_manifests.git .repo/local_manifests -b cm-14.1
repo sync -c
. build/envsetup.sh
brunch grouper
Click to expand...
Click to collapse
Can confirm that this works - now I just need to find the magic in the code. Also, how did kernel/timeconst.pl not need to be replaced with timeconst.bc and kernel/Makefile not need to be amended to use bc instead of perl? I was getting a compile error because of this in the grouper kernel tree.
nixuser1980 said:
Just took a look at those. I have been using TheMuppets at github for the proprietary components, having needed to patch the nvidia components due to an old GNU-ism (gcc extension that was eventually formalised).
Saw that you got the broadcom et al components from your "ads" git repo and wanted to know if there was any reason not to use TheMuppets (or if, indeed, you sourced them from there and modified them), that I can learn from.
Thanks again.
Click to expand...
Click to collapse
The "ads" git repos referenced in my manifests are AndDiSa's. My repos are labelled "aaopt".
As stated in OP my goal with this ROM is to continue GtrCraft's CM13 work now that he has moved on to other devices. He had been following AndDiSa's proprietary components from AOSP so I just continued that way. In fact I took it a step further by using AndDiSa's kernel directly, not (yet?) seeing a clear reason to maintain my own. I just want to do the minimum amount of work needed to keep somewhat up to date with upstream LineageOS and take advantage of AndDiSa's device-specific performance improvements from the AOSP side.
aaopt said:
The "ads" git repos referenced in my manifests are AndDiSa's. My repos are labelled "aaopt".
As stated in OP my goal with this ROM is to continue GtrCraft's CM13 work now that he has moved on to other devices. He had been following AndDiSa's proprietary components from AOSP so I just continued that way. In fact I took it a step further by using AndDiSa's kernel directly, not (yet?) seeing a clear reason to maintain my own. I just want to do the minimum amount of work needed to keep somewhat up to date with upstream LineageOS and take advantage of AndDiSa's device-specific performance improvements from the AOSP side.
Click to expand...
Click to collapse
Oops. I got that wrong. Anyway, thanks for your work and I learned a few things from it.
Just flashed it, will see how it goes.
For now when the only bug
When i take picture with camera, it mirrors it and makes it look pixelish
Great! Happy to see our grouper still updated, thanks
Inviato dal mio Nexus 7 utilizzando Tapatalk
Hey there! Will there be a ROM for Tilapia? I'd be nice to try it on it. I'm not a programmer but as I noticed building for Grouper and Tilapia is just a little different.
I think You can just flash the grouper recovery and flash the ROM.
From one day of full usage:
- The charging is a bit slow, i don't know if it's a big battery or the power flow is low
- There is lagging, like the ROM isn't optimized yet, slowdowns, applications are usually giving me stopped working etc...
- The camera bug i mentioned above, when u take picture it looks pixelated
I'll do more reviews like this if the updates keep coming
Cannot use the video option in the camera app.
The camera app force closes.
CrazyLegenD said:
From one day of full usage:
- The charging is a bit slow, i don't know if it's a big battery or the power flow is low
- There is lagging, like the ROM isn't optimized yet, slowdowns, applications are usually giving me stopped working etc...
- The camera bug i mentioned above, when u take picture it looks pixelated
I'll do more reviews like this if the updates keep coming
Click to expand...
Click to collapse
Here is a build I am testing, in which all I did was sync sources with upstream. It feels somewhat less laggy to me... not sure if it is due to Lineage changes, 7.1.1_r9, or the fact that I used newer opengapps.
Camera issue is interesting -- I have a shot in my camera folder from 11-29 which looks better. Current shots claim to have the same resolution but file size is much smaller, which suggests the wrong jpeg quality setting was used. Something to dig for.
Regarding charging, are you saying it charges more slowly with this ROM than with others? Charging speed varies widely for me but recently it hasn't been that bad. If your hardware is behaving the expected charging time from nearly empty is supposed to be 3-4 hours. Over time the connector gets loose and then charging can take much longer. There are plenty of charging-related threads around here including some which say to replace the USB port and one which says take out the existing port and put it back in. Tried that on the worst of my family's tablets and it helped for a day or so but then went back to old slow charging speed.
Why is the "Mobile network signal" in orange in a WiFi tablet ?
eNVy said:
Why is the "Mobile network signal" in orange in a WiFi tablet ?
Click to expand...
Click to collapse
How did you get to that screen?
Related
If you are a developer, and wish to have a device merged into Omni, here is the current "temporary" process to use. There are 2 ways to do this - make your tree available on github (or a similar service), or request a new git tree be created, and submit it to gerrit.
1) Get your device working. There's plenty of help available in #omnirom on Freenode if you need assistance. An AOSP device tree is probably the best place to get started.
2) Set up your device to use the OmniROM "custom" build type, rather than full/aosp. More information will follow on this step - check device/samsung/manta or device/lge/mako for an example.
3) Make your device tree available on github or a similar git service. Please retain authorship of an original tree (if you fork it from AOSP or another custom ROM)
4) Come to #omni on Freenode, and have a chat to one of the core developers (they are listed at the top of the user list) - they will be able to help you get your device merged
Please note, in order to add a new device, we will require a maintainer on an ongoing basis for it, to ensure someone is able to investigate bugs that users report on a device. Without this, we unfortunately cannot enable nightly builds for a device.
will a cm kernel tree work for the most part with just a few changes?
azoller1 said:
will a cm kernel tree work for the most part with just a few changes?
Click to expand...
Click to collapse
yes - of course it must be 10.2 (4.3)
most likly it will work even unchanged
pulser_g2 said:
3) Make your device tree available on github or a similar git service. Please retain authorship of an original tree (if you fork it from AOSP or another custom ROM)
Click to expand...
Click to collapse
Along these lines, do NOT remove copyright attributions of a changed file. You may ADD copyrights to a header, but do NOT remove anything.
maxwen said:
yes - of course it must be 10.2 (4.3)
most likly it will work even unchanged
Click to expand...
Click to collapse
Most likely kernel change will be that reverting out that MDP sync point mess used by CM's AOSP+CAF frankendisplay. Can't link to it from my current location.
I have everything device sided transformed to Omni (m7ul,m7-common,and msm8960) and have exactly this problem now. Builds fine but Stucks after a few secs booting and hard reboots. Already looked into kmsg with maxwen but now we need to find what's causing it...
Reverted some stuff (MDP) kernel sided but haven't succeeded so far. Would be appreciated if u point us there when u back on a pc
noNeedForAsig
TF300T
OK here goes..
For the Asus Transformer TF300T the kernel forked from the CyanogenMod github:
https://github.com/scanno/android_kernel_asus_tf300t/tree/android-4.3
And the device tree, modified to get OmniROM to finish the build and get a bootable result:
https://github.com/scanno/android_device_asus_tf300t/tree/android-4.3
Hopefully it will be added to the OmniROM github.
n3ocort3x said:
I have everything device sided transformed to Omni (m7ul,m7-common,and msm8960) and have exactly this problem now. Builds fine but Stucks after a few secs booting and hard reboots. Already looked into kmsg with maxwen but now we need to find what's causing it...
Reverted some stuff (MDP) kernel sided but haven't succeeded so far. Would be appreciated if u point us there when u back on a pc
noNeedForAsig
Click to expand...
Click to collapse
I'm thinking for m7ul it would be https://github.com/CyanogenMod/android_kernel_htc_m7/commit/f2efb02581110747711c8b17f31f38fc3ed5dd1a
Don't want to hijack the thread though, so we can probably discuss this elsewhere
@Grarak Maybe you should post your edited device tree for Omni Rom =)
Sent From my i9500 With ☆★Crash Rom★☆
AL_IRAQI said:
@Grarak Maybe you should post your edited device tree for Omni Rom =)
Sent From my i9500 With ☆★Crash Rom★☆
Click to expand...
Click to collapse
Already on my github
https://github.com/Grarak/android_device_samsung_i9500
kernel tree
https://github.com/Grarak/android_kernel_samsung_exynos5410
proprietary
https://github.com/Grarak/proprietary_vendor_samsung
exynos 5410 repos:
https://github.com/intervigilium/android_hardware_samsung_slsi_exynos5410
https://github.com/intervigilium/android_hardware_samsung_slsi_exynos
https://github.com/intervigilium/android_hardware_samsung_slsi_exynos5
https://github.com/intervigilium/android_hardware_samsung_slsi_exynos5-insignal
https://github.com/intervigilium/android_hardware_samsung_slsi_openmax
pretty much ^^
I'd like to maintain for l900 and i605 (Sprint and Verizon Galaxy Note 2).
device trees
https://github.com/omnirom-slickrick/android_device_samsung_l900 (sprint tree)
https://github.com/omnirom-slickrick/android_device_samsung_i605 (vzw tree)
https://github.com/omnirom-slickrick/android_device_samsung_t0lte (note 2 common tree)
https://github.com/omnirom-slickrick/android_device_samsung_smdk4412-common (same as tree on omnirom github but actually more updated and device settings added back)
kernel
https://github.com/omnirom-slickrick/android_kernel_samsung_smdk4412 (just have needed device settings commits added back in)
thracky said:
I'm thinking for m7ul it would be https://github.com/CyanogenMod/android_kernel_htc_m7/commit/f2efb02581110747711c8b17f31f38fc3ed5dd1a
Don't want to hijack the thread though, so we can probably discuss this elsewhere
Click to expand...
Click to collapse
we already making progress but it needs more work to be done.. at least we are now in system with working wifi, and display but modem doesent work.. something for tomorrow, and i dont want to hijack this thread too sorry if my question was in the wrong section but i thought i mention it because of the post above mine. nevermind i cann offer to maintain m7ul as already discussed with maxwen and oin IRC but a lot of work needs to be done:
here are my sources, device trees are usable but kernel needs more work as said above:
device trees:
https://github.com/n3ocort3x/android_device_htc_m7ul
https://github.com/n3ocort3x/android_device_htc_m7-common
https://github.com/n3ocort3x/android_device_htc_msm8960-common
kernel: its a modified one but its no problem to bring it back to stock features and will push as soon asap the modem stuff is sorted out
https://github.com/n3ocort3x/android_kernel_htc_m7
EDIT modem fixed, only BT left
@sykomaniac , look at first post and become a maintainer
pulser_g2 said:
If you are a developer, and wish to have a device merged into Omni, here is the current "temporary" process to use. There are 2 ways to do this - make your tree available on github (or a similar service), or request a new git tree be created, and submit it to gerrit.
1) Get your device working. There's plenty of help available in #omnirom on Freenode if you need assistance. An AOSP device tree is probably the best place to get started.
2) Set up your device to use the OmniROM "custom" build type, rather than full/aosp. More information will follow on this step - check device/samsung/manta or device/lge/mako for an example.
3) Make your device tree available on github or a similar git service. Please retain authorship of an original tree (if you fork it from AOSP or another custom ROM)
4) Post a link here to the device tree (and kernel repository) for review, and tell us what device it is (give model numbers and board names and as many details as possible )
Click to expand...
Click to collapse
We have quite a few things that aren't working like bluetooth, camera is buggy, H/W vsync, gps, and fm radio.
https://github.com/SeannyM/android_device_samsung_kylessopen
https://github.com/SeannyM/ba2x-kernel
gt-s7560m with quadband gsm and 850/1900/2100 WCDMA/UTMS
We have a MSM7227a cpu armv7 clocked at 1008mhz stock.
645mb of usable ram
4gb of storage with 1.7 usable
233 dpi 800x480 4inch screen
Adreno 200 enhanced
5mp camera 1.3 front facing
hopefully we can get something official
single sim
Gtab2 10.1 Wifi & 3G (p5110 & p5100)
There you have my device tree for omni
p5110 :
https://github.com/sevenup30/android_device_samsung_p5110
p5100:
https://github.com/sevenup30/android_device_samsung_p5100
omap4-common (had to edit it cuz of duplicate libion entry):
https://github.com/sevenup30/android_device_samsung_omap4-common
other dependencies required from CM & Themuppets
kernel :
https://github.com/CyanogenMod/android_kernel_samsung_espresso10
samsung proprietary:
https://github.com/TheMuppets/proprietary_vendor_samsung
samsung hardware:
https://github.com/CyanogenMod/android_hardware_samsung
apps samsung service:
https://github.com/CyanogenMod/android_packages_apps_SamsungServiceMode
Everything is working (sound / wifi / bluetooth / video playback) BUT!
I must edit build.prop by hand to get sound working until omni build process take care of "product_build_prop_overrides" into custom_XXXX.mk
see:
http://forum.xda-developers.com/showthread.php?t=2484747
Original Samsung Galaxy Note
Samsung n7000 initial bringup:
Modified CM n7000 device: https://github.com/chasmodo/android_device_samsung_n7000/tree/android-4.3
Modified CM galaxys2-common: https://github.com/chasmodo/android_device_samsung_galaxys2-common/tree/android-4.3
CM smdk4412 kernel: https://github.com/CyanogenMod/android_kernel_samsung_smdk4412/tree/cm-10.2
Samsung proprietary stuff: https://github.com/TheMuppets/proprietary_vendor_samsung/tree/cm-10.2
Samsung hardware tree untouched from OmniRom.
Device info:
Board platform - exynos4
SOC - exynos4210
Board name - smdk4210
Kernel specifics - unified kernel and recovery
It compiles fine using the repos listed above, but throws up a kernel assert error when flashing the Rom. Several compilers for different devices complained about it in the 'All the answers' thread. The way out of this is to flash a CM10.2 kernel immediately after the Rom flash aborts, then Omni boots up fine.
What works:
1. telephony
2. mms
3. WiFi
4. GPS
What doesn't work:
1. data
2. bluetooth turns off as soon as you turn it on
3. both sdcards are invisible from Android; all your stuff is there when you drop into recovery, though
4. Settings/Storage FC when tapped - see #3
5. Performance options also FC
6. Notification drawer cannot be pulled down
Camera cannot be tested because it shuts down as soon as you start it, saying: "No external storage available" - again, see #3
Galaxy Note II / N7100 (International)
Samsung Galaxy Note II / N7100 Bring up details.
I have a working build of the Omni rom for the N7100. Below are the details on what is working and not working. i have been using it for the last 2 days, so far not crashes or reboots all seems to be working fine. i cherry picked a few commits and included it into my build
Working :
WIFI
DATA -3G & 2G
Telephony & MMS & SMS
GPS
Sound
Camera (Both Front and Back)
SD card
Performance control
Notification drawer & Lights
Multi-Window
roadrunner
Not Working :
BT
Backlights(if i install a custom kernel then the lights work)
Device Tree for N7100 - https://github.com/tilaksidduram/device_samsung_n7100
Device smdk4412-common - https://github.com/tilaksidduram/android_device_samsung_smdk4412-common
smdk-4412 Kernel (3.0.100) - https://github.com/CyanogenMod/android_kernel_samsung_smdk4412
samsung hardware - https://github.com/CyanogenMod/android_hardware_samsung
DEVICE: GT-N7100
sources
https://www.github.com/UtkarshGupta/android_device_samsung_n7100
https://www.github.com/omnirom/android_device_samsung_smdk4412-common
https://www.github.com/omnirom/android_hardware_samsung
https://www.github.com/omnirom/android_kernel_samsung_smdk4412
https://www.github.com/TheMuppets/proprietary_vendor_samsung
Is anyone else working on d2att/d2can (Galaxy S3 I747)? I'm not overly familiar with ROM development, but I can compile CM10.2 for this device just fine, and I'm slowly working on getting Omni to compile for it as well. If someone more experienced than I is already working on it though, I'll probably just let them do it.
If I am the only one, expect some newb-ish questions in the near future.
dstruct2k said:
Is anyone else working on d2att/d2can (Galaxy S3 I747)? I'm not overly familiar with ROM development, but I can compile CM10.2 for this device just fine, and I'm slowly working on getting Omni to compile for it as well. If someone more experienced than I is already working on it though, I'll probably just let them do it.
If I am the only one, expect some newb-ish questions in the near future.
Click to expand...
Click to collapse
I think a few are... There has been chat of it in the IRC channels.
Device name: LG Optimus 4X HD
Codename: P880
Board name: X3
Chipset: Tegra 3 AP33
Everything works, except button backlight.
https://github.com/Adam77Root/android_device_lge_p880
https://github.com/Adam77Root/android_kernel_lge_x3
https://github.com/TheMuppets/proprietary_vendor_lge
In Alphabetical Order
AOSP ROM
ABC
Aquari
Benzo
Google+
Bliss
Google+
BlissRoms-Devices
Carbon
Google+
Copperhead
Cyanide
Google+
CyanideDevices
DarkKat
Elixir
Evervolv
Google+
Euclidean
Google+
Krexus
Google+
LiquidDeath
Google+
LiquidNougat
Master-Branch
Minimal
Google+
Nitrogen
Google+
nitrogen-os-devices
noobbuilds
PureNexus
Google+
SAOSP
Google+
Screw'd
Google+
Sheve
TorMan
TwistedCore
Google+
UBERROMS
Google+
UnholyDevs
Unlegacy-Android
Velvet
YAOSP
Google+
AOSP+CAF ROM
AICP
Google+
Anonymity
AOKP
Google+
AospExtended
Google+
BeanStalk
Google+
Candy
Google+
CandyDevices
Cardinal
Google+
Cardinal-devices
CMRemix
Google+
Cosmic
Google+
Crap
crDroid
Google+
crdroid-devices
Cypher
Google+
Darkness-reDefined
Discovery
Emotion
FireHound
Google+
FireHound-Devices
***** Ground Zero ROMs *****
GZR Google+
Tesla
TeslaROM-Devices
Tipsy
TipsyOs-Devices
Validus
ValidusOs-Devices
***** Ground Zero ROMs *****
Heritage
Hexagon
Google+
Hexa-Project
Lineage
Google+
Liquid Dark
Google+
LiquidDark-Devices
Mokee
Google+
NetHunter
Newel
aliceteam
Next
Nuclear
Google+
Oct
Google+
Team-OctOS-Devices
Omni
Google+
Orion
Google+
TeamOrion-Devices
PNougat-CAF
Reaper
RR
Google+
ResurrectionRemix-Devices
Scarex
Slim
Google+
Slim-Mimorin
StonedOSP
SudaMod
Google+
SudaMod-devices
Suicide-Squad-OMS
UB
Google+
UltraDevs
UOS
Google+
Vanir
Google+
Vertex
VertexOS-devices
Viper
XenonHD
Google+
XOSP
Google+
XOSP-devices
XPe
Google+
CAF ROM
AOSIP <= CAF
Google+
AOSiP-devices
AOSParadox
Google+
Athene <= CAF
BORG <= CAF
Citrus-CAF <= CAF
Cirtus-CAF n-8916 <= CAF
Cirtus-CAF n-8952 <= CAF
Cirtus-CAF n-8996 <= CAF
Google+
Exodus <= CAF
Google+
Halogen <= CAF
Google+
Infinitive <= CAF
Google+
InfinitiveOS-Devices
KodeParadise <= CAF
Omega <= CAF
Paranoid <= CAF
Google+
Phenex <= CAF
Phenex OS
XesKi <= CAF
Zephyr <= CAF
Google+
ZephyrOS-Devices
Note : ROMs that are not to be shared when you build them
AOSP
Flash
SkyDragon
AOSP+CAF
Broken
Google+
DU
Google+
Device specific
8890dev
AOSPlusone
AscendToDev
AquaXP
DakTak
Elixium
Exynos5420
FullGreen
FunRom
HUAWEI-MSM8916
J5-Nougat
JDC
LG_Volt-Lineage
Kenzo-CAF
Lineage-onyx
MSM8930-Samsung
Morph
MyAOSP
N3xtBit
nAOSP
Naosp
Nexus4ever
Google+
Omni-onyx
OnePlusOSS <= CAF
PixN
PURE AOSP
Pure-Hammerhead
S4
Slimbit
SM-G361F
SonyAosp
SultanXDA
TeamButter
Tesla-Unleashed
SonyM4
WeedZ
ROMs that has yet to be released
Nameless
Google+ <= Source
Vanilla-Coding <= Source
ROMs that may or may not be updated
aosp-op2
AOSP-RRO
Beltz
Dominion
Exotic
F-ASOP
Mainly
Maple
Google+
Marsh
Google+
n2o
Noise
Purity
Google+
Quantum Droid
Scorpion
SOKP
Google+
SOS
Turbo
Google+
Xylem
Theming/ App
Substratum
Custom ToolChains
UberTC
Linaro => More info here
SaberMod
If you found any ROMs not listed here, mention my name in your reply with the link & i'll update OP, Thanks... :good:
How & Where to look for Newly Develop/ Latest Android Custom ROMs
Open any browser => github.com => Type manifest => Press ENTER
Select => Recently updated
XDA:DevDB Information
List of Active Custom ROMs, ROM for all devices (see above for details)
Contributors
yuweng
ROM OS Version: 7.x Nougat
Based On: AOSP, AOSP+CAF, CAF
Version Information
Status: Testing
Created 2017-01-27
Last Updated 2017-02-13
FAQ
What is AOSP ROM ? What is CAF ROM ? What is HAL ? There are only two types of Android sources, AOSP ROMs uses google source, Eg. here while CAF ROMs uses codeaurora, Eg. here. Do take note that CAF also have different branches, for Eg. AOSPA CAF branch uses 89xx, it won't boot on my MSM8916 or wouldn't even build.
View attachment 4019415
Source
The only custom CAF ROMs that boots on my MSM8916 uses this
View attachment 4019440
Source
Q : How do i know which custom ROMs will build & boot on my Android device ?
A : As RD Santhosh M once told me, you'll never know until you build them & flash it to your device. Generally, from the custom ROM manifest.xml, you'll see whether it is supported. Eg. My Android device uses MSM8916 & if a particular custom ROMs doesn't have that, even though it build but it won't boot. Best is to directly ask the ROM Developer via pm, most of them are active here on XDA or post at their Google+
Q : Which custom ROM shall i build ?
A : Each custom ROM is unique in their own way. i don't plan to review each of them, you'll have to build them & flash it to your device to know its feature. From experience at performance & battery life, 50% is from the kernel & balance is from the ROM, thats why some custom ROMs feels snappier than the other. While some offers custom toolchain too. More info then refer to here
Q : i wanna learn how to build custom ROMs, where do i start ?
A : There are tons of guides here on XDA & elsewhere. Personally, i use BBQLinux, more info then refer to my thread here
Q : i have a slow PC & slow connections
A : Try out Google Cloud for free, more info then refer to nitin.chobhe thread
Misc Tips
Syncing ROM Source
Code:
mkdir -p ~/AOSP/LineageOS
cd ~/AOSP/LineageOS
repo init -u git://github.com/LineageOS/android.git -b cm-14.1
repo sync -fcj68 --force-sync
Source Eg. For my kiwi. Each custom ROMs may be different, refer to their manifest for further build info
More info on syncing source here & info on fixing sync corruption here <= Misc Tips
Code:
cd ~/AOSP/LineageOS
prebuilts/misc/linux-x86/ccache/ccache -M 100G
export USE_CCACHE=1
export LC_ALL=C
export JAVA_HOME=/usr/lib/jvm/default
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"
source build/envsetup.sh
brunch kiwi 2>&1 | tee ~/AOSP/LineageOS/compile.log
My BBQLinux build-script
Fixing build error
From experience after building about forty custom ROMs, most of the time is either the ROM source or device tree. On some custom ROMs, you may need to replace certain projects in order for it to work, more info on using local_manifest.xml. Eg. below
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<[COLOR="Blue"]remove[/COLOR]-project name="android_hardware_qcom_audio" />
<project path="hardware/qcom/audio-caf/msm8916" name="LineageOS/android_hardware_qcom_audio" remote="github" revision="cm-14.1-caf-8916" />
<[COLOR="blue"]remove[/COLOR]-project name="android_hardware_qcom_display" />
<project path="hardware/qcom/display-caf/msm8916" name="LineageOS/android_hardware_qcom_display" remote="github" revision="cm-14.1-caf-8916" />
<[COLOR="blue"]remove[/COLOR]-project name="android_hardware_qcom_media" />
<project path="hardware/qcom/media-caf/msm8916" name="LineageOS/android_hardware_qcom_media" remote="github" revision="cm-14.1-caf-8916" />
</manifest>
If a particular ROM is based on Lineage & Lineage developers there has added a new feature or fix some codes & this particular custom ROM developer haven't updated it yet then most of the time it will cause build error. So either wait for a few days until those changes has been merged then only build again.
Or refer to their github & gerrit to see what are the changes that might causes the build error. Then you can either revert those changes so that the ROM can be build. An Eg. here & the build error hints something about power.h then you can revert the change as below
Code:
cd ~/CustomROM/hardware/libhardware
git revert --no-edit [COLOR="Blue"]f29cb1fd95ee6e5b371d2d6a85c1aeac708b19a6[/COLOR]
View attachment 4034126
Every custom ROMs is unique so refer to their device tree for reference. Eg. Custom MSM8916 flags & dependencies on Omnirom for my kiwi
Another common build error & fixes
Code:
ninja: error: '/home/yuweng/5x/AOSP/Omni/out/target/product/kiwi/obj/SHARED_LIBRARIES/[COLOR="Blue"]libqmiservices[/COLOR]_intermediates/export_includes', needed by '/home/yuweng/5x/AOSP/Omni/out/target/product/kiwi/obj/EXECUTABLES/[COLOR="blue"]wcnss_service[/COLOR]_intermediates/import_includes', missing and no known rule to make it
make: *** [build/core/ninja.mk:149: ninja_wrapper] Error 1
Code:
[COLOR="Red"][B]#[/B][/COLOR] TARGET_USES_QCOM_WCNSS_QMI := true
OR
Code:
TARGET_PROVIDES_WCNSS_QMI := true
Either remark it or just delete that whole flag or add an additional new flag above will fix the build error on omnirom.
While some custom ROMs require additional flags for certain feature to work, always refer to their github device tree for reference. For Eg. on my kiwi, on DU, sliding the BT switch won't work, it will switch on but it won't detect nearby bluetooth devices & in a short while, it will auto switch off. All needed was an additional flag
Code:
BLUETOOTH_HCI_USE_MCT := true
Source
If you are still not able to solve those build errors or a certain function doesn't work on your device then try asking for help at their google+. Some provide realtime on IRC Freenode too. Eg. TWRP & omnirom, always check out the timezone first. Eg. You should be able to catch hold of Dees_Troy TWRP Lead Developer( very nice & approachable developer ) at 9am to 5pm & there won't be anyone around at 3am in the morning obviously !
Ethics
Gives Credit Where Credit is Due
Over the years, i've seen alot of fights & arguments here on XDA & elsewhere regarding taking the work of others. Most developers already shared/ public their work to the world, all you have to do is to show your gratitude by mentioning their name in your work when you share them, thats all they want, to be acknowledged & recognized for their work ! When you don't meaning you are stealing from them, end users wouldn't have known & they will think that you do all the work all by yourself. Gives Credit Where Credit is Due
Detail info then refer to here & here
Official Support
Most ROM Developers doesn't support devices that they don't own. If you do want to maintain a particular ROM for your device then talk to them & see how to work things out !
Example of a Basic requirement of a Device Maintainer
Code:
As a Maintainer you are expected to:
1. Be able to build for your device and provide users with regular builds.
a. You must own the device you wish to maintain. Blind builds and ports are NOT allowed!
b. Exceptions may be made (family/friend's devices with direct access and variants of devices etc) and are to be requested BEFORE submitting your patchset to Gerrit!
c. A Co-Maintainer may be elected for your device by you if wanted. He/she must follow the same rules as you and submit their own commit to Gerrit.
d. Maintainers will have merge permissions to their device and kernel specific repositories and are expected to keep their device in working order. Whether this done by; doing basic upkeep with upstream changes for fixes and updates, starting for an upstream base and doing original work (pushing upstream when you can), or a mixture of both. The main concern is following proper procedure and keeping your device(s) functioning. Additionally, common and shared repositories will be worked on together by the Maintainers; they will still be controlled and merged by the PAC Team. In this respect, teamwork among Maintainers with common devices will not only be encouraged, in some cases, it may be necessary.
2. Threads are to be compared to our templates regularly for updated topic and content changes.
a. Templates are to be used exactly as they are with NO alterations aside the foreseen places like Title, Installation, Updating, Not working, Other info, and additional credits below the current list if any, unless permitted otherwise.
b. Custom additions (custom builds, kernels, patches, software packages etc) are tolerated and may be distributed from the PAC-ROM thread's Downloads section of the first post.
c. Information about any custom additions is to be posted in the 2nd post of both threads.
d. Custom additions are your responsibility, and are not supported by the PAC-ROM Dev Team.
e. The PAC-ROM Dev Team may change, remove, disable, or tell you to delete ANY custom additions or infringing content for any reason, at any time, in our sole discretion.
f. If unsure, ask the reviewer you contacted.
3. Maintainers MUST create an account on our [JIRA] (http://jira.pac-rom.com/). Users will be able to submit issues and find contact information on the Maintainer for their device such as PAC/XDA Threads. Maintainers will be required to upkeep their JIRA support.
4. To maintain proper support and device usability across the PAC-ROM community, if a device is: abandoned, unsupported, unkempt, or devices where the Maintainer has; sold, broken, lost, no longer has and will not be replacing [within the grace period of 4 weeks], or no longer cares to maintain the device for PAC, then the device will be removed. Remember, if the device is removed and it gets further support, from someone else, then it can be resubmitted later as new.
a. Be fair to the users, if you can not maintain the device anymore for whatever reason, please try to find a follow up maintainer, have them submit their take over changes to Gerrit, and have your threads transferred if possible. If this is not possible, please remove the device and submit your cleanup to Gerrit.
5. Prereleases
* Only Maintainers may publish Alpha/Prerelease builds.
* Alpha/Prerelease build version tag should be set to UNOFFICIAL
* Users/Unofficial device Maintainers may NOT release/post our Prerelease builds.
* Permission for Maintainers may be revoked anytime for a Maintainer or global for all Maintainers.
* Alpha/Prerelease builds are to be uploaded to BB/codename/Unofficial.
* Alpha/Prerelease builds are NOT supported by PAC Dev Team or Maintainers.
* Maintainers are to check their XDA device category for threads posting Prereleases/Unofficial builds and have them removed/closed.
* Maintainers can use this opportunity to test and bring up their devices, users can play with cutting edge test builds and return feedback for the Maintainer at their own risk.
* Community/Forum posts about ETA's, Prerelease device compatibility, broken or missing features, or any other acquisition of Prerelease information and support will be deleted/directed toward the Maintainer.
6. As a Maintainer, you will be able to:
* Get official, clean built, and automated nightly/weekly builds from Jenkins.
* Use our file hosting for builds.
* Use our OTA for pushing your own builds.
* Join in on our discussions, get support from the Dev Team and other Maintainers.
* There is no cake, it's a lie!
* Devices that get less than 35 downloads a week are considered low activity and will be moved to weekly.xml.
7. This page is subject to change without notice! Check back regularly here for changes.[/hide]
Original Source
Build Server
Recently a good friend of mine shoxxy from Germany is so kind for letting me try out his build server... :good:
View attachment 4071930
repo sync completed in about 35 minutes only instead of 8 to 10 hours on my home 10MB broadband !
View attachment 4071931
speedtest 200MB/s while my home typically only 8 to 9MB/s !
How this works is that you are actually still using your PC to connect to the build server via terminal ssh, Eg. ssh [email protected] & you'll be prompt for password. shoxxy has already setup the OS so i only need to sync the source & start building ! There is absolutely no GUI only command line so you need to be familiar with nano to edit your device tree.
View attachment 4071955
Copy/ paste from your PC to build server terminal works. Some of the common nano shortcut key is ctrl + k = cut & ctrl + u = paste or you can also use your mouse to highlight that particular line then ctrl + k to cut it & copy whatever you need to replace from your PC to the terminal & right-click mouse to paste it. More info on nano keyboard commands
View attachment 4071985
Build completed successfully. You can also use gdrive to upload your build to google drive... :good:
View attachment 4071988
Use nano to check for build error. nano shortcut key to end of file is Ctrl + w + v
View attachment 4071992
Very important to use screen before you start building or your build will stop when connection is lost !
{
"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"
}
You can even connect directly from your Android device too !
Always wanted something like this . Glad to see you again @yuweng.
How are you my friend, indeed it has been quite awhile since our last chat... :highfive: Back in our early MTK days, absolute nothing can build from source, we have to resort to ROM porting to get the so called custom ROM on our device... Now i can see M.A.D Team are making some progress but not all MTK devices are supported. Mid of last year, i have made the decision to move to Qualcomm SoC, we have close to 50 custom ROMs build from source, Thanks to our device tree bring-up team, crpalmer & BadDaemon, we have 3 generations of Android on it, cm-12.1 (LP), cm-13.1 (MM), cm-14.1 (N) & now we have Official Support too... And Yes, with the exact same device tree, i alone was able to built about 40 of them...
The first custom ROMs database started back in 2013, very detail list but no longer updated, i don't plan to go so deep into it, just links to their source & Google+, you'll have to sync the source, build them, flash them to your device to know what those custom ROMs has to offer, all you need is your device tree, kernel source & vendor tree & last but not least, of course, a MSM SoC not MTK... :laugh:
yuweng said:
How are you my friend, indeed it has been quite awhile since our last chat... :highfive: Back in our early MTK days, absolute nothing can build from source, we have to resort to ROM porting to get the so called custom ROM on our device... Now i can see M.A.D Team are making some progress but not all MTK devices are supported. Mid of last year, i have made the decision to move to Qualcomm SoC, we have close to 50 custom ROMs build from source, Thanks to our device tree bring-up team, crpalmer & BadDaemon, we have 3 generations of Android on it, cm-12.1 (LP), cm-13.1 (MM), cm-14.1 (N) & now we have Official Support too... And Yes, with the exact same device tree, i alone was able to built about 40 of them...
The first custom ROMs database started back in 2013, very detail list but no longer updated, i don't plan to go so deep into it, just links to their source & Google+, you'll have to sync the source, build them, flash them to your device to know what those custom ROMs has to offer, all you need is your device tree, kernel source & vendor tree & last but not least, of course, a MSM SoC not MTK... :laugh:
Click to expand...
Click to collapse
Hehe yeah, the good old MTK days. I still have the same device that you helped me with back in the day and I've done quite some work on my own too, built all the available recoveries, custom kernels and tried two ROMs (CM11 and CM12.1). They don't boot (libs issue) but haha it was a nice experience. I know you switched from the MTK scene for a while now and are working with the Honor device :silly:. M.A.D team is doing something great because a lot of other developers are coming out and getting other devices supported too!!. Sadly it's only the newer generation chips (MT67XX) while I still have the old MT65XX :laugh:. If I ever get a Qualcomm device, I'll be sure to continue following this thread .
Can i know which ROMS would get built for exynos devices?
rohit9757 said:
Can i know which ROMS would get built for exynos devices?
Click to expand...
Click to collapse
Not the purpose of this thread and the developer of that device is who you should be asking that question.
kirito9 said:
Not the purpose of this thread and the developer of that device is who you should be asking that question.
Click to expand...
Click to collapse
Apologies read it wrong and took your post in a wrong way.
Deleted.
rohit9757 said:
I agree I am a noob. Started learning stuff very recently. The device which i own is not an easy device for ROM building but am trying. Saw this wonderful post and thought would get help. But thats ok mate you can talk all about your golden days here[OFF-TOPIC] and I will take help from somebody else as xda is quite big.
Peace.
@OP:-Wonderful thread thank you.
Click to expand...
Click to collapse
I never said anything about not offering help but alright xD.
You do have a point about the OT part tho, a question like that isn't quite as OT as my post.
Theoretically all, as all of them are actually a fork of Android however, having said that, RD codeworkx has ceased development on it since 5 years ago !
Source
rohit9757 said:
Can i know which ROMS would get built for exynos devices?
Click to expand...
Click to collapse
Hello,
I recently compiled CyanogenMod 14.1 for my Android device using the official sources and want to compile Omni 7.1 for the same device and use the device tree and kernel from the official CM sources because there's no device tree for Omni. Is there a way to "convert" the CM device tree to work with the Omni sources? My exact problem is the compiler doesn't know my device so I can't run something like "brunch [device]" or "make [device]", although I already downloaded all device-specific repositories to the same subdirectory as I'd do it on CM.
Thanks in advance,
Oebbler
Oebbler1 said:
Hello,
I recently compiled CyanogenMod 14.1 for my Android device using the official sources and want to compile Omni 7.1 for the same device and use the device tree and kernel from the official CM sources because there's no device tree for Omni. Is there a way to "convert" the CM device tree to work with the Omni sources? My exact problem is the compiler doesn't know my device so I can't run something like "brunch [device]" or "make [device]", although I already downloaded all device-specific repositories to the same subdirectory as I'd do it on CM.
Thanks in advance,
Oebbler
Click to expand...
Click to collapse
You have to go to your android_device_manufacturer_yourphonecodename repo and rename cm.mk to omni_codename.mk, open it and change cm_codename to omni_codename.
You have also to rename cm.dependencies to omni.dependencies, but the repos included in that file may not be in omnirom source, so you would need to manually sync those repos in your android sorce tree.
You might have to make other minor changes, take a look at the rest of code in that repo.
For further info: https://docs.omnirom.org/Porting_Omni_To_Your_Device
Thank you, but I think I won't succeed in building Omni for my device because I always get strange errors.
Probs will get annoyed, cmsdk, cmhw, and cm encryption are significantly annoying. Also they moved their build dir, generally include useless common subtrees, and named dtbtool with CM suffix. Their build tree might be the most significant hindrance to unified building on Android, not only for the many unnecessary additions and dependencies they have for devices, but also they generally lack a community presence to answer or respond to users, so a lot of us get stuck with cleaning up their mess.
Notice how TWRP has a community presence here and are helpful. I'm not hating on cm, they have been doing this longer than most of us, but for ease id recommend using your rom choices tree.
Also the immensely significant annoyance of having to track devicesettings and the unwillingnes to nuke cmactions, combine it with cmsdk, or at least remove it's dependency in most trees is almost certainly going to cause you errors.
Sent from my One using XDA-Developers Legacy app
Hey Guys,
Ok so here is my situation.
I have a really old HTC Kernel that is lacking way behind in commits. Due to this, this is why LineageOS 14.1 is failing to build. Of course I could use a ugly hack and apply the commits manually of the Android Source that requires them but this is quite a ugly hack.
This is how the kernel looks like right now.
CAF Kernel from Dec, 2014 + Code removed ( like comments) by HTC + HTC Open Source Software
I want to go back to "CAF Kernel from Dec, 2014", Apply all of the Latest Commits and then apply the "HTC Open Source Software" on top of the Kernel.
What is the best way to do this, If I merge the Kernel, I have a ton of Conflicts and that isn't really efficient, pretty much the whole kernel is a conflict with extra new files added.
I think the best thing to do is to port the device to the normal android_kernel_cyanogen_msm8916 (because it is a Snapdragon 410 Phone) but I don't know how to do this and don't think it will work because it is missing HTC Features in the Kernel.
The latest source from the last device maintainer is here:
https://github.com/PatrikKT/android_kernel_htc_a31ul/commits/cm-12.1
https://github.com/HTC-MSM8916/android_kernel_htc_msm8916/commits/cm-13.0
I am the next Device Maintainer, hopefully.....
Introduction
A spinoff thread from the previously-supported-official thread by Atman.
This thread will contain my unofficial builds for violet. On the 16.0 version, the only real fix (so far...) have been the fingerprint scanner sepolicy denials. I aim to do monthly/bimonthly builds to keep up to date with security patches, as so far I haven't encountered any other issues (let me know).
On the 17.1 version, I have slowly figured out how to make it work, but it is highly experimental.
The 16.0 ROM is stable (I use it as my daily driver).
If you find any bugs, please do take screenshots, give a way for me to replicate it on my device, and send a logcat. If you're super smart, use a logcat and filter for the keyword so I don't have to do even more digging
Please don't tell me to use PE/Mokee commits.
Yet another update. I've got 17.1 builds working without having to resort to cheap tricks and commits (sort of).
Flash instructions
Same as usual:
Reboot to fastboot and flash recovery with fastboot (You have to use the TWRP linked below. Other versions likely won't boot.)
Reboot to recovery TWRP
Wipe to format data, wipe again to wipe system and cache (not necessary if you're updating, only if you're switching ROMs)
Flash firmware (ADB sideload) (this step is dated. The newer builds have a higher target firmware so you should try to flash without the firmware first, then flash the firmware if the ROM doesn't work.)
Flash the ROM (sideload)
Flash GApps, Magisk, etc. as necessary
Done
Downloads (16.0) (STABLE)
Firmware (Dated firwmare)
Recovery (TWRP)
11-Jun-2021 build (with 05-May-2021 security patch), and MD5 Digest
For previous builds see below
Downloads (17.1)
Here's the 17.1 ROM. Here's the md5 hash. It has the March security patch.
It currently does not boot. If you would like to try and help with development, flash the ROM, and then flash the Chinese Q firmware on top of it (this can be downloaded from xiaomifirmwareupdater). Be warned that there is a risk that the newest android keymaster may re-encrypt your device, which in the worst case may require you to format data and/or reflash recovery and/or flash a fastboot MIUI rom. So, it's a bit risky, but likely won't be an issue.
Credits, Sources, etc.
Too many to mention. Atman Shah for getting this device supported earlier last year. ThE_MarD (Marc Bougoin) for other help. Various other names I've seen - Bruno Martins, Weikai Kong, Wang Han... all of the Lineage dev team. I'm sure I'm missing many people who have been involved in the project. I am new, and very much a latecomer to all of this.
Device Tree: https://gitlab.com/mzha/android_device_xiaomi_violet
Kernel Tree: https://gitlab.com/mzha/android_kernel_xiaomi_violet
Other things see my gitlab: https://gitlab.com/mzha
A telegram group to discuss development for 16.0/17.1: t.me/lineageos_violet
Previous builds
07-Nov-2020 (incl. Oct-2020 security patch), with 07-Nov-2020 MD5 Hash
13-Jul-2020 (incl. Jul-2020 security patch), with 13-Jul-2020 MD5 Hash
11-May-2020 (incl. May-2020 security patch), with 11-May-2020 MD5 Hash
Good to see some devs showing interest on this os
will you be adding any customisation? or does it continue as pure lineage os?
e2vinay said:
Good to see some devs showing interest on this os
will you be adding any customisation? or does it continue as pure lineage os?
Click to expand...
Click to collapse
Pure LineageOS. There's more than enough customised ROMs for violet already in my opinion... and I also don't have that much time
hcnulma said:
Pure LineageOS. There's more than enough customised ROMs for violet already in my opinion... and I also don't have that much time
Click to expand...
Click to collapse
That's great
by any chance will you consider adding signature spoofing support? that would be really great. it would help many users go for microG instead of gapps
I completely understand you're starter.
great work. good luck.
Thank you
e2vinay said:
will you consider adding signature spoofing support?
Click to expand...
Click to collapse
No, but there are a few alternatives:
Merge the changes from this RFC and build it
Download the spoofer from https://download.lineage.microg.org/violet/, or get the (ed)Xposed module, or other possibilities...
Will be official Lineage Os?
Can we expect los 17 soon?
himanshu fulmali said:
Can we expect los 17 soon?
Click to expand...
Click to collapse
As per OP: I'm waiting on both Android 10 firmware blobs + kernel to be released by Xiaomi... I'm not sure how the other ROM devs get around this, if it's easy to forward-port or not. But for now, only LOS 16.
Heyyo @hcnulma good to see you got your thread up and going!
As for 17.1? You can work with your current kernel and cherry-pick the fixes that other maintainers of violet are using and same for the device tree and vendor blobs.
As an example, LeEco msm8996 devives are using kernel source code from Marshmallow just rebased on a CAF Q Tag for our kernel since we never got anything newer...
Even once Xiaomi release their kernel source code for Android 10? It would probably take quite a bit of work to shave it down to what you specifically need and then importing it on top of a fresh CAF tag for the kernel or even more work to try and inplement it into uour current kernel.
To get official builds of LOS 16.0 going again for violet you would need to show that you are capable of fixing any major bugs that arise as well.
https://wiki.lineageos.org/submitting_device.html
anywho, hope this information helps bud!
hcnulma said:
As per OP: I'm waiting on both Android 10 firmware blobs + kernel to be released by Xiaomi... I'm not sure how the other ROM devs get around this, if it's easy to forward-port or not. But for now, only LOS 16.
Click to expand...
Click to collapse
I am pretty sure you can use the pixel experience device tree and kernel to compile the ROM just like every other rom
Thank you. If he is stable enough I will use it to build RR PIE
Zjh0094 said:
Thank you. If he is stable enough I will use it to build RR PIE
Click to expand...
Click to collapse
It's definitely stable...
prajwal2001 said:
I am pretty sure you can use the pixel experience device tree and kernel to compile the ROM just like every other rom
Click to expand...
Click to collapse
From what I understand, using their kernel tree will mean I'll have to change a lot of references in my own device tree, and using their device tree on top of that is essentially just building PE, not Lineage.
In any case, I did find the Snapdragon 675 (ie sm6150) kernel trees for Q in several places, https://github.com/sm6150-dev/android_kernel_xiaomi_sm6150 and https://github.com/PixelExperience-Devices/kernel_xiaomi_sm6150. I'll take a closer look into this...
I did find the most recent CAF kernel under sm6150 here, but there seems to be an issue of this not showing up in /quic/la... Something will be resolved. Hopefully.
Request to create group for discussion in Telegram
hcnulma said:
It's definitely stable...
From what I understand, using their kernel tree will mean I'll have to change a lot of references in my own device tree, and using their device tree on top of that is essentially just building PE, not Lineage.
In any case, I did find the Snapdragon 675 (ie sm6150) kernel trees for Q in several places, https://github.com/sm6150-dev/android_kernel_xiaomi_sm6150 and https://github.com/PixelExperience-Devices/kernel_xiaomi_sm6150. I'll take a closer look into this...
I did find the most recent CAF kernel under sm6150 here, but there seems to be an issue of this not showing up in /quic/la... Something will be resolved. Hopefully.
Click to expand...
Click to collapse
you won't have to make any changes in the kernel as far as I know and as for the device tree you just have to make some changes according to the ROM
as every ROM uses the same device tree
and you won't be making pe instead of lineage as the same device tree and kernel are used in every Q ROM except EvoX which uses crimson kernel
hcnulma said:
It's definitely stable...
Click to expand...
Click to collapse
Thanks. I will use it as my benchmark to build RR pie.
---------- Post added 15th February 2020 at 12:03 AM ---------- Previous post was 14th February 2020 at 11:57 PM ----------
hcnulma said:
In any case, I did find the Snapdragon 675 (ie sm6150) kernel trees for Q in several places, https://github.com/sm6150-dev/android_kernel_xiaomi_sm6150 and https://github.com/PixelExperience-Devices/kernel_xiaomi_sm6150. I'll take a closer look into this...
I did find the most recent CAF kernel under sm6150 here, but there seems to be an issue of this not showing up in /quic/la... Something will be resolved. Hopefully.
Click to expand...
Click to collapse
/quick/la/msm-4.14
prajwal2001 said:
you won't have to make any changes in the kernel as far as I know and as for the device tree you just have to make some changes according to the ROM
Click to expand...
Click to collapse
It is precisely the device tree that I'm worried about. From experience, PE has a lot of platform-specific stuff that Lineage doesn't (and the same the other way), and also from trying to figure out the fix to 16.0 I realised there's a lot of context/definition differences between the two device trees. I'd still give it a look, but I suspect it might be easier to just modify the current 16.0 device tree.
RupeshRN said:
Request to create group for discussion in Telegram
Click to expand...
Click to collapse
https://t.me/lineageos_violet.
Zjh0094 said:
/quick/la/msm-4.14
Click to expand...
Click to collapse
Yeah I already figured it was msm-4.14. Have already cloned it but am also considering cherrypicking changes that other devs have done to their kernel trees from 16.0 -> 17.1 as opposed to starting with the CAF kernel. A work in progress.
Sir I'm noob but mokee dev released android 10 and i think mokee and los are pretty same, will he not help you if you contact him?
An update on where I am:
I'm not sure whether to use the PE or Mokee vendor trees. Neither of them have much resemblance to 16.0 tree I have so cherry picking changes will be a nightmare.
The PE vendor tree has a lot of device-tree-specific commits, which will make it a headache to untangle later on. The Mokee vendor tree also has a lot of differing firmware files, though is a bit more similar to the LOS tree.
I'm doing a bit of experimentation to figure out which one will last better in the long run, since I can't seem to get my hands on any MIUI Android Q firmware blobs.
An update on where I am:
I'm not sure whether to use the PE or Mokee vendor trees. Neither of them have much resemblance to 16.0 tree I have so cherry picking changes will be a nightmare.
The PE vendor tree has a lot of device-tree-specific commits, which will make it a headache to untangle later on. The Mokee vendor tree also has a lot of differing firmware files, though is a bit more similar to the LOS tree.
I'm doing a bit of experimentation to figure out which one will last better in the long run, since I can't seem to get my hands on any MIUI Android Q firmware blobs.
Yet another update. I've got 17.1 builds working without having to resort to cheap tricks and commits (sort of).
Here's the 17.1 ROM. Here's the md5 hash. Needless to say, it's very experimental, not stable in the least (expect to get past boot maybe 70% of the time) - I'm getting very mixed results when experimenting myself. Nevertheless, try it out, see what you get. Install it the same way as usual. Keen to get as many eyes on this as possible