[DEVONLY] LineageOS 16 - Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,

This is the development thread for Lineage 16.
Everyone who knows C, Java and strace is welcome to participate. Please send git formatted patches!
Device Trees
https://github.com/cryptomilk/android_kernel_sony_msm8998
https://github.com/cryptomilk/android_device_sony_common-treble
https://github.com/cryptomilk/android_device_sony_yoshino
https://github.com/cryptomilk/android_device_sony_lilac

I've started to get TWRP building.

I've finally successfully started TWRP based on Android 9.0. However the data partition doesn't get upgraded. So I'm trying to figure out what is failing there now ...

I think I got a working TWRP recovery. First step towards Pie done. I think @derf elot has the Kernel update almost ready. We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.

modpunk said:
I think I got a working TWRP recovery. First step towards Pie done. I think @derf elot has the Kernel update almost ready. We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
Click to expand...
Click to collapse
Thank you very much, I just want to ask if there will gcam HDR+ support in this version?

modpunk said:
I think I got a working TWRP recovery. First step towards Pie done. I think @derf elot has the Kernel update almost ready. We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
Click to expand...
Click to collapse
The new 47.2.A.0.306 stock kernel is merged into an up-to-date LA.UM.7.4.r1 kernel following both CAF and Linux updates (thank again @nathanchance ). Sony is also using LA.UM.7.4.r1 as a base now, so the switch made sense (we/Sony used LA.UM.6.4.r1 before). But we will always be updated to upstream, as is the case for 15.1 already, sometimes even months before some patches for security issues make it on to the ASB.
So far, the kernel builds fine. Will now test it on stock, then "LOS'ify" it - which is pretty straightforward - and we are ready to go.

Hi, first of all, thank you very much for your work on LineageOS!
I'm reposting a message from LineageOS 15.1 thread as it is EOL and you probably missed it and it contains two bugs not listed in OP that I believe are worth investigating on next release or so:
- On calls, we can't hear with headset (unless you unplug and plug back in). It was noted that it worked with beta4 so I investigated and found that this commit was added between beta 4 and 5 so you may have a look at it: https://github.com/cryptomilk/andro...mmit/c4a8569c492b343a0e22b31dd51d0821c9b75b47
- Some apps can't write on their own data folder (/storage/emulated/0/Android/data/<appname>/) if READ/WRITE_EXTERNAL permission not listed in Manifest, so the workaround you mentioned in Known Issues of the thread doesn't work + even if it is listed, it's a privacy issue because we don't want the app to look at other folders.
Examples of apps trying to write in its own data folder with no READ/WRITE_EXTERNAL permission in Manifest:
- com.tinyco.potter (instantly crash)
- com.c4mprod.rtm (instantly crash)
The only workaround possible it to apktool the app, add permission to the Manifest, and in some cases (Harry Potter for example) remove the license verification due to wrong signature after new signing, but the privacy issue remains.
Android documentation about this: https://developer.android.com/reference/android/Manifest.permission#WRITE_EXTERNAL_STORAGE
Starting in API level 19, this permission is not required to read/write files in your application-specific directories returned by Context.getExternalFilesDir(String) and Context.getExternalCacheDir().
Click to expand...
Click to collapse
That's why older versions of apps targeting a lower API than 19 works because they have the writing external permission

This is a DEVONLY thread and not the appropriate place to discuss bugs in a completely different version of the ROM.

Gairtial said:
This is a DEVONLY thread and not the appropriate place to discuss bugs in a completely different version of the ROM.
Click to expand...
Click to collapse
Why do you say it is a "completely different version of the ROM"?
Device and kernel trees are based on 15.1 work, look at the commits, there is almost no differences, so the same bugs will be inherited on 16.
I'm not sure I understand what you mean by "DEVONLY", I'm a dev and I talked of the bugs from a developer point of view (link to commit from the tree, logs, Android documentation).

I don't want to derail the thread (my original goal was to stop the thread from being derailed) but to explain myself some more (and this will be my last post on the matter, this has gotten bad enough as it is):
Yurienu said:
Why do you say it is a "completely different version of the ROM"?
Device and kernel trees are based on 15.1 work, look at the commits, there is almost no differences, so the same bugs will be inherited on 16.
Click to expand...
Click to collapse
16 is in a very early state and we don't know for sure whether the bugs can be reproduced on 16. We can't verify them, we can't diagnose them, we can't test fixes. We can't take any action on them, therefore they don't really belong here. They'd be much better suited to the LOS 15.1 thread, or left until 16 is functional enough that they can at least be verified.
Yurienu said:
I'm not sure I understand what you mean by "DEVONLY", I'm a dev and I talked of the bugs from a developer point of view (link to commit from the tree, logs, Android documentation).
Click to expand...
Click to collapse
I brought up DEVONLY because you're presenting bugs (discussion really belongs in a user thread) rather than fixes, or even work towards fixes (discussion totally belongs in a developer thread). You've presented one bug with some details but nothing that really contributes to fixing it and one with a possibly related commit. However you haven't done anything to determine whether that commit is actually the problem. You could verify for sure by building and testing before and after it. If you did that, you could even look into offering a fix.
I'm not saying this to pick a fight with you or because I hate you or think you're an idiot, I just want to make sure the right discussions are in the right threads so that devs are able to communicate with us and each other without too much pain. Putting your bug report in the 15.1 thread where it belongs ensures that this thread can be used to discuss LOS 16 development, as was clearly the intention of creating it.

Time to fork xD
Do you have a gerrit?

modpunk said:
We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
Click to expand...
Click to collapse
It just arrived. :good:

beggar23 said:
It just arrived. :good:
Click to expand...
Click to collapse
Download is already running ...

The deep sleep bug affecting Yoshino platforms on Pie is being fixed here: https://github.com/kholk/kernel/commits/232r14-sleep-bug-research
According to the pull request to official kernel, this should mitigate the issue.
Please keep us informed if there is anything else preventing a release.
I was not able to boot LineageOS 16 compiled from your repos but if you can provide a flashable package, I can help testing if you need help?

Can you provide a status update please? How are things going? Is there something bootable at least (even if self-compiling is required)?

There is something which can be compiled. I dunno if it boots yet.

Read on Reddit that what's holding back LOS16 is "LineageHW deprecation in favor of new "treble-ready" HALs".
From the thread "What's holding back the LOS16 release ?" posted 9 days ago in r/LineageOS by u/FishTheFish152.

Any news here? How to participate?

building LineageOS 16.0 including TWRP for pie
I am sharing my steps used to build los16 with repos provided by @modpunk in the OP, in the hope that more devs could participate in the development.
Disclaimer: the result of this does not boot, so I am not sure at all if my howto and modifications are good or wrong.
Still hoping it might be useful to someone or maybe @modpunk or @derf elot could provide some hints to reach current status of this project?
Big thanks to @modpunk and @derf elot for working on this project.
Basically I tried to follow los15 howto as provided in the README.md of the modpunk's android_device_sony_lilac repository - just adapting it for los16 instead of los15:
initialize repo: used branch "lineage-16.0", first sync was done on 2019-03-18 with resync on 2019-03-19 (for the record of the los16, twrp and modpunk's repos source tree state)
for local manifest I've used this:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<!-- SONY -->
<project name="cryptomilk/android_kernel_sony_msm8998" path="kernel/sony/msm8998" remote="github" revision="lineage-16.0-LA.UM.7.4.r1" />
<project name="cryptomilk/android_device_sony_common-treble" path="device/sony/common-treble" remote="github" revision="TESTING" />
<project name="cryptomilk/android_device_sony_yoshino" path="device/sony/yoshino" remote="github" revision="TESTING" />
<project name="cryptomilk/android_device_sony_lilac" path="device/sony/lilac" remote="github" revision="TESTING" />
<!-- Pinned blobs for lilac -->
<project name="cryptomilk/android_vendor_sony_lilac" path="vendor/sony/lilac" remote="github" revision="lineage-16.0" />
<!-- TWRP recovery -->
<remove-project path="bootable/recovery" name="LineageOS/android_bootable_recovery" groups="pdk" />
<project name="omnirom/android_bootable_recovery" path="bootable/recovery" remote="github" revision="android-9.0" />
<remove-project path="vendor/qcom/opensource/data-ipa-cfg-mgr" name="LineageOS/android_vendor_qcom_opensource_data-ipa-cfg-mgr" groups="qcom,pdk-qcom" />
</manifest>
Please note, I've used TESTING branch instead of lineage-16.0 as it seems that the newest changes happen there for los16 development. Similarly I tried to guess the right kernel branch based on the most recent commits: lineage-16.0-LA.UM.7.4.r1 - hopefully that is right.
Also I tried to build TWRP in the process, so replacing los recovery with upstream twrp for pie one in the local manifest.
There has been a conflict in los source tree with data-ipa-cfg-mgr that has been pulled also from modpunk's local manifest, so that is why I am removing the los one in my local manifest here.
to speed up the sync and reduce the disk space, I am using this command:
Code:
repo sync --no-tags --no-clone-bundle -c -j8
in the Extract vendor blobs step, I am using
Code:
SRC=/path/to/unpacked-fw/xz1c-pie-8.24 ./extract-files.sh
command, having full fw unpacked into plain files all readable for normal user including fixes for symlinks to be relative instead of pointing to / directory. As I was not sure about the right fw version, I've tried pie 4.45 too for the blobs extraction. During the build, some blob was missing, so I've added proprietary-files-rootfs.txt file into device/sony/lilac directory with following content:
Code:
# ROOTFS_TRIMAREA
-sbin/tad_static;rootfs
for Setup the environment, I am using following:
Code:
unset JDK_HOME
unset JAVA_HOME
unset JAVAC
export OUT_DIR_COMMON_BASE=/path/to/lineageos/output
export WITH_TWRP=true
source build/envsetup.sh
lunch lineage_lilac-userdebug
Those unset's I had to use to avoid build problem complaining about javac different versions for .mk and soong - quite difficult to find that workaround.
The OUT_DIR_COMMON_BASE is to make compiled stuff to go outside the source tree to speed up greping there.
The WITH_TWRP option seems to be needed to let some makefiles know we like to build twrp recovery.
I've tried lineage_lilac-userdebug first, after lots of fixes during the build, the result did not boot, so I tried lineage_lilac-eng lunch target too with basically the same result unfortunately.
before Build LineageOS step, you may try to apply my changes/fixes that I had to use to avoid build errors (some were quite tricky actually) - please see the attachment here for the combined patch.
This is my repo status after the changes:
Code:
project bootable/recovery/ (*** NO BRANCH ***)
-m applypatch/Android.bp
-m applypatch/applypatch.cpp
-m crypto/lollipop/cryptfs.c
-m minui/events.cpp
-- mtdutils/Android.bp
-m otautil/Android.bp
-m otautil/Android.mk
-m updater/Android.mk
-m updater/install.cpp
project build/make/ (*** NO BRANCH ***)
-m tools/releasetools/common.py
project device/sony/common-treble/ (*** NO BRANCH ***)
-m sepolicy/vendor/file.te
project device/sony/lilac/ (*** NO BRANCH ***)
-- proprietary-files-rootfs.txt
project device/sony/yoshino/ (*** NO BRANCH ***)
-m recovery/twrp.fstab
-m sepolicy/vendor/file.te
-m sepolicy/vendor/hal_livedisplay_default.te
-m sepolicy/vendor/startup-logger.te
-m sepolicy/vendor/toolbox.te
project vendor/sony/lilac/ (*** NO BRANCH ***)
-m proprietary/framework/qti-telephony-common.jar
following command would build los16 including twrp recovery:
Code:
make -j5 bacon
The built images and installation zip can be found under ${OUT_DIR_COMMON_BASE}/lineage-16.0/target/product/lilac directory:
twrp recovery image: recovery.img
kernel boot image: boot.img
los16 installation zip: lineage-16.0-20190321-UNOFFICIAL-lilac.zip
Here are the results for lineage_lilac-eng build:
tried to boot recovery.img first, got hanging on twrp splash screen.
Installed the zip file via modpunk's twrp, tried to boot it, got a hanging black screen after SONY splash screen.
Flashed userdata from stock fw to do an erase: that made built twrp bootable and actually working - installed the built los16 zip just fine.
So this twrp is the only working thing for me so far. But it seems my built twrp is not that flexible as modpunk's as mine needed userdata erase to boot while modpunk's did not.
I tried to get some logs from main los16 boot, but logcat is not reachable. Have seen also the commit to redirect logcat into /cache for charging boot mode - tried that, but the log file was not created there.
The lineage_lilac-userdebug behaved similarly if I remember correctly (tried that build first), only twrp I could not boot as the userdata erase thing has been discovered with the -eng build. But re-tested that, it helped also with -userdebug twrp build, so both variants seem to behave the same.
The blobs from pie 8.24 vs pie 4.45 did not make a difference (after a quick rebuild followed the extraction).
In order to check my build environment, I tried similarly to build sony's aosp-9.0 - it also needed some fixes, but the result has been working (needed the special oem partition image flashed as described in sony's howto to make it boot - it would hang without it).
Attached result of following command (git added the new files first):
Code:
repo diff -u >my-changes.diff
Hopefully this helps anybody who likes to participate.
Thanks for any hints.

hi there,
yes those are the right branches you are using there. I was planning to PR some of the changes needed to build to the testing branches this weekend. I'll also look more closely at your patches, but from what I can tell you fixed the neverallow selinux issues - great!
the main issue right now is still the init, I know of at least a couple of crucial things missing from stock (there is more than one fstab now, for example - this is not implemented yet), but I was waiting for modpunk to push his recent changes before working on it again. he also told me that he has some uncommitted stuff, but hasn't had the time yet to sort them out.
also, feel free to PR your patches to modpunk's git. any help is much appreciated!
edit: instead if re-adding the proprietary-files-rootfs.txt, you can just remove the references to it from extract-files.sh and setup-makefiles.sh

Related

[ROM]CM10.1[JB][4.2.2][Kernel 3.0][SGT7][P1000/N/L/C]OpenPDroid[20130913][RETIRED]

CM10.1 (Android Jellybean 4.2.2) build for the Samsung Galaxy Tab 7" P1000, P1000N, P1000L, P1000CDMA (P1000T and P1000R also?).
Kernels for p1 and p1ln included in the same automated ZIP. p1c has it's own separate ZIP.
This is an unofficial CyanogenMod ROM Based on the SGT7 repo (cdesai, sbradymobile and humberos) with optional OpenPDroid patches. Read on for details.
Here is @cdesai's original thread.
Alroger's downloads (info, tips and troubleshooting included) <<<============
Humberos's downloads (you can use my PDroid Patches with them).
[UPDATE 20130913] Kernel 3.0.94 v1.45 + TWRP! Friday the 13th update.
[UPDATE 20130810] Kernel 3.0.89 v1.38 + TWRP! Kernel updates! Better battery!
[UPDATE 20130802] Kernel 3.0.88 v1.35 + TWRP! Kernel updates! Better battery?
[UPDATE 20130730] Kernel 3.0.87 v1.34 + TWRP! VoicePlus (former Babel), updates. Anything interesting?
[UPDATE 20130715] Kernel 3.0.86 v1.33 + TWRP! UI, security and kernel updates. Lockscreen rotation. Anything interesting?
[UPDATE 20130705] HALO and Privacy Guard updates.
[UPDATE 20130625] HALO and Privacy Guard added!
[UPDATE 20130621] Kernel 3.0.83 v1.26 + TWRP! Anything interesting?
[UPDATE 20130614] Kernel 3.0.82 v1.24 + TWRP! Anything interesting?
[UPDATE 20130611] Kernel 3.0.81 v1.23 + TWRP! SystemUI Fullscreen fixed.
[UPDATE 20130610] Kernel 3.0.81 v1.23 + TWRP! TVout, hdmi, ext keyboard, orientation, systemui, updates, updates…
[UPDATE 20130604] Kernel 3.0.80 v1.18 + TWRP! CDMA fixes?
[UPDATE 20130602] Kernel 3.0.80 v1.16 updates, translations… You tell us!
[UPDATE 20130527] Kernel 3.0.80 v1.13 updates, wifi, bluetooth, translations… You tell us!
[UPDATE 20130520] Kernel 3.0.79 updates, CDMA, wifi, expanded desktop, headphone, translations… You tell us!
[UPDATE 20130516] USB Fixed.
[UPDATE 20130514] more kernel improvements, CDMA 3.0!
[UPDATE 20130512] Kernel 3.0.78 updates: sensors, video, battery... You tell us!
[UPDATE 20130510] Kernel 3.0.77 and little fixes. You tell us.
[UPDATE 20130508] p1 kernel fix? Kernel Flash ZIPs fixed.
[UPDATE 20130507] Just getting better and better...
[UPDATE 20130505] eMMC mount working. Bluetooth working.
[UPDATE 20130502] Kernel 3.0.76 by @humberos! eMMC working, charge working.
[UPDATE 20130429] Kernel 3.0.75 by @humberos! USB working.
[UPDATE 20130425] System UI / Settings updates. Kernel 3.0 by @humberos!
[UPDATE 20130405] System UI / Settings updates. PIE controls without limits. Thanks @sbradymobile.
[UPDATE 20130401] System UI, Settings, Kernel updates and official CDMA kernel. PDroid available separately now.
[UPDATE 20130328] System UI, Settings, Expanded desktop fixed. Official CDMA kernel? Serial USB fixes.
[UPDATE 20130325] Settings, hardware keys, BT fixes? GPS Fast? Quick launch shortcuts in PIE menu!
[UPDATE 20130315] Status bar icone size and flip settings.
[UPDATE 20130313] Status bar larger icon size for Tablet UI.
[UPDATE 20130312] Status bar settings fixed.
[UPDATE 20130310] CDMA build! jt1134's kernel... does it work? Tell me!
[UPDATE 20130309] humberos' kernel. BT working, ADB permission popup working.
[UPDATE 20130307] New build and PDroid patches. humberos kernel. BT working for audio, just like humberos' build.
[UPDATE 20130225] New build and PDroid patches. Android 4.2.2! No BT yet.
[UPDATE 20130204] New build and PDroid patches. Little updates, PDroid performance updates. No BT yet.
[UPDATE 20130122] New build and PDroid patches. OpenPDroid patched sucessfully... various updates. No BT yet.
[UPDATE 20130117] New build with PDroid patches and PDroidManager. Note: there was an error patching PDroid in SMSDispatcher.java, so something is doomed to not work right.
[UPDATE 20121228]New build from @humberos! Checkout his blog.
No PDroid yet...
[UPDATE 20121215] New build, @humberos kernel and rotation fixed.
[UPDATE 20121214] Nope, PDroid ZIP from Android 4.1.2 will NOT work on CM10.1.
[UPDATE: 20121212] The world is not over. Happy 12-12-12! Let's get to CM10.1.
For now you can try cdesai's and humberos' CM10.1. I'm starting a fresh compile...
PDroid Patches available separately as CwM Flash install.
NoMoarPowah! GalaxyTab stockblue theme available.
OBS: No need to restock if coming from CM10 or other MTD ROMs.
Easy restock from Gingerbread:
Flash full stock Gingerbread (with repartition).
Flash CM10.1 kernel using heimdall (check for your boot*.img inside ZIP).
Boot directly into CwM / TWRP Recovery, holding VolUp.
Flash CM10.1 ROM, PDroid Patches and GApps!
Cheers! Thanks everyone!
Screenshots:
==[SCREENSHOTS ro.sf.lcd_density=160]== landscape
{
"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"
}
==[SCREENSHOTS ro.sf.lcd_density=120]== landscape and Tablet UI + Nav Buttons
==[SCREENSHOTS ro.sf.lcd_density=120]== landscape and Phone UI + Nav Buttons to the left
Building CM10.1 + TWRP Android 4.2.2 successful!
New build will automatically detect your device (p1, p1l, p1n)! p1c builds separately.
Android 4.2.2 building fine with humberos' repos! CDMA building fine with official repo.
[UPDATE 20130802]
TWRP - Touch Recovery in place of CwM.
New roomservice-twrp.xml attached.
[UPDATE 20130510]
New Kernel 3.0, new manifest..
[UPDATE 20130405]
@jt1134 updated and recommended using the official CyanogenMod repo. His repo has a kernel that might not work, might be in testing and might not have radio (3G) capabilities.
New roomservice.xml attached.
[UPDATE 20130312]
Figured out better "manifest" ways to pull humberos' and jt1134's repos, for humberos' kernel, device and common projects and jt1134's device and kernel for CDMA tabs.
[UPDATE 20130307]
sgt7 repo corrected and with new build instructions. Thanks @sbradymobile!
Code:
mkdir ~/cm10.1-sgt7
cd ~/cm10.1-sgt7
repo init -u git://github.com/sgt7/android.git -b cm-10.1
repo sync
cd vendor/cm
./get-prebuilts
cd ../..
mkdir .repo/local_manifests
cp ~/yourdownloads/roomservice-twrp.xml .repo/local_manifests/roomservice.xml
roomservice-twrp.xml attached at the end of this post, it looks like this:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project name="humberos/proprietary_vendor_samsung" path="vendor/samsung" remote="github" revision="cm-10.1" />
<project name="humberos/android_kernel_samsung_aries" path="kernel/samsung/aries" remote="github" revision="cm-10.1" />
<project name="humberos/android_device_samsung_p1" path="device/samsung/p1" remote="github" revision="twrp"/>
<project name="humberos/android_device_samsung_p1c" path="device/samsung/p1c" remote="github" revision="twrp"/>
<project name="humberos/android_device_samsung_p1-common" path="device/samsung/p1-common" remote="github" revision="twrp"/>
<remove-project name="CyanogenMod/android_bootable_recovery" />
<project name="humberos/Team-Win-Recovery-Project" path="bootable/recovery" remote="github" revision="cm-10.1" />
</manifest>
Code:
repo sync
source build/envsetup.sh
breakfast p1 # for p1, p1l and p1n
breakfast p1c # for p1c (CDMA)
time make -j3 bacon # j3 is number of cores
Done for the sgt7 build, without PDroid.
Now for OpenPDroid
PDroid patch, after the first build:
Code:
cd $cmdir/build; patch -p1 < $cmdir/../OpenPDroidPatches-4.2.x/openpdroid_4.2_build.patch > $cmdir/../pdroid.log
cd $cmdir/libcore; patch -p1 < $cmdir/../OpenPDroidPatches-4.2.x/openpdroid_4.2_libcore.patch >> $cmdir/../pdroid.log
cd $cmdir/packages/apps/Mms; patch -p1 < $cmdir/../OpenPDroidPatches-4.2.x/openpdroid_4.2_Mms.patch >> $cmdir/../pdroid.log
cd $cmdir/frameworks/base; patch -p1 < $cmdir/../OpenPDroidPatches-4.2.x/openpdroid_4.2_frameworks_base.patch >> $cmdir/../pdroid.log
cd $cmdir/frameworks/opt/telephony; patch -p1 < $cmdir/../OpenPDroidPatches-4.2.x/openpdroid_4.2_frameworks_opt_telephony.patch >> $cmdir/../pdroid.log
cd $cmdir
Add to vendor/cm/config/common.mk, after the rsync PACKAGE: Better install PDroidManager from the Market.
Sources at
CyanogenMod repo: https://github.com/CyanogenMod
SGT7 repo: https://github.com/sgt7
Humberos Kernel: https://github.com/humberos
OpenPDroid Patches: https://github.com/OpenPDroid/OpenPDroidPatches
Cheers!
BUGs
BUGs? You tell me.
My build should have the same flaws as official CM nightlies, humberos and cdesai builds. Sometimes more, sometimes less.
CDMA users - if you want 3G, use kernel on page 149 -http://forum.xda-developers.com/showthread.php?p=42961558.
Test videos for HW codec: http://forum.xda-developers.com/showpost.php?p=25215203&postcount=805
Use these as reference, anything else might have encoding problems of its own. I use MX Player.
Reporting Bugs
Before reporting a bug, please make sure you are running as stock as possible. This means no custom kernel, no custom framework modification, etc. If you are using any of the above modifications, please flash the rom again to get rid of the modifications before reporting.
Please read the thread for known issues before reporting.
Grab a logcat right after the problem has occurred. ie: adb logcat > logcat.txt (from your PC)
(Please include at least a few pages of the log, not just the last few lines, unless you know what you're doing.)
Get kmsg also. ie: cat /proc/kmsg > /sdcard/kmsg.txt (inside your Tablet via adb shell)
Get dmesg also. ie: dmesg > /sdcard/dmesg.txt
If it is a random reboot, grab /proc/last_kmsg. ie: cat /proc/last_kmsg > /sdcard/last_kmsg.txt
(Do not bother getting a logcat unless you can get it just before the reboot. A logcat after a reboot is useless)
PLEASE USE PASTEBIN.ORG FOR COPY / PASTE, OR ATTACHMENT OF .TXT / .ZIP FILES.
PLEASE DO NOT COPY / PASTE LOGS INTO POSTS.
PLEASE DO NOT QUOTE LONG POSTS, QUOTE ONLY THE RELEVANT PART.
It's ok to paste short parts of the log using the CODE formatting.​
Remember to provide as much info as possible. The more info you provide, the more likely that the bug will be solved. The following is a useful format to follow.
Code:
What is your--
Tablet model:
Radio (baseband):
CM version:
CM Download url:
Gapps version:
Did you--
wipe:
restore with titanium backup:
reboot after having the issue:
Are you using--
a task killer:
a non-stock kernel:
CMSettings/Performance settings (other than stock):
other modifications:
Provide any additional information (observations/frequency of problem/last version it worked on/etc) as needed:
hey alroger, good to see you are already getting cm10.1 builds out for SGT7
sorry to jack your thread so early in the piece, but i noticed with your local_manifest that you are using nothing but humberos' kernel for your builds, are you releasing CDMA builds, and if so, have you had any good feedback with his kernel on CDMA tablets?
i ask this because i tried using his CDMA kernel a while back (ICS) on my AOKP SGT7 builds, but all the CDMA users i have come across said that it wouldn't work with his kernel (caused "encryption unsuccessful" errors and wouldn't actually allow users to get into a working system) - i ask this because i use his kernel sources for every other variant except CDMA at this time, but would love to use it for CDMA as well (jt1134's kernels are great, but id love to offer CDMA users the extra tweaks that humberos offers in his kernels).
if you haven't had any feedback then i might try building another kernel with his sources and see if my CDMA tester has any luck with getting it working with JB. if so, i will get back to you on how it shapes up, though it may take me a while as i am currently between internet connections at home due to moving so i cant upload / download very much at the moment - i am currently using my mobile to connect to the internet, and i have a 500mb download limt.
i may even possibly take a shot at getting it working myself, though i have little experience with kernels.
again, sorry to jack your thread for a slightly off topic question.
Like new humberos rom from 12.12.2012! No reboots since this morning. Smooth and nice features! But I had a system crash right now. Log is attached. I can see this at the log before restart:
[ 1522.094239] binder: 553:553 transaction failed 29189, size 92-0
[ 1533.097649] save exit: isCheckpointed 0
[ 1533.098315] save exit: isCheckpointed 0
[ 1533.188139] Restarting system.
Humberos is your fix for PARAM include?
What is your Tablet model: p1
Radio (baseband): jpz
CM version: 10.1
CM Download url: humberos.br
Gapps version: 30.11.2012 for 4.2
Did you wipe: cache and dalvik cache before flashing
restore with titanium backup: no
reboot after having the issue: no reboot, but restart
Are you using a task killer: no
a non-stock kernel: no
CMSettings/Performance settings (other than stock): no
other modifications: seeder apk
elvitas said:
Like new humberos rom from 12.12.2012! No reboots since this morning. Smooth and nice features! But I had a system crash right now. Log is attached. I can see this at the log before restart:
[ 1522.094239] binder: 553:553 transaction failed 29189, size 92-0
[ 1533.097649] save exit: isCheckpointed 0
[ 1533.098315] save exit: isCheckpointed 0
[ 1533.188139] Restarting system.
Humberos is your fix for PARAM include?
What is your Tablet model: p1
Radio (baseband): jpz
CM version: 10.1
CM Download url: humberos.br
Gapps version: 30.11.2012 for 4.2
Did you wipe: cache and dalvik cache before flashing
restore with titanium backup: no
reboot after having the issue: no reboot, but restart
Are you using a task killer: no
a non-stock kernel: no
CMSettings/Performance settings (other than stock): no
other modifications: seeder apk
Click to expand...
Click to collapse
I advise you to format /system partition before flash and don't use seeder APK at moment.
This error came from /drivers/staging/android .
Thanks!
Thanks alroger and Humberos
With todays HumberOS build i cannot mount the tab as USB storage (while booted - i do not talk about CWM). I see the two drives in windows explorer but get error message like removable drive without disc inserted. In the notification bar of the tab i see the messages for mount, unmount and sd scan changing all the time without any action from me. Something seems to go wrong there. Fast charge was deactivated before (did use it this morning and that one works).
Works
Mjoelnir77 said:
With todays HumberOS build i cannot mount the tab as USB storage (while booted - i do not talk about CWM). I see the two drives in windows explorer but get error message like removable drive without disc inserted. In the notification bar of the tab i see the messages for mount, unmount and sd scan changing all the time without any action from me. Something seems to go wrong there. Fast charge was deactivated before (did use it this morning and that one works).
Click to expand...
Click to collapse
It is working fine here!!
stimpz0r said:
hey alroger, good to see you are already getting cm10.1 builds out for SGT7
sorry to jack your thread so early in the piece, but i noticed with your local_manifest that you are using nothing but humberos' kernel for your builds, are you releasing CDMA builds, and if so, have you had any good feedback with his kernel on CDMA tablets?
i ask this because i tried using his CDMA kernel a while back (ICS) on my AOKP SGT7 builds, but all the CDMA users i have come across said that it wouldn't work with his kernel (caused "encryption unsuccessful" errors and wouldn't actually allow users to get into a working system) - i ask this because i use his kernel sources for every other variant except CDMA at this time, but would love to use it for CDMA as well (jt1134's kernels are great, but id love to offer CDMA users the extra tweaks that humberos offers in his kernels).
if you haven't had any feedback then i might try building another kernel with his sources and see if my CDMA tester has any luck with getting it working with JB. if so, i will get back to you on how it shapes up, though it may take me a while as i am currently between internet connections at home due to moving so i cant upload / download very much at the moment - i am currently using my mobile to connect to the internet, and i have a 500mb download limt.
i may even possibly take a shot at getting it working myself, though i have little experience with kernels.
again, sorry to jack your thread for a slightly off topic question.
Click to expand...
Click to collapse
I don't have any real cdma feedback. But I have hundreds of downloads, so I'm really curious. You or your tester can try the latest CM10 (4.1.2) from my blog, there's a small ZIP just for the kernel also.
Many thanks to cdesai, humberos, alroger, sbradymobile who keep our lovely P1 alive
When using tvout (cinch to samsung connector) the tv display is rotated 90 degrees to the left compared to tab display, regardless of orientation.
Can I directly revert back to 4.1.2 if I want ? Or will have to restock ?
Sent from my GT-P1000 using xda app-developers app
adi6262 said:
Can I directly revert back to 4.1.2 if I want ? Or will have to restock ?
Sent from my GT-P1000 using xda app-developers app
Click to expand...
Click to collapse
Sure you can. Just remember to flash the respective gapps too.
Orientation and lock screen without function at quick settings. Can someone confirm?
It will be nice if autocync will be include to quick settings...
One question off-topic: I can't see "wipe battery stats" at current cwm. How can I wipe it now?
elvitas said:
Orientation and lock screen without function at quick settings. Can someone confirm?
It will be nice if autocync will be include to quick settings...
One question off-topic: I can't see "wipe battery stats" at current cwm. How can I wipe it now?
Click to expand...
Click to collapse
Yes I can confirm on my P1000:
- that the Orientation Lock and
- Lock Screen
do not work in Quick Settings. Additionally the Orientation is always locked in Landscape mode.
elvitas said:
Orientation and lock screen without function at quick settings. Can someone confirm?
It will be nice if autocync will be include to quick settings...
One question off-topic: I can't see "wipe battery stats" at current cwm. How can I wipe it now?
Click to expand...
Click to collapse
Same here...
Can i updat to 4.2, form last 4.1, like i do with 4.1, only flash and wipe?
many thanks
elvitas said:
Orientation and lock screen without function at quick settings. Can someone confirm?
It will be nice if autocync will be include to quick settings...
One question off-topic: I can't see "wipe battery stats" at current cwm. How can I wipe it now?
Click to expand...
Click to collapse
Wiping Battery Stats isn't going to do any good.
It's just a myth.
anilspice said:
Yes I can confirm on my P1000:
- that the Orientation Lock and
- Lock Screen
do not work in Quick Settings. Additionally the Orientation is always locked in Landscape mode.
Click to expand...
Click to collapse
danielvieira said:
Same here...
Click to expand...
Click to collapse
Enable Auto-Rotation in Settings -> Accessibility until it's fixed.
jmpub said:
Can i updat to 4.2, form last 4.1, like i do with 4.1, only flash and wipe?
many thanks
Click to expand...
Click to collapse
No need to wipe data, but do backup, wipe only if you have issues.
Wiping /system is suggested though, wipe it and flash gapps again after flashing the ROM.
Hi,
tried humberos cm-10.1-20121212-HumberOS-p1.zip like described in Install (inclusive format system). Previous version was cdesai cm-10.1-20121206-EXPERIMENTAL-p1-cdesai.zip.
The boot process never find an end, after 25min i interrupted and shut down. Reboot gave the same behavior.
So i went the longer way wit overcome, full restocking. When i now install cm-10.1-20121212-HumberOS-p1.zip from CWM Recovery, reboot brings me back to recovery. Now i'm back to cdesai, with boots normal.
i installed gapps-jb-20121212-signed.zip with both version, works fine with cdesai
Any hint, why i can not boot the latest version?
Tnx, Cinq

Encryption on Android 5-based ROMs

(This should be a reply to @sddfdds and @ivzn on http://forum.xda-developers.com/showpost.php?p=63053041&postcount=3274, but this forum doesn't allow new members to post to "developer" subforums. If a moderator wants to merge the threads, please do!)
I've been trying to upgrade a Galaxy Nexus GSM (maguro) from CyanogenMod 11 to @Ziyan's CyanogenMod 12.1 builds, but before I can use CM12.1 as my daily-use ROM, I need to get device encryption to work. The symptom is that if I encrypt /data on CM11, then flash CM12.1 without wiping /data, the system fails to decrypt it during boot; or if I wipe /data, install CM12.1 (as a new installation or an upgrade), and then enable encryption, the system reports that encryption failed and recommends a factory reset.
Looking into this based on the hint from @ivzn's bisection, it seems that system/vold in Android ≥ 5.1 assumes features of the dm-crypt module that aren't supported by the 3.0-based kernel used on Galaxy Nexus. I suspect any 5.1-based ROM is going to have a similar issue: I've noticed that TWRP 2.8.7.0 also can't decrypt an encrypted /data, and I suspect this might be because it's also using a newer vold.
One way to resolve that would be to patch vold, as @ivzn suggested. The linked commit on Gerrit doesn't seem to be available any more, but the general idea seems to be something like this:
Code:
diff --git a/cryptfs.c b/cryptfs.c
index 880ac53..e1cdab7 100755
--- a/cryptfs.c
+++ b/cryptfs.c
@@ -1035,7 +1035,7 @@ static int load_crypto_mapping_table(struct crypt_mnt_ftr *crypt_ftr, unsigned c
#else
convert_key_to_hex_ascii(master_key, crypt_ftr->keysize, master_key_ascii);
#endif
- sprintf(crypt_params, "%s %s 0 %s 0 %s 0", crypt_ftr->crypto_type_name,
+ sprintf(crypt_params, "%s %s 0 %s 0 %s", crypt_ftr->crypto_type_name,
master_key_ascii, real_blk_name, extra_params);
SLOGI("%s: target_type = %s\n", __func__, tgt->target_type);
However, since vold is common to all devices, that comes with some risk of breaking unrelated devices; I can't be sure that there isn't some random device (perhaps with a modified dm-crypt for hardware-assisted crypto) where that trailing 0 is somehow important.
Another way to avoid that would be to patch the kernel to tolerate this extra "column", like it does in 3.4-based kernels. That's what I've suggested here:
http://review.cyanogenmod.org/#/c/110508/
https://github.com/smcv/android_kernel_samsung_tuna/commit/6407247d
and that does seem to work fine on my maguro. This has the advantage that it only affects the Galaxy Nexus (tuna) family of devices, so it's less likely to cause a regression.
I suspect that this is applicable to all 5.1-based ROMs for Galaxy Nexus. Similarly, if there are other devices that have a working Android-5.1-based ROM but are still stuck on a 3.0 kernel, they'd probably benefit from the same patch.
I hope this is useful to someone.
Hmm, well one oddity then, it does work in Zmod 5.1.1, which also has 3.0.101
sddfdds said:
Hmm, well one oddity then, it does work in Zmod 5.1.1, which also has 3.0.101
Click to expand...
Click to collapse
On closer examination, I could be wrong about the history; this might be CM-specific. The vold commit that breaks it is db2b1edd "vold: Adding support of Inline Crypto Engine (ICE)". I had thought that CM12.1's vold was pretty closely based on Android 5.1.1, but looking at the history in gitk, the feature was added on the cm-12.0-caf branch by codeaurora.org developers.
@Ziyann merged a cherry-pick of some changes from Linux 3.1, which are another way to fix this. A build from source according to http://forum.xda-developers.com/showpost.php?p=62230725&postcount=2 now has working encryption.
Any non-CyanogenMod ROMs that use the CAF branch of vold on Galaxy Nexus, and maintain their own kernels, should probably do the same: cherry-pick commits 498f0103ea13123e007660def9072a0b7dd1c599 and 772ae5f54d69c38a5e3c4352c5fdbdaff141af21.
Could someone please mention this as a reply to <http://forum.xda-developers.com/showpost.php?p=62554113&postcount=3140>? I can't post in that subforum (not enough post count yet).
another one [user space] way to fix encryption
Hello, @smcv.
Thank you for this sort of team work (it's great, actually) - kernel level information about dm layer is very interesting.
I guess I'm pretty late, however, I think that - nothing personal, only technical - it's pretty insane to fix user space code by backporting a part of dm in kernel space.
So here is my point of view to "fix" encryption in both cases at runtime from user space by patching vold itself (sorry for "encoded" links):
github / ia / android_system_vold - eaacaf37f3
review cyanogenmod org - 111160
Speaking about TWRP - I've got a patch for 2.8.7.0 to fix decryption (based on backported changes from 2.8.N.0) as well, but I need a couple of days to clean it up and to test a few things.
But if you use your dm patch, do you have any issues with decrypting data using "vanilla" build of TWRP 2.8.7.0 ?

[ROM][13.0][Daredevil] LineageOS 20.0 [UNOFFICIAL]

{
"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"
}
LineageOS for Nokia 7.2
About LineageOS
LineageOS is a free and open-source operating system for set-top boxes, smartphones and tablet computers, based on the Android mobile platform. It is the successor to the custom ROM CyanogenMod, from which it was forked in December 2016 when Cyanogen Inc. announced it was discontinuing development and shut down the infrastructure behind the project. Since Cyanogen Inc. retained the rights to the Cyanogen name, the project rebranded its fork as LineageOS.
LineageOS was officially launched on December 24, 2016, with the source code available on GitHub. Since that time, LineageOS development builds now cover more than 185 phone models with over 1.9 million active installs,having doubled its user base in the month February–March 2017 And if you would like to contribute to LineageOS, please visit out Gerrit Code Review.
Whats working?
Wi-Fi
RIL
Volte
Mobile data
GPS
Camera
Flashlight
Camcorder
Bluetooth
Fingerprint
FM radio
Sound
vibration
Bugs ?
Let me know if you see anything else. Especially please mention the issue and attach the logcat.
Installation process
Click Here for Installation process
Credits
* LineageOS Team for rom source
* Nokia for kernel source​
Download Rom
Download TWRP
Join Community Group
Android OS version: 13.0
Security patch level: 2023-01
Build author: Raghu varma
Kernel source code : android_kernel_nokia_LC-SDM660
Source code: https://github.com/LineageOS
Note - please take your data backup and do clean flash as per the instructions linked in the main thread. On top of it, my builds will boot on any stock firmware as base. So there is no special recommendation towards which stock rom you need to be on.
Changelog - Sun Jan 22 19:01:23 UTC 2023
============================
• Initial Android 13 build
• Based on android-13.0.0_r20
• Improved system stability
• User interface enhancements
• Google security patch 2023-01
• Selinux enforced
• Vendor built from Source
• Imported CTS profile patches
• Safety net pass by default & no need zygisk
• Updated build fingerprint from Pixel 7 Pro (cheetah)
Reminder - for reporting bugs please mention the issue and attach the logcat.
Thank you!
Awesome..!
Any chance it would run on Nokia 8.1 after unlocking/rooting with Hikari files ?
I'm mean ... someday / when updates are over .
Changelog Sat Apr 3 08:41:31 UTC 2020
===================================
1. Initial stable build
2. March security patch
3. Comes with stock kernel
4. Linux version 4.4.194
5. Vendor image from 2250
6. System blobs from 2250
7. Ota support available
Note- Installation process changed so please go ahead and follow the instructions as I mentioned in installation section
I tested now and I found Google Services - are GApps included? I installed lineageos in this build to AVOID this. Or did I make something wrong?
overclockA said:
I tested now and I found Google Services - are GApps included? I installed lineageos in this build to AVOID this. Or did I make something wrong?
Click to expand...
Click to collapse
Thanks, saved me some time. Defeats the entire purpose for me.
xe500linux said:
Thanks, saved me some time. Defeats the entire purpose for me.
Click to expand...
Click to collapse
I wrote to Raghu varma for the same question.
Technically it seems to not be that simple - if lineage 17.1 has been compiled without gapps and the build process was done by using private keys, flashing gapps would brick the device or the lineageos installation.
So Raghu varma compiled the version with gapps included to avoid this.
So I took his scripts from github and I built lineageos 17.1 on my own (with private keys and without gapps as I don't think about flashing them afterwards) - this worked fine.
Now I couldn't find his scripts for Daredevil on his github profile anymore - maybe they will come back for the 7.2 build process.
overclockA said:
I wrote to Raghu varma for the same question.
Technically it seems to not be that simple - if lineage 17.1 has been compiled without gapps and the build process was done by using private keys, flashing gapps would brick the device or the lineageos installation.
So Raghu varma compiled the version with gapps included to avoid this.
So I took his scripts from github and I built lineageos 17.1 on my own (with private keys and without gapps as I don't think about flashing them afterwards) - this worked fine.
Now I couldn't find his scripts for Daredevil on his github profile anymore - maybe they will come back for the 7.2 build process.
Click to expand...
Click to collapse
Ah I see. Any chance you still have a copy of your non-g build?
xe500linux said:
Ah I see. Any chance you still have a copy of your non-g build?
Click to expand...
Click to collapse
This should be OK. I'll upload a copy and send a link.
Be aware that the security patch level is dated on march 2020 and doesn't include the latest Google security patches from june.
overclockA said:
This should be OK. I'll upload a copy and send a link.
Be aware that the security patch level is dated on march 2020 and doesn't include the latest Google security patches from june.
Click to expand...
Click to collapse
Much appreciated!!
i posted already in the twrp thread of my problem "touch not working with twrp", that's still persisting.
so i got another idea. i used adb commands to control twrp. like you know, adb shell twrp sideload and then do the adb sideload commands for installing lineageos 17.1.
what did i do so far is:
*flash twrp 3.4.0
*boot up to twrp 3.4.0
*use adb shell twrp remountrw
*use adb to sideload lineageos 17.1 zipfile with commands (adb shell twrp sideload and then adb sideload lineageos.zip) - but the progress bar only goes to 47% and say like it would have "finished" - i dont believe in it
*use adb to sideload vendor zipfile zipfile with commands (adb shell twrp sideload and then adb sideload vendor.zip) - that one works normally
*changed slot from B (i was on before) to A on fastboot and flashed the vbmeta to current slot (A)
*reboot without wiping system partition and installing lineageos only brings up normal stock rom
*even wiped system partition one time (or should i say system_root?) - and installed lineageOS via adb sideload. but nothing was in the system_root folder as i mounted it back again
*wiping system partition and reboot only brings up android one loading screen endlessly
so basically, the installer says it has installed the rom, but in reality it didnt seem to touch the system partition at all. am i doing something wrong or may it be that because i dont have touch access i miss to move some unlock slider which is not implemented via adb shell twrp? i think something along these lines might be the case but.. i was able to adb shell twrp wipe system. so basically it should not be a big deal to write to system partition or system_root in general.
oh and of accusation that the adb sideload probably doesnt send data correctly (from which i heard lots of stories of the past), i even pushed the zip file via adb push to / and installed it with adb shell twrp install /lineageos.zip. same result.
what i would really like to see is an debug log of the installer zip. you only see "part 1 and part 2" installing and percentage, but no informations what the installer is doing currently. this would help a lot if there would be a switch for the installer like "verbose information"
edit again.
I finally managed to do the install. You know what? it is possible without the touch gui. what i did was:
*reflashed via fastboot the stock rom
*booted normally, installed the latest upgrade (Stock ROM OTA - took a long while) - (may be obsolete)
*booted to fastboot, flashed newest twrp to boot
*booted to recovery
*adb shell twrp remountrw
*adb shell twrp remountrw (the /tmp/recovery.log showed interestingly at first remountrw the page set of readonly, at second time not - why?)
*adb shell
*entered in adb shell mount /system
*adb shell twrp wipe data
*adb push lineageos.zip /data/
*adb shell twrp install /data/lineageos.zip
*adb push ddv.zip /data/
*adb shell twrp install /data/ddv.zip
*adb shell getprop ro.boot.slot_suffix (to get the actual boot slot)
*adb reboot bootloader
*fastboot --set-active=_a (for me i was on b before, so i needed to go to a)
*fastboot flash vbmeta_a --disable-verity --disable-verification vbmeta.img
*fastboot reboot
*then the phone - now on lineage - asked me to factory reset, i did
*booted finally successfully up to lineage 17.1 - wlan, mobile network working just fine
if you want gapps on it, install them ideally direct after your custom rom is able to boot. in my case gps didnt worked with gapps and other apps till i did another factory reset. and the original launcher that comes with the cust-rom doesnt work anymore after installing the gapps. use the pixel launcher instead. after that, it works like a charme
in conclusion: a bit odd how the install not works as in the description was told. maybe the TA-1196 is just a bit different.
Hello Together,
i've installed LineageOs yesterday and i realy like it . I just can't find an camera App that supports the wideAngle Camera at the back.
Open Camera only recognizes 2 Cameras, and GCam 7.0 Nokia 7.2 Mod can't seem to access it either.
Is there a solution to this?
Best regards
Alex
Changelog Fri Nov 13 23:24:47 IST 2020
==============================
- based on latest lineage sources
- November 2020 security patch
- fixed bluetooth audio
- fixed mic
- fixed RIL
- fixed headset
- based on android 10 prebuilt vendor for now ( DDV2.340 )
- Comes with stock kernel
- linux version 4.4.192
- compiled using gcc
- fixed battery drain
- fixed styles and wallpapers
- selinux enforced
- banking apps working
- use NikGapps
Got brand new nokia 7.2 yesterday, developer loaded old android build 1_130 and unlocked bootloader, didnt recommend twrp as this wol break wi-fi. Can I flash this OS on my phone directly without twrp ? will wifi and camera work as it should? Sorry for the questions I am new here and just started reading this Thank you
Nokia is nowadays very slow in giving security patch updates to its devices. Its a high time we switch to custom rom..?
I'm waiting for my phone's warranty to get over. Anyways, do anyone have any eta on when this rom will get official?
I have managed finally to install it, but sorry, nothing mentioned work: no double tapp sleep or wake up, no fingerprint, no slinux enforced, camera is not worth to mention at all and i still didnt test bluetooth or microphones yet. ..
dariuslapsys said:
I have managed finally to install it, but sorry, nothing mentioned work: no double tapp sleep or wake up, no fingerprint, no slinux enforced, camera is not worth to mention at all and i still didnt test bluetooth or microphones yet. ..
Click to expand...
Click to collapse
I agree for tapp to wake up and selinux.
Nevertheless, bluetooth and microphones and fingerprint sensors are working like a charm.
NFC is not mentioned anywhere, but I don't need this function at all.
I installed the build from 14/11.
@Raghu varma: Can we help you out sending logfiles for some issues? Do you need testers?
Raghu varma said:
Note - Iam Not Responsible for bricked devices
About LineageOS
LineageOS is a free and open-source operating system for set-top boxes, smartphones and tablet computers, based on the Android mobile platform. It is the successor to the custom ROM CyanogenMod, from which it was forked in December 2016 when Cyanogen Inc. announced it was discontinuing development and shut down the infrastructure behind the project. Since Cyanogen Inc. retained the rights to the Cyanogen name, the project rebranded its fork as LineageOS.
LineageOS was officially launched on December 24, 2016, with the source code available on GitHub. Since that time, LineageOS development builds now cover more than 185 phone models with over 1.9 million active installs,having doubled its user base in the month February–March 2017 And if you would like to contribute to LineageOS, please visit out Gerrit Code Review.
Installation procedure
Note - I don't recommend you people to flash any other custom kernels on this ROM untill Nokia release kernel sources. Because this ROM supports only stock kernel .
1. Download Rom.zip , twrp.img & vbmeta.img
2. power off your phone boot in to bootloader mode and flash twrp
3. Boot in to Twrp
4. Format data by typing yes
5. Wipe everything
6. Flash rom.zip & vendor.zip
7. Now tap on reboot and check your current active slot.
Example - if twrp shows current active slot A change to B if B change to A
8. Tap on reboot and tap on bootloader ( this will reboots your phone to bootloder mode )
9. Now open cmd in pc flash vbmeta using this command
for slot-a > fastboot flash vbmeta_a --disable-verity --disable-verification vbmeta.img
for slot-b> fastboot flash vbmeta_b --disable-verity --disable-verification vbmeta.img
( thanks to @singhnsk for this step )
10. now type fastboot reboot
and wait for 3 min rom will boot up
Credits
* LineageOS & CO (For Source Code)
* All the authors in my git sources
* Nokia For Prebuilt Vendor & Kernel Source
* Moderators (For Giving Freedom To Post Threads)
* My entire Nokia 7.2 community Thank you all for your massive support Again
​Join Nokia 7.2 Community​
​
Download Rom
Download Vendor
Download vbmeta
Download GApps
Download Official Twrp
Android OS version: 11.0.0_r17
Security patch level: November 2020
Build author: Raghu varma
My build script: https://github.com/RaghuVarma331/scripts
Kernel Source code: https://github.com/RaghuVarma331/android_kernel_nokia_sdm660
Source code: https://github.com/LineageOS
Click to expand...
Click to collapse
When i install this rom volte function not proper working outgoing not work incoming volte works reply what is this
When i install this rom volte function not proper working outgoing not work incoming volte works reply what is this

[H932] (CAF) Kernel Development Notes

(I'd love to post this in the dev section, but seeing as I've always been an XDA downloader I don't have the post count. )
What I've gathered around the 'net is that there isn't really a good place to get started with development on Android kernels when presented with an OEM source zip drop. This "guide" if you can call it that is nothing more than my musings in stumbling through the kernel dev learning process. My goal is to get both me and maybe you from "ok, I can download source" to doing some basic kernel tasks.
My LG V20 gave up the ghost, but to my surprise my insurance didn't deliver a replacement h918, but instead a T-Mobile LG V30 H932. That messed my restore plans up a good deal. Upon perusing the XDA forums I'm seeing that this model isn't popular with developers. This walkthrough is written with its current latest firmware release in mind, 30d. I won't be updating this guide for newer firmwares as I feel I've documented my process -extremely- thoroughly. If they do miraculously release another update be assured that it'll eventually be in my git's commits.
The first thing I'll note is that this is my first foray into Android kernel development. I've been a Linux sysadmin for 13 years though, so most of my solutions to problems are going to come from that realm rather than Android development. I've been hacking phones using the great releases on XDA since my UTStarcom XV6800 running Windows Mobile 6. It's time to give back.
The second note is that while I tried to keep this guide as generic as possible, that's an impossible task because the process itself is intrinsically tied to what device you're doing this for. I concede 100% that these are the dev notes on my work towards better h932 ROMs w/VoLTE and VoWiFi. If you're working with something else you can follow the same process but change some names around. If your image isn't CAF based, the process is the same except utilizing whatever repository your manufacturer started with.
My last note is that I will not be doing this process on other device kernels unless they're supportable by my base work. The H932 is unloved enough.
------------------------------------------​GETTING STARTED
Start from a Linux host of your choosing. I'll be doing this from Arch Linux. Make sure your basic build tools are installed and you've got lots of disk space (and free time :\ ).
Get the 30d source through your browser: (apparently I can't post links yet- you're gonna have to Google for now)
Inside the file you download from LG will be another compressed tarball named "LGH932SV_Kernel_Pie.tar.gz". This is where the stock kernel source is stored. Keep this file handy as we'll need to extract the stock kernel's contents a few times.
Alright. We have kernel source and the means to build it. Is that all we can do though? Surely LG didn't just magic this whole platform together. They probably started from an upstream base. The most widely used base for starting development on a Snapdragon device would be the Code Aurora (REALLY missing the links) repo. Just by coincidince CAF contains a branch named "msm-4.4", exactly the same as our stock release's kernel folder. It's likely they started here. But where?
CAF uses some extremely hideous tags to mark their releases. I haven't deciphered the full meaning from the CAF tag strings themselves yet but they do correspond to commits in their git repository. That's good enough for us to start guessing at stuff!
(If you're doing this for the H932 30d release, you can skip CAF-dentification and go straight to "Your Kernel Repo". I already have the magic answers for 30d.)
CAF-DENTIFICATION
Modified instructions from:
abhishekan - can't post links yet. To be filled. :\
Click to expand...
Click to collapse
Only necessary if you don't know your base - I already did this for our example.
LG H932 release 30d script results:
Code:
Best match
TAG: LA.UM.7.4.r1-03500-8x98.0
Lines changed: 1174716
That's a LOT of changes! I hope it's not too bad to sort through...
Click to expand...
Click to collapse
Extract your stock kernel sources (located within LGH932SV_Kernel_Pie.tar.gz in the file you download from LG) and go into the msm-4.4 directory via bash terminal.
Code:
cd msm-4.4
Initialize this folder as a git repo
Code:
git init
Add all the stock kernel files into git's tracking and make your initial commit
Code:
git add .
git commit -m "LG V30 30d Stock Open Source Files - (link removed)"
Add the CAF upstream repo for our kernel (msm-4.4)
Code:
git remote add msm https://source.codeaurora.org/quic/la/kernel/msm-4.4
Fetch all their tags (this will take some time/~3.3GB folder size after this command)
Code:
git fetch msm 'refs/tags/*:refs/tags/*'
Download the best-caf-kernel python script to identify which version CAF LG based the image from
Code:
wget https://raw.githubusercontent.com/LineageOS/scripts/master/best-caf-kernel/best-caf-kernel.py
Set it executable
Code:
chmod 755 best-caf-kernel.py
Search through the msm-8998 builds to see which one is most similar
Code:
./best-caf-kernel.py "*-8x98.0"
This command will take a long while to complete because it's checking each release individually and comparing how much of the source code differs. The least changed kernel represents our best chance to merge LG's changes back into a CAF release as a patch.
Again, the secret answer for the H932 30d kernel is: LA.UM.7.4.r1-03500-8x98.0
LG more than likely started from this base for their 30d release and implemented their custom kernel changes atop LA.UM.7.4.r1-03500-8x98.0. Had they released a repository instead of a bespoke zip we wouldn't have to do all this guesswork. We could just review the commit history and see where the two projects match up.
It's never the easy way...
START YOUR KERNEL REPO
Go ahead and delete the msm-4.4 directory you made before (if you did the CAF-dentification step). We'll start fresh here and explain some of the more common git commands as we go. I know some will not be familiar with git so these examples in motion may help.
Go home (or some place with a lot of storage) and make a directory to store your nascent kernel repository.
Code:
cd ~
mkdir -p ./kernel/msm-4.4/
cd ./kernel/msm-4.4/
Initialize this folder as a git repo
Code:
git init
Start by making a master branch we'll use for our "good" code. We have to add a file to start the master branch so just drop a description of what we're coding here.
Code:
echo "# Custom kernel source repo for the LG V30 H932.
" > caffy.readme
git add .
git commit -m "initial commit"
You can see that the master branch was automatically created via the commit:
Code:
git branch -a
Before we move on we should enable a git feature called rerere, short for "Reuse recorded resolution of conflicted merges". This comes in insanely handy in the advanced steps later because it will record how you resolve git conflicts when merging branches. If you merge that code again into a similar branch, git will already know how to automagically fix most of the conflicting issues.
In fact, it's so useful, I recommend enabling it globally. Use branches people!
Code:
git config --global rerere.enabled 1
For now add a staging branch that we'll test our code updates in. This will come into play later.
Code:
git branch staging
Tracking every change we make and the differences between versions is going to play a VERY vital role in maintaining your kernel source. We'll make heavy use of branches to make merging differences easier later.
Add a third branch that will contain the stock LG H932 30d source files.
Code:
git branch LG.H932.30d_stock
Note that you weren't automatically placed in the LG.H932.30d_stock branch. If you do another "git branch -a" you'll see master is still selected. Switch!
Code:
git checkout LG.H932.30d_stock
Extract the file "LGH932SV_Kernel_Pie.tar.gz" from the source you downloaded from LG. Now open that compressed tarball to reveal a ./kernel/ folder. This is your actual kernel source code. Extract their ./kernel/ into your ./kernel/.
Now that the files are in place there are a couple small changes that need to be made to the original source so git can catalog it correctly. Looks like LG missed a few files that changed between software versions behind the scenes (for other devices - just know it may not compile as delivered and you'll have to dig).
Make sure you're back in the msm-4.4 folder before running these commands.
Code:
echo '!vmlinux.scr' >> ./arch/sh/boot/.gitignore
sed -i '/*.pdf/d' ./Documentation/DocBook/.gitignore
rm ./.get_maintainer.ignore
Update our readme breadcrumb with this branch's details. Personal notes will save you eternal frustration down the road when things are much more complicated.
Code:
echo "# This source tree represents the latest LG V30 H932 kernel, version 30d.
#
# Find the original release at:
# (link temporarily removed)
" > caffy.readme
Once all that is in place, add the files into your repo and make a commit for this branch, noting the changes you made from master.
Code:
git add .
git commit -m "Clean version of the LG V30 H932 stock kernel (release 30d)"
You can verify your changes by checking your git logs, which will report your commit history on your selected branch.
Code:
git log
Your two commit messages should be visible in the log.
Switch back to the master branch so we can add s'more kernel branches.
Code:
git checkout master
Note that the directory cleared out again after checking out the master branch. All we have now is our readme file from our initial commit and the .git directory itself (which you should RARELY modify directly).
Now we'll make a new branch to host our stock kernel's closest CAF cousin. Finding out what your CAF tag is can be its own adventure. Normally here is where you have to do the CAF-dentification step (you can refer to that section above). Since this is an example I'll cheat and tell you the closest CAF tag for the H932 30d image: LA.UM.7.4.r1-03500-8x98.0.
Code:
git branch LA.UM.7.4.r1-03500-8x98.0
git checkout LA.UM.7.4.r1-03500-8x98.0
Update our breadcrumb with how we got to this point, just in case someone pulls this code and for some reason and blows the .git dir away.
Code:
echo "# This source tree represents the original "LA.UM.7.4.r1-03500-8x98.0" CAF release.
#
# Find the full original repo at:
# https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
" > caffy.readme
Add the CAF upstream repo for our kernel (msm-4.4 I'm guesing, since the LG kernel is delivered in a folder named that)
Code:
git remote add msm https://source.codeaurora.org/quic/la/kernel/msm-4.4
Grab the most similar version to your CAF as identified by the best-caf-kernel.py script. This is "git fetch" followed by your CAF repo (msm-4.4 here) then the CAF tag.
Code:
git fetch msm LA.UM.7.4.r1-03500-8x98.0
Merge this fetched code into our branch, ignoring that it has no common "history" (commits) with our readme-only-containing branch.
Code:
git merge --allow-unrelated-histories FETCH_HEAD
(Optional sanity check) You can verify that we're using Qualcomm's code now because we have the commit logs available (unlike with the LG releases). The git log will show you looooooots of dev notes.
Code:
git log
Now we have two branches with kernel source code, one of which we suspect is a modified version of the other. Without LG's git history to detail what they changed and where, we're going to have to reconcile the differences ourselves. That sounds easy... right? Wait, did you do the CAF-dentification step? ...remember "Lines changed: 1174716"?
In theory this would be simple and software would note all the changes automagically, sort them, and generate a pretty list. In practice it never works that way.
Here's the basic intro to get you started down the path... Be aware that git merge conflict resolution could be a masters level class depending on what you're starting from and where you're trying to go.
Switch back to your empty staging branch
Code:
git checkout staging
Pull the code from our CAF branch into our staging branch
Code:
git merge LA.UM.7.4.r1-03500-8x98.0
Update your breadcrumb for what's about to come...
Code:
echo "# This source tree represents the "LA.UM.7.4.r1-03500-8x98.0" CAF release,
# with the LG customizations added on top of the standard release code.
#
# Find the full original repos at:
# https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
# (apparently CAF links are fine but LGE opensource links are NOT ok)
" > caffy.readme
Now do basically the same process for the H932 30d kernel files. This will result in A LOT of conflicts because LG added a lot of drivers/fixes.
Code:
git merge LG.H932.30d_stock
Merging these modifications is a process that is kinda outside of the scope of an "introductory" document. My first attempt on this step took almost a full day of verifying file contents and locations. Even after all that I had to go back and find some missed changes between the two versions manually. Kernel modding is not for the faint of heart. I'm still figuring parts of it out!
"git mergetool" is a good place to start your web searches. meld is a graphical tool you can install on Linux hosts to allow merging between LOCAL, BASE, and REMOTE concurrently via GUI.
This step is where the real art comes in, it seems.
Code:
git mergetool -t meld
ANYWAYS, once that whole mess is sorted, you may or may not have a functional stock kernel merged with its closest CAF relative. Preserve your work by adding and committing.
Code:
git add .
git commit -m "CAF release tag: LA.UM.7.4.r1-03500-8x98.0 + LG H932 30d kernel source merged.
LG's kernel release finally gets an upstream commit history. >:D"
Since this was such a huge merge I like to park it in (you guessed it) another branch for posterity. Issue these commands to copy our staging work elsewhere.
Code:
git branch LA.UM.7.4.r1-03500-8x98.0+H932.30d
At this point you've tracked down where LG started with their kernel source, rebuilt the commit history they started with, and created a patch delta between what Qualcomm handed LG and the 30d image that LG eventually shipped. Very nice!
How do we know it works, though? Maybe we fudged one of the merges up and completely disabled a piece of hardware. Maybe there's no sound. The ONLY way to know the final outcome is to compile, flash, and test. If you weren't "an artist" in the previous step this can be a long repetitive slog.
Some notes to help you diagnose stuff: If you know your 30d kernel compiles and works fine on your phone, but your merged CAF tag + 30d release does not, it must be a difference somewhere between the two sets of files. I had missed a few files the first time around which resulted in a ton of build errors in the final stage. I was able to track this down because most of the errors were "net" related, so I started my search for differences in that directory.
Code:
git diff HEAD LG.H932.30d_stock -- ./net/*
git checkout LG.H932.30d_stock -- ./net/Makefile
git checkout LG.H932.30d_stock -- ./net/core/dev.c
git checkout LG.H932.30d_stock -- ./net/core/sock.c
You can go down every directory similarly and VERY SLOWLY verify that you've copied the changes 100%. If you haven't noticed by now this process is a labor of love. Continue until it compiles. Flash. Test. Verify. Progress!
COMPILE KERNEL
If you've followed this guide top to bottom as written, we may be a bit ahead of ourselves. I recommend trying the following steps on the 30d stock files FIRST, and then once you're sure of your methods on the original files you can try your hand at compiling your merged CAF tagged version. This helps isolate issues between your process and your code.
Switch back over to the pristine stock branch.
Code:
git checkout LG.H932.30d_stock
Unless you're doing this from a 64-bit Raspberry Pi (AND 64-bit OS!) or similar platform you'll need to grab the cross-compile toolchain for arm64 (here called aarch64) from Google. There's a slight problem with using the latest release though. Commit fc97ce6abfe822403eb219dcbd1067a53c49e4f1 removed the GCC compiler completely!
Checking back through the git log we can see where they've made changes to GCC, so let's roll back to a version more suitable for our platform. I found the last commit that contains GCC before they started introducing the deprication warnings - 22f053ccdfd0d73aafcceff3419a5fe3c01e878b. We'll leave the msm-4.4 directory first so this toolchain isn't downloaded into our code.
Code:
cd ../..
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
cd aarch64-linux-android-4.9
git checkout 22f053ccdfd0d73aafcceff3419a5fe3c01e878b
git reset --hard HEAD
You can verify that we have gcc again by checking the ./bin/ directory here.
Code:
ls -lah ./bin | grep gcc
While we're here we need to set some environment variables so the compiler will know to use this location. You'll have to redo this from this directory any time you close your shell (in this case, the terminal probably), if you want to recompile the kernel.
Code:
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-android-
export ARCH=arm64 && export SUBARCH=arm64
Head back into the msm-4.4 directory for punishment time.
Code:
cd ../kernel/msm-4.4
This next part I'm pretty sure is not the correct way to perform it. I'm not a C developer - just a sysadmin - so I've worked out a way to get it running at least. Yes, this does mean that the code is no longer pristine. Someone let me know how to get the stock code compiling without modification. Click the button below for my steps that are -extremely- specific to the h932 30d image.
In ./Makefile, Remove the gcc-wrapper script from the equation. All it does is stop the build on warnings. Google made a similar change with their commit e7fb62baa7c8b803d7e3b3f3d8bf4e2b916b659d. Change this line:
Code:
REAL_CC = $(CROSS_COMPILE)gcc
to this:
Code:
CC = $(CROSS_COMPILE)gcc
And remove this line:
Code:
CC = $(srctree)/scripts/gcc-wrapper.py $(REAL_CC)
-OR- if you really like stopping on compiler warnings, you need to make the wrapper executable.
Code:
chmod 755 ./scripts/gcc-wrapper.py
Note that this wrapper breaks newer GCC toolchains so it's advised you choose to remove it.
./arch/arm64/kernel/vdso/gen_vdso_offsets.sh has incorrect permissions. It needs to be executable.
Code:
chmod 755 ./arch/arm64/kernel/vdso/gen_vdso_offsets.sh
You're going to need to apply a Linux kernel commit from 4.4.218 (commit ce513359d8507123e63f34b56e67ad558074be22) to prevent compile errors about "multiple definition of `yylloc'". Remove the line "YYLTYPE yylloc;" (or in later versions "extern YYLTYPE yylloc;") from two files:
Code:
# ./scripts/dtc/dtc-lexer.l
# ./scripts/dtc/dtc-lexer.lex.c_shipped
Go into the ./arch/arm64/boot/dts/ directory. Delete the qcom file and make it a link instead. This fixes a missing file error that msm8998-joan_tmo_us_rev-0.dts otherwise runs into.
Code:
cd arch/arm64/boot/dts/
rm qcom
ln -s ../../../../arch/arm/boot/dts/qcom qcom
cd ../../../..
Go into the ./include/uapi/linux/ directory. We're going to delete some files and link them instead. This fixes ambiguous errors like: "../include/uapi/linux/oneshot_sync.h:1:1: error: expected identifier or '(' before '.' token". It's LITERALLY parsing the link in the file. Make it a link instead.
Code:
cd ./include/uapi/linux/
rm oneshot_sync.h
ln -s ../../../drivers/staging/android/uapi/oneshot_sync.h oneshot_sync.h
rm sync.h
ln -s ../../../drivers/staging/android/uapi/sync.h sync.h
cd ../../..
Edit the #include statements in ./arch/arm/boot/dts/qcom/msm8998.dtsi to point to the current file locations. Leave the first #include alone! Change the other three to:
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/regulator/qcom,rpm-smd-regulator.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Another #include needs to be fixed in ./include/dt-bindings/interrupt-controller/arm-gic.h
Code:
#include "irq.h"
Two #includes in ./arch/arm/boot/dts/qcom/msm-pmi8998.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
#include <../../../../../include/dt-bindings/spmi/spmi.h>
The same thing in reverse on ./arch/arm/boot/dts/qcom/msm-pm8005.dtsi
Code:
#include <../../../../../include/dt-bindings/spmi/spmi.h>
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
Some common culprits over in ./arch/arm/boot/dts/qcom/msm8998-regulator.dtsi
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
ANOTHER set of #includes in ./arch/arm/boot/dts/qcom/msm-pm8998.dtsi
Code:
#include <../../../../../include/dt-bindings/spmi/spmi.h>
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
#include <../../../../../include/dt-bindings/msm/power-on.h>
One in the similarly namned ./arch/arm/boot/dts/qcom/msm8998-pm.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Seeing a pattern yet? The include directory must be defined in something I've missed. Another over in ./arch/arm/boot/dts/qcom/msm-arm-smmu-8998.dtsi
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Moar. ./arch/arm/boot/dts/qcom/msm8998-vidc.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
Moar. ./arch/arm/boot/dts/qcom/msm8998-bus.dtsi
Code:
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
Moar. ./arch/arm/boot/dts/qcom/msm-smb138x.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
Moar. ./arch/arm64/boot/dts/lge/msm8998-joan/msm8998-joan_tmo_us/msm8998-joan_tmo_us.dtsi
Only the first #include on this file needs to be changed.
Code:
#include <../../../../include/dt-bindings/interrupt-controller/irq.h>
Locate the devconfig file you'd like to use for your device under the directory ./arch/arm64/configs/.
Code:
ls -lah ./arch/arm64/configs/
The closest in my instance will be the "joan_tmo_us-perf_defconfig" file. Joan is the codename for the LG V30, T-Mobile's my carrier, US is my country, and while using the stock ROM the uname -r command returns "4.4.153-perf+" so I assume they used the perf config. The defconfig will instruct the compiler what options to include in the kernel. We're going with the LG stock options to start with.
Make a few directories for the clean/mrproper scripts. The build process throws some (harmless) errors otherwise.
Code:
mkdir -p out/drivers/staging/qcacld-3.0
mkdir -p out/drivers/staging/qca-wifi-host-cmn
mkdir -p out/arch/arm64/boot/dts
Now run through the make steps. Clean, prepare the environment, prep the make with your devconfig, then run the actual make specifying that it use all the cores your PC has to speed things up. You can change that to a manually specified number like 3 cores if you're using the PC for other stuff with "-j3".
Code:
make O=./out clean
make O=./out mrproper
make O=./out joan_tmo_us-perf_defconfig
make O=./out KERNEL_COMPRESSION_SUFFIX=gz -j$(nproc)
Your kernel should compile successfully and output the file "./out/arch/arm64/boot/Image.gz-dtb". AnyKernel3 will need this so your kernel can be included in the installer.
PACKAGE & FLASH KERNEL
Download the latest AnyKernel3. Make sure you're not in your kernel directory.
Code:
cd ~
wget https://github.com/osm0sis/AnyKernel3/archive/master.zip
Unzip the archive and go into the AnyKernel3 directory.
Code:
unzip master.zip
cd AnyKernel3-master
Place your Image.gz-dtb file into the AnyKernel3-master folder.
Edit the anykernel.sh file, it comes pre-populated with demo values. Copy my example below for the V30 and feel free to change kernel.string (make sure not to use a ' though). If you aren't using a V30 and therefore not making a Joan kernel, change the device.name1 and block lines for your device. You can either pull the values from another kernel for your device, or boot into TWRP or similar, go to the terminal, and try a find /dev/block -name boot to see if you can garnish any clues as to where your real boot is. Some devices just hard specify this under /fstab.${devicecodename} - ours is at /fstab.joan but has no /boot/.
Code:
# AnyKernel3 Ramdisk Mod Script
# osm0sis @ xda-developers
## AnyKernel setup
# begin properties
properties() { '
kernel.string=CAF Test Kernel
do.devicecheck=1
do.modules=0
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=joan
'; } # end properties
# shell variables
block=/dev/block/bootdevice/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
## AnyKernel methods (DO NOT CHANGE)
# import patching functions/variables - see for reference
. tools/ak3-core.sh;
## AnyKernel install
dump_boot;
write_boot;
## end install
Finally, pack up the entire folder.
Code:
zip -r9 UPDATE-AnyKernel3.zip * -x .git README.md *placeholder
You've created your first kernel release! Most XDA users would know what to do with this file at this point. Remember that if you're using a Pie release like we are that not all versions of TWRP support the newer standard of encryption. I'm using 3.3.1 personally.
That first flash is perilous. You'll swear it's the slowest your phone has ever booted and there's no way this could be working. Patience. If it doesn't work and you have no access to another kernel for your device you'll have to reflash a working image, find out what you did wrong, fix it, and try again.
Once you have a known working kernel the other flashes are much less risky - if it doesn't work, just go back into TWRP and flash the working one.
SWITCHING TOOLCHAINS
Switching between Google Android 4.9 builds
I've pulled some of the commits from the aarch64-linux-android-4.9 git logs which correlate to when they introduced new build versions. Might help someone track down an errant compiler issue or two.
Code:
93092903254cba0b6950c94170332973a85b450f - final gcc build 5790414 + very long delays added to dissuade use
22f053ccdfd0d73aafcceff3419a5fe3c01e878b - build 4983606 - last version before warnings
e7c51da4d09616dcff4a9d0f1190c3403079c462 - build 4682334
ce9d77505072450d2f16a4bf06673f31d8d67ff0 - build 3335333
2d6950d80de80ab7b1252816a2f543d07180deeb - build 2734602
d65210cccc244bf9a92a1ff56953314e9908e0fd - build 2617618
b5845835b5e6a5266c56d554c0c1f282d30f8c3f - build 2492827
8f7279e3d34a45f084fdb23bd434c01d5e598bf4 - they don't mention the builds this early
For anything older checkout this last commit and do: git log --grep 'prebuilts for aarch64'
You can change which gcc build your toolchain is on by going into your aarch64-linux-android-4.9 directory and performing the following commands, making sure to replace the commit with the one reflecting the build you'd like.
git checkout 22f053ccdfd0d73aafcceff3419a5fe3c01e878b
git reset --hard HEAD
Switching to Alternatives
From what I understand reading around XDA, it's best practice to try to compile your kernel with Google's aarch64-linux-android-4.9 toolchain first to make sure that nothing's wrong with it. Relative to the Linux community however, Google has been extremely conservative with its toolchain. If you're looking to bleed every last drop of performance out of your platform you should try a few different toolchains and see which one results in code that's most efficient for your workflow.
There are LOTS of toolchains out there. XDA has entire threads on dedicated to this topic. On Linux your distribution also probably bundles a premade toolchain for aarch64, Arch Linux is currently on GCC 10 (aarch64-linux-gnu-gcc)!
I'm going to focus on a popular performance-focused toolchain here, Linaro. They produce an aarch64 toolchain for most of the GCC release versions with enhancements specific to ARM based targets. Their latest release as of this writing is 7.5.0.
Go back to your home directory and download the aarch64-7.5.0 release of Linaro, then unpack.
Code:
cd ~
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
tar -xf gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
Now, whenever you want to compile your kernel following the steps in this guide, you'll go into this directory instead of your previous aarch64-linux-android-4.9 one. Then you'll need to set your CROSS_COMPILE variable a different string which corresponds to Linaro 7.5.0's file structure.
Code:
cd gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-gnu-
I've tested this on my LA.UM.7.4.r1-03500-8x98.0+H932.30d and it completes albeit with a few warnings. Coding standards and compilers evolve as time moves on and code that isn't maintained can find itself stranded with the ancients - these warnings are to help developers work in the right direction so that doesn't happen to their projects.
To that end, to actually compile a functional kernel using a GCC 7.x+ toolchain there's a flag that needs to be added to your ./Makefile: "-fno-store-merging". I found this tidbit over at https://github.com/nathanchance/angler/commit/406d54a7f006142372157d4fb49d7e76a5564d00
Add the following at line 634 in ./Makefile:
Code:
# Needed to unbreak GCC 7.x and above
KBUILD_CFLAGS += $(call cc-option,-fno-store-merging,)
UPDATE CAF
Repeating history isn't what we came for though. From our CAF base the fun begins. We didn't do all that work to end up with a stock image! The entire reason to figure out what CAF we started with is so we could change it. Now that we have a kernel with the CAF commit history, as we download newer CAF bases, we'll simply reapply the same commits that they did to update our kernel's base.
We're going to download the latest CAF base image for our hardware. Go to the codeaurora.org page for your device's source tags. Search for your chip (here 8x98 referring to the msm8998 aka Snapdragon 835) and find a similar build string to your identified one.
For the H932 this page would be: https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
In this instance, 30d identified closest as "LA.UM.7.4.r1-03500-8x98.0 ", so I'm looking for a "LA.UM.7.4.r1" release for the "8x98.0" architecture.
Just a heads up - I'm not sure if this is right! There are much newer msm8998 releases listed, such as "LA.UM.8.4.r1-05500-8x98.0". I've yet to experiment with these to see if they are of value to us. I went with the "most similar looking" to get my feet wet with the process.
Code:
git fetch https://source.codeaurora.org/quic/la/kernel/msm-4.4.git LA.UM.7.4.r1-06000-8x98.0
Go back to master since it's our only clean branch. Then make a home for our selected CAF release. Then switch to using it.
Code:
git checkout master
git branch LA.UM.7.4.r1-06000-8x98.0
git checkout LA.UM.7.4.r1-06000-8x98.0
Do the same process we did to import the original CAF's code. We already set the LA.UM.7.4.r1-06000-8x98.0 commit as our FETCH_HEAD earlier.
Code:
git merge --allow-unrelated-histories FETCH_HEAD
Head back to staging. It currently has a copy of the LA.UM.7.4.r1-03500-8x98.0+H932.30d branch's code.
Code:
git checkout staging
Now merge the changes from 06000 into our 03500 base.
Code:
git merge LA.UM.7.4.r1-06000-8x98.0
Notice how this produces A TON fewer conflicts than our original go around. Also, rerere has captured how we modified some of the files when we added 30d into the CAF branch so it has a basic concept of what we're trying to achieve, and makes some of these for us automagically. The day is saved!
Break out your git mergetool of choice again and get to work.
Code:
git mergetool -t meld
Then add and commit your changes.
Code:
git add .
git commit -m "LA.UM.7.4.r1-06000-8x98.0 + LG H932 30d kernel source merged"
You also need to update some tertiary CAF drivers like qcalcd-3.0. You may need to check the CAF repo to make sure you've nabbed all that apply. I'm going to assume you can merge a repo at this point.
qcacld:
Code:
git remote add qcacld https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0
git fetch qcacld LA.UM.7.4.r1-06000-8x98.0
fw-api:
Code:
git remote add fw-api https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/fw-api
git fetch fw-api LA.UM.7.4.r1-06000-8x98.0
qca-wifi-host-cmn:
Code:
git remote add qca-wifi-host-cmn https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qca-wifi-host-cmn
git fetch qca-wifi-host-cmn LA.UM.7.4.r1-06000-8x98.0
If your image compiled /before/ adding the CAF drivers but didn't compile /after/, check that your config flags are up to date before changing code around. qcacld-3.0 threw some errors for me in the upgrade from 3500 to 6000 unless I /also/ enabled WLAN_TX_FLOW_CONTROL_V2 in the defconfig, then reverted some of LGE's older custom patches (check OEM patches before modifying CAF code!).
The easiest way to poke around at flags is by doing a menuconfig after you run your "make O=./out joan_tmo_us-perf_defconfig" equivalent.
Code:
make O=./out menuconfig
UPDATE LINUX
Coming soon. Still ascertaining the easiest process. Git merge sounds like an obvious choice.
<reserved>
When you get enough posts we can request a Mod move it to Development section. Thank you for your efforts in developing the V30 more.
ChazzMatt said:
When you get enough posts we can request a Mod move it to Development section. Thank you for your efforts in developing the V30 more.
Click to expand...
Click to collapse
My only other post was apparently waaay back in 2009 about my HTC Touch Pro 2. I'm hoping I can bounce off of questions on this thread and hit 10 posts relatively quickly. And thank you! Without all the work the community had done already I wouldn't be this far along.
I've found the flag to allow the latest GCC 10.1 to compile now. Looks like it became a lot more picky in version 9 and the qcacld-3.0 build fails a buffer paranoia check.
Wow, very impressive write-up. Thanks a lot for sharing it.
I spent quite some time studying parts of the H932 kernel (and other models too) to better understand how the QuadDAC is implemented (es9218p codec). But my background is almost the opposite of yours: I was a prolific assembly language and C programmer back in the days, but have almost zero Unix/Linux experience. I would never be able to build the kernel, not even with your guide, so I couldn't make any changes to the codec, as much as I wanted.
Anyways, great contribution to the community. Thanks again!
TheDannemand said:
I spent quite some time studying parts of the H932 kernel (and other models too) to better understand how the QuadDAC is implemented (es9218p codec). But my background is almost the opposite of yours: I was a prolific assembly language and C programmer back in the days, but have almost zero Unix/Linux experience. I would never be able to build the kernel, not even with your guide, so I couldn't make any changes to the codec, as much as I wanted.
Anyways, great contribution to the community. Thanks again!
Click to expand...
Click to collapse
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
I know a few other languages like Java and Python; I never had a reason to get my hands dirty with good ol' C until now. The syntax makes sense to me but I don't always have an underlying knowledge of the big picture. I won't be making my own kernel patches, instead pulling in known working code from newer sources.
CAF tag 6000 is running albeit with some obvious errors in the dmesg log. All the hardware seems to be working fine. I've had one soft reboot in 24 hours so it's getting to a point where I'll be able to release my source code/alpha build. I'm resisting the urge to name it "30e" to avoid confusion with official updates.
Caffination said:
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
Click to expand...
Click to collapse
I'm sure you saw these other V30 custom kernel stuff:
https://github.com/zachariasmaladroit/kernel_lge_msm8998
Haumea kernel is the one I hear most about on Telegram group.
Of course compatibility is concern because T-Mobile H932 has different RSA encryption but maybe there's something there to give you ideas.
Caffination said:
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
Click to expand...
Click to collapse
Thank you for the offer. It's over a year ago I looked at V30 kernels, and unfortunately that window has since closed for me. For one thing, I no longer have H932 (now on US998). But also, I lost much of my hearing to a nerve disease, so my interest in the QuadDAC is now purely academic.
Once again, I love your project and spirit, and much look forward to your postings around here.
TheDannemand said:
But also, I lost much of my hearing to a nerve disease, so my interest in the QuadDAC is now purely academic.
Click to expand...
Click to collapse
Very sorry to hear that.
ChazzMatt said:
Very sorry to hear that.
Click to expand...
Click to collapse
Thank you, buddy. Yeah it sucks.

[ROM][11][UNOFFICIAL] AICP 16.1 UNNOFICIAL FOR MOTO ONE (DEEN)

{
"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"
}
AICP
Android Ice Cold Project
AICP is known by everyone as the "Ice Cold Project" that started on a Desire HD years ago (2012) and since then has evolved into a mature ROM with the BEST community that you can find!!!
Until Android Lollipop, the ROM has always been based on AOKP. Unfortunately, since AOKP stopped development (but made a comeback later), we changed our base to CM.
With the re-brand of CM to LineageOS (LOS), we became LineageOS based with some tweaks from AOSP and then changed to be based on the "Ground Zero Open Source Project" (GZOSP) for Android Pie.
We changed again for Android Q-R with a base of AOSP repositories and some additions from LineageOS for device-specific repositories.
If there are any bugs we will sort them out if it concerns our codebase. This ROM isn't LineageOS supported, so there is no need to report errors/bugs to them!!
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications and if
* you point the finger at us for messing up your device, we will laugh at you. Hard & a lot.
*
*/
Feature list (rough overview)
In the beginning, we would like to thank:
GZOSP team
LineageOS & CM (R.I.P.) team
@maxwen and the rest of the OmniRom team
DU team
Resurrection Remix team
AOSiP team
Community
@LorD ClockaN
@eyosen
@semdoc
@SpiritCroc
@wartomato
@Miccia
plus the rest of the crazy bunch that we call "team"
We are paying for servers that build weeklies and everything that comes with this, so EVERY DONATION will really be appreciated and be used to cover those expenses.
Thank you!!
Latest Stable Release Version 16.1
Download link: https://sourceforge.net/projects/moto-one-deen/files/AICP-11/
Please note that official builds will be deleted from our servers every month due to maintenance services.
Starting with AICP 15 we will be storing a copy of the most recent release here: https://media.aicp-rom.com/vault/.
Full Changelog link: https://dwnld.aicp-rom.com/
(Just click the changelog button next to the download link in the list of builds available for your device)
Google Apps:
We recommend MindTheGapps as it has been thoroughly tested and it works well with the ROM, some other minimal (and others) GApps packages could have issues, so try using MindTheGapps if you have any issues with other GApps packages
MindTheGapps: https://androidfilehost.com/?w=files&flid=322935
Mirror: http://downloads.codefi.re/jdcteam/javelinanddart/gapps
You tell...
FAQ:
Before using the ROM:
Q. Can I have an ETA for the next build?
A. Yes, just look here to see what day your device is built on.
Q. Does this ROM support custom kernels officially?
A. No. You can still use them, but the discussion should go in the thread of the respective kernel. We don't offer support for bugs you might encounter while using them!
Q. Does this ROM include GApps or do I have to flash them separately?
A. No, we do not include prebuilt GApps, because of possible licensing issues with Google Software and because some users do not want GApps preinstalled as they want to use alternative services like MicroG or just prefer flashing a GApps "flavor" of their liking.
Q. Does this ROM use the camera or gallery app from stock?
A. It depends on the device. In most cases, these apps include proprietary libs/code and cannot be included in the device trees on GitHub or we risk having the ROM banned from GitHub. In this case, we might try to make them installable (separate from the ROM zip), or we might provide a version of these apps with the ROM that doesn't include any proprietary libs. It's also sometimes the case that these apps are simply not included because we didn't feel the need to do so for the device in question.
Q. Does this ROM have Extended/Scrolling screenshot?
A. No, extended screenshot was implemented using an app extracted and modified from manufacturer firmware/system images and is proprietary as well. It led to the closing of many ROM's sources on GitHub.
Q. Does this ROM have FaceUnlock?
A. No, FaceUnlock was also an app extracted and modified from some manufacturers. Even Google removed the Trusted Face (FaceUnlock) feature for security reasons on Android 9.0/10.x. Adding the modified feature did the same to ROM sources as described above.
Q. Can you add (insert favorite weather provider)?
A. No, we cannot add more weather providers as the implementations change and we (the ROM) now have to pay for most services, and that is not cheap, so we decided to use the best free service that we could find, the only way to add your own is for users to apply for their own API key to use their preferred service.
Q. Does this ROM have private official builds with the above proprietary libs included?
A. No, we believe in open source software, this way users know what's in the build and can replicate it themselves, all official builds are built on our build servers using the public sources from GitHub, and no one can (or would) add their own private sources to the build.
Flashing the ROM:
Q. What do I need to know before flashing?
A. Check the flashing instructions...
Q. Can the builds be dirty flashed over each other?
A. Yes, this is how users can/should install updates most of the time, this can be done with the built-in updater service or with a custom recovery.
Q. How do I 'dirty flash' builds?
A 1. For "A only" devices: Wipe the System, Cache, and ART/Dalvik cache. Flash the ROM, GApps (only needed if you wipe the system), your preferred root solution, and reboot. Or just use the OTA app to perform that task for you.
A 2. For "A/B" devices": Wipe the ART/Dalvik cache. Flash the ROM, reboot to the recovery, flash GApps, your preferred root solution, and reboot. Or just use the OTA app to perform that task for you.
Q. How do I flash kernel builds?
A1. If it's a .img file, boot into TWRP and go to the install page in TWRP, in the bottom right corner select "install image", select the desired kernel, then select "boot" as the destination, then swipe to flash, then go back to the install screen and install your root method again, if you don't want to lose root and reboot.
A2. If it's a flashable ZIP, you can flash it together with a ROM update or separately. Go to the install page in TWRP, choose the kernel zip (or add it to the flash queue right after the ROM zip). Then add your root method to the queue if you don't want to lose root. Now swipe to flash and reboot afterward.
Using the ROM:
Q. Do I need to provide a logcat if I'm reporting a bug?
A. If you want it to be fixed faster (or at all) then yes, you should definitely provide a logcat AND the model name. (Note: Please just link the logcat from your GDrive, Dropbox, etc. Do not post the content here. Thanks.)
Q. How do I get a logcat, what type should I get, and more questions that can conveniently be answered by my pre-determined answer?
A1. Read this thoroughly. Also, here's a good app for getting logs: https://play.google.com/store/apps/details?id=com.tortel.syslog (Root needed).
A2. If you are already rooted, you can use the built-in feature to make a logcat and provide that. Just look into the others section on the AICP Extras main page.
The ROM should contain everything you need to enjoy Android R. You don't need to install any Add-ons, simply download the latest ROM and GApps, then follow the flashing instructions and go!
If you want the device to run the ROM "rooted", you can flash a root solution of your choice after the ROM zip file.
It is STRONGLY recommended to fully wipe your device before flashing and please avoid restoring system apps and system data with Titanium Backup (or with any backup/restore app) as this can cause stability issues that are very hard to debug, restoring regular apps is fine though.
If you believe you know what you're doing - then fine, go ahead, but please don't complain if you experience any strange behavior.
How to flash for the first time:
(Again: Don't do it if you don't know!)
1. Download the ROM and GApps and transfer them to your device.
2. Boot to recovery (TWRP is recommended, the lineage recovery is a great alternative however, it will not decrypt the internal storage so you will have to flash the rom with adb sideload or usb OTG or with an external sdcard).
3. Wipe the System (DO NOT WIPE THE SYSTEM ON A/B DEVICES!), Cache, and Data (you might need to format the data partition!).
4. Flash the ROM zip file (reboot to recovery before flashing anything else if you have an "A/B" device).
5. Flash the GApps (optional, needed for e.g. Google Playstore to work)
6. Reboot and set up your device.
7. You can then reboot to recovery and flash the root solution of your choice if you want to, and then boot back to the system.
The procedure may vary from device to device and is a bit different on system updates!
The ROM has GApps persistence in between dirty flashes, so you only have to flash them once! This might differ on A/B Devices.
Currently supported Root Solution:
Magisk stable
Magisk versions >= 20.4 don't usually need to be flashed on every dirty flash.
Depending on the device, you may need to flash it every time, unless your maintainer says otherwise, you should be fine.
If you want to contribute to AICP, or if you want to see what is being worked on/merged, feel free to visit our Gerrit code review system. (Link is at the bottom!!!)
Kernel source:
https://github.com/jro1979oliver/kernel_motorola_deenDevice tree source:
GitHub - jro1979oliver/device_motorola_deen
Contribute to jro1979oliver/device_motorola_deen development by creating an account on GitHub.
github.com
Vendor source:
GitHub - jro1979oliver/aicp_vendor_motorola
Contribute to jro1979oliver/aicp_vendor_motorola development by creating an account on GitHub.
github.com
Follow this guide if you want to extract the vendor blobs
ROM & Additional links:
AICP's Homepage
AICP Gerrit Code Review
AICP sources on GitHub
AICP Download page for official builds and media content
AICP Discord Community
AICP Telegram channel for server notifications on official builds
Contributors:
Information:
ROM OS Version: 11.x
Kernel: 3.18.140
ROM Last stock Rom required:
Status: STABLE
Release Date: 05-31-2022
You want to see a "normal" night at the "DEV office", click here!!​
Q&A:
1: It's stable?
Yes, it's currently running with selinux enforcing and no major bugs
2: Can I use encryption?
Yes, it's not enforced by default because twrp still can't decrypt, but if you prefer you can do it via settings
3: From where I can find a twrp for first install?
From here. NOTICE: Aicp also ships it's own recovery and it is functional. Besides extreme stable, deen kernel still has a bug where when you are on slot a, recovery can't switch to slot b by it's own, so you need to use fastboot --set-active=b with latest adb tools from google (Download).
From b to a, you can just reboot system. At first install, I recommend a format data to fix selinux contexts that twrp may bork and avoid storage issues
AICP 16.1 (android 11)
Moto One deen
Changelog:
June security patch
Signed build;
Enabled verity checks; added the hability to lock bootloader (do it at your own risk -
fastboot flashing lock and fastboot flashing unlock (this kill your data as stock does));
Added Dolby (settings/sound/dolby atmos);
Working usb internet tethering,
Selinux enforcing;
Reworked paddings;
Enabled proccess reclaim;
Gesture navigation as default;
Enabled LiveDisplay (again)
Bugs:
*
Currently, recovery can't change slot from a to b;
You tell me
May be few more changes idk
https://sourceforge.net/projects/moto-one-deen/files/AICP-11/aicp_deen-16.1_signed.zip/download
I've been away from the xda community for a while and got a Motorola One XT-1941-3 (retail from Brazil).
Is this AICP the most stable custom rom available?
Thanks!
jeferson1979 said:
AICP 16.1 (android 11)
Moto One deen
Changelog:
June security patch
Signed build;
Enabled verity checks; added the hability to lock bootloader (do it at your own risk -
fastboot flashing lock and fastboot flashing unlock (this kill your data as stock does));
Added Dolby (settings/sound/dolby atmos);
Working usb internet tethering,
Selinux enforcing;
Reworked paddings;
Enabled proccess reclaim;
Gesture navigation as default;
Enabled LiveDisplay (again)
Bugs:
*
Currently, recovery can't change slot from a to b;
You tell me
May be few more changes idk
https://sourceforge.net/projects/moto-one-deen/files/AICP-11/aicp_deen-16.1_signed.zip/download
Click to expand...
Click to collapse
Bro have Deen too?
zahidm said:
Bro have Deen too?
Click to expand...
Click to collapse
Yeah, more one moto
jeferson1979 said:
Q&A:
1: It's stable?
Yes, it's currently running with selinux enforcing and no major bugs
...
Click to expand...
Click to collapse
This is a very nice rom and gives more life to my moto one.
However, I'm trying to build it locally and having some issues with the manifest.
Do you mind sharing your manifest for the rom?
Thank you.
I'm trying to rebuild your rom locally with your repositories. Maybe I don't use the correct manifest, and I'm getting selinux policy violation.
Code:
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=11
AICP_VERSION=aicp_deen_r-16.1-UNOFFICIAL-20220728
TARGET_PRODUCT=aicp_deen
TARGET_BUILD_VARIANT=user
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=generic
TARGET_2ND_ARCH=arm
TARGET_2ND_ARCH_VARIANT=armv8-a
TARGET_2ND_CPU_VARIANT=generic
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-5.15.39-1-pve-x86_64-Ubuntu-20.04.4-LTS
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
KERNEL_TOOLCHAIN=gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin
HOST_BUILD_TYPE=release
BUILD_ID=RQ3A.211001.001
OUT_DIR=out
PRODUCT_SOONG_NAMESPACES=vendor/motorola/deen device/motorola/deen hardware/qcom-caf/msm8996 vendor/qcom/opensource/data-ipa-cfg-mgr vendor/qcom/opensource/dataservices packages/apps/Bluetooth
============================================
wildcard(out/target/product/deen/clean_steps.mk) was changed, regenerating...
$(shell date +%H%M%S) was changed, regenerating...
[100% 26280/26280] writing build rules ...
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib/hw/audio.primary.msm8953.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib/hw/audio.primary.msm8953.so'
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib/libsensorndkbridge.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib/libsensorndkbridge.so'
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib/libtinycompress.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib/libtinycompress.so'
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib64/libsensorndkbridge.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib64/libsensorndkbridge.so'
[ 60% 26285/43481] build out/target/product/deen/obj/FAKE/sepolicy_tests_intermediates/sepolicy_tests
FAILED: out/target/product/deen/obj/FAKE/sepolicy_tests_intermediates/sepolicy_tests
/bin/bash -c "(out/host/linux-x86/bin/sepolicy_tests -l out/host/linux-x86/lib64/libsepolwrap.so -f out/target/product/deen/system/etc/selinux/plat_file_contexts -f out/target/product/deen/vendor/etc/selinux/vendor_file_contexts -f out/target/product/deen/system/system_ext/etc/selinux/system_ext_file_contexts -f out/target/product/deen/system/product/etc/selinux/product_file_contexts -p out/target/product/deen/obj/ETC/sepolicy_intermediates/sepolicy ) && (touch out/target/product/deen/obj/FAKE/sepolicy_tests_intermediates/sepolicy_tests )"
The following types on /system/ must be associated with the "system_file_type" attribute: clean_scratch_files_exec
12:07:01 ninja failed with: exit status 1
#### failed to build some targets (01:56 (mm:ss)) ####
My local manifest is as follows:
Code:
<manifest>
<remote name="kernel" fetch="https://github.com" revision="r11.1" />
<remote name="device" fetch="https://github.com" revision="r11.1" />
<remote name="vendor" fetch="https://github.com" revision="r11.1" />
<remote name="github_fetch" fetch="https://github.com/" revision="lineage-18.1" />
<project name="jro1979oliver/kernel_motorola_deen.git" path="kernel/motorola/deen" remote="kernel" />
<project name="jro1979oliver/device_motorola_deen.git" path="device/motorola/deen" remote="device" />
<project name="jro1979oliver/aicp_vendor_motorola.git" path="vendor/motorola" remote="vendor" />
<project path="external/bson" name="LineageOS/android_external_bson" remote="github_fetch" revision="lineage-18.1" />
<project path="hardware/motorola" name="LineageOS/android_hardware_motorola" remote="github_fetch" revision="lineage-18.1" />
<project path="system/qcom" name="LineageOS/android_system_qcom" remote="github_fetch" revision="lineage-18.1" />
</manifest>
Could you point me in the right direction? Is the manifest good or am I missing something?
Your help will be much appreciated.
Thanks.
xdadevc said:
I'm trying to rebuild your rom locally with your repositories. Maybe I don't use the correct manifest, and I'm getting selinux policy violation.
Code:
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=11
AICP_VERSION=aicp_deen_r-16.1-UNOFFICIAL-20220728
TARGET_PRODUCT=aicp_deen
TARGET_BUILD_VARIANT=user
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=generic
TARGET_2ND_ARCH=arm
TARGET_2ND_ARCH_VARIANT=armv8-a
TARGET_2ND_CPU_VARIANT=generic
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-5.15.39-1-pve-x86_64-Ubuntu-20.04.4-LTS
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
KERNEL_TOOLCHAIN=gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin
HOST_BUILD_TYPE=release
BUILD_ID=RQ3A.211001.001
OUT_DIR=out
PRODUCT_SOONG_NAMESPACES=vendor/motorola/deen device/motorola/deen hardware/qcom-caf/msm8996 vendor/qcom/opensource/data-ipa-cfg-mgr vendor/qcom/opensource/dataservices packages/apps/Bluetooth
============================================
wildcard(out/target/product/deen/clean_steps.mk) was changed, regenerating...
$(shell date +%H%M%S) was changed, regenerating...
[100% 26280/26280] writing build rules ...
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib/hw/audio.primary.msm8953.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib/hw/audio.primary.msm8953.so'
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib/libsensorndkbridge.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib/libsensorndkbridge.so'
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib/libtinycompress.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib/libtinycompress.so'
build/make/core/Makefile:49: warning: overriding commands for target `out/target/product/deen/vendor/lib64/libsensorndkbridge.so'
build/make/core/base_rules.mk:513: warning: ignoring old commands for target `out/target/product/deen/vendor/lib64/libsensorndkbridge.so'
[ 60% 26285/43481] build out/target/product/deen/obj/FAKE/sepolicy_tests_intermediates/sepolicy_tests
FAILED: out/target/product/deen/obj/FAKE/sepolicy_tests_intermediates/sepolicy_tests
/bin/bash -c "(out/host/linux-x86/bin/sepolicy_tests -l out/host/linux-x86/lib64/libsepolwrap.so -f out/target/product/deen/system/etc/selinux/plat_file_contexts -f out/target/product/deen/vendor/etc/selinux/vendor_file_contexts -f out/target/product/deen/system/system_ext/etc/selinux/system_ext_file_contexts -f out/target/product/deen/system/product/etc/selinux/product_file_contexts -p out/target/product/deen/obj/ETC/sepolicy_intermediates/sepolicy ) && (touch out/target/product/deen/obj/FAKE/sepolicy_tests_intermediates/sepolicy_tests )"
The following types on /system/ must be associated with the "system_file_type" attribute: clean_scratch_files_exec
12:07:01 ninja failed with: exit status 1
#### failed to build some targets (01:56 (mm:ss)) ####
My local manifest is as follows:
Code:
<manifest>
<remote name="kernel" fetch="https://github.com" revision="r11.1" />
<remote name="device" fetch="https://github.com" revision="r11.1" />
<remote name="vendor" fetch="https://github.com" revision="r11.1" />
<remote name="github_fetch" fetch="https://github.com/" revision="lineage-18.1" />
<project name="jro1979oliver/kernel_motorola_deen.git" path="kernel/motorola/deen" remote="kernel" />
<project name="jro1979oliver/device_motorola_deen.git" path="device/motorola/deen" remote="device" />
<project name="jro1979oliver/aicp_vendor_motorola.git" path="vendor/motorola" remote="vendor" />
<project path="external/bson" name="LineageOS/android_external_bson" remote="github_fetch" revision="lineage-18.1" />
<project path="hardware/motorola" name="LineageOS/android_hardware_motorola" remote="github_fetch" revision="lineage-18.1" />
<project path="system/qcom" name="LineageOS/android_system_qcom" remote="github_fetch" revision="lineage-18.1" />
</manifest>
Could you point me in the right direction? Is the manifest good or am I missing something?
Your help will be much appreciated.
Thanks.
Click to expand...
Click to collapse
Just revert this commit. Also, use this repo for hardware/motorola
I made some progress (thanks). There seems to be another selinux issue:
Code:
[ 4% 400/9625] build out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/treble_sepolicy_tests_26.0
FAILED: out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/treble_sepolicy_tests_26.0
/bin/bash -c "(out/host/linux-x86/bin/treble_sepolicy_tests -l out/host/linux-x86/lib64/libsepolwrap.so -f out/target/product/deen/system/etc/selinux/plat_file_contexts -f out/target/product/deen/vendor/etc/selinux/vendor_file_contexts -f out/target/product/deen/system/system_ext/etc/selinux/system_ext_file_contexts -f out/target/product/deen/system/product/etc/selinux/product_file_contexts -b out/target/product/deen/obj/ETC/built_plat_sepolicy_intermediates/built_plat_sepolicy -m out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/26.0_mapping.combined.cil -o out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/built_26.0_plat_sepolicy -p out/target/product/deen/obj/ETC/sepolicy_intermediates/sepolicy -u out/target/product/deen/obj/ETC/built_plat_sepolicy_intermediates/base_plat_pub_policy.cil ) && (touch out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/treble_sepolicy_tests_26.0 )"
SELinux: The following domains violate the Treble ban against use of the binder_in_vendor_violators attribute: mm-qcamerad
14:04:29 ninja failed with: exit status 1
Looking at the sepolicy/vendor/mm-qcamerad.te file I see:
Code:
# TODO(b/36599434): Remove this once mm-qcamerad stops using Binder services
typeattribute mm-qcamerad binder_in_vendor_violators;
allow mm-qcamerad binder_device:chr_file { read write };
What would be the proper fix here? (sorry if I bother you, I understand I'm way out of my league).
xdadevc said:
I made some progress (thanks). There seems to be another selinux issue:
Code:
[ 4% 400/9625] build out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/treble_sepolicy_tests_26.0
FAILED: out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/treble_sepolicy_tests_26.0
/bin/bash -c "(out/host/linux-x86/bin/treble_sepolicy_tests -l out/host/linux-x86/lib64/libsepolwrap.so -f out/target/product/deen/system/etc/selinux/plat_file_contexts -f out/target/product/deen/vendor/etc/selinux/vendor_file_contexts -f out/target/product/deen/system/system_ext/etc/selinux/system_ext_file_contexts -f out/target/product/deen/system/product/etc/selinux/product_file_contexts -b out/target/product/deen/obj/ETC/built_plat_sepolicy_intermediates/built_plat_sepolicy -m out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/26.0_mapping.combined.cil -o out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/built_26.0_plat_sepolicy -p out/target/product/deen/obj/ETC/sepolicy_intermediates/sepolicy -u out/target/product/deen/obj/ETC/built_plat_sepolicy_intermediates/base_plat_pub_policy.cil ) && (touch out/target/product/deen/obj/FAKE/treble_sepolicy_tests_26.0_intermediates/treble_sepolicy_tests_26.0 )"
SELinux: The following domains violate the Treble ban against use of the binder_in_vendor_violators attribute: mm-qcamerad
14:04:29 ninja failed with: exit status 1
Looking at the sepolicy/vendor/mm-qcamerad.te file I see:
Code:
# TODO(b/36599434): Remove this once mm-qcamerad stops using Binder services
typeattribute mm-qcamerad binder_in_vendor_violators;
allow mm-qcamerad binder_device:chr_file { read write };
What would be the proper fix here? (sorry if I bother you, I understand I'm way out of my league).
Click to expand...
Click to collapse
Remove typeattribute mm-qcamerad binder_in_vendor_violators;
jeferson1979 said:
Remove typeattribute mm-qcamerad binder_in_vendor_violators;
Click to expand...
Click to collapse
This fixed the compile problem. Thank you so much. I've been struggling with compiling an updated aicp for deen for two whole days.
I had a few other issues with a modified api, hence my delay, but I was able to compile, and flash the moto one. It seems to work. No boot loops
I ended up with a few gapps installed in the system (youtube, photos, maps) but there was no google services. This is weird. Why did those apps get included in the first place and how do I remove them?
xdadevc said:
This fixed the compile problem. Thank you so much. I've been struggling with compiling an updated aicp for deen for two whole days.
I had a few other issues with a modified api, hence my delay, but I was able to compile, and flash the moto one. It seems to work. No boot loops
I ended up with a few gapps installed in the system (youtube, photos, maps) but there was no google services. This is weird. Why did those apps get included in the first place and how do I remove them?
Click to expand...
Click to collapse
You may want to use my TWRP with oem wipe option built in, this gapps are coming from stock installation
jeferson1979 said:
You may want to use my TWRP with oem wipe option built in, this gapps are coming from stock installation
Click to expand...
Click to collapse
Formatting the oem partition made them disappear. Most/all things seem to work, including all the hardware. I'm going trough your github commit history. You did quite a bit of work there over the last few months. Impressive. Thank you again !
I see on aicp page that there is latest version 17.1. I think this is android 12 aicp_deen_s-17.1-WEEKLY-20220713.zip
https://sourceforge.net/projects/moto-one-deen/files/latest/download
Someone have tested this version on our moto?
Ok,
jeferson1979 said:
You may want to use my TWRP with oem wipe option built in, this gapps are coming from stock installation
Click to expand...
Click to collapse
I was trying to sign my build and I made something stupid and hard-bricked my xt1941-3 deen.
I have fastboot. fastboot devices shows something but there is no partition table. No A/B slots and no imei/baseband or any other thing. The serial number changed as well. It's still seend as a "deen" product with variant 000000000000000
In linux the phone is recognized as
Bus 001 Device 055: ID 22b8:2e80 Motorola PCS Fastboot deen S
Blankflash will not work in either linux or windows. It waits for the device (I quess the qualcomm flashing device) which is not there.
Is there a way out?
PS: What I did was I flashed the A slot with my boot/system/vendor.img. Then erased the B slot partitions, then booted into TWRP, activated the B slot and flashed the signed ota update, thinking that it would go to the A slot. In the middle of the flash, my phone rebooted and I got a faled boot, no gpt.bin etc.
xdadevc said:
Is there a way out?
Click to expand...
Click to collapse
So, I managed to get my bootloader back. The issue with a partial bootloader was that it was not accepting the blankflash command. No QCOM serial inteface etc.
I found out that "fastboot oem blankflash" will put the bootloader into blankflash mode, and pull up the serial interface. However there's a timing issue. blankflash must start almost immediately after going into this mode. To same me the hassle I made a small script:
Code:
#!/bin/bash
fastboot oem blankflash
for i in `seq 1 1000` ; do
./qboot blank-flash --debug=4 $*
done
Now this is sub-optimal, but worked first time for me. Just power on the phone, wait for the bootloader to come up, then start the script. It will require a ctrl-c after the phone reboots into fastboot again, this time with a proper partition table, imei, gpt etc all working.
Back to business. I'm trying to sign AICP with my own keys, then enable AVB verifier and relock the bootloader. Perhaps blankflash can be used to actually flash my own boot in place of the motorola one?
For now I'm trying to understand how to exactly sign the image with my keys. Then how to enable AVB.
PS: The "blankflash" command from fastboot oem disappeared as soon as I had a working gpt. I guess it's a failsafe. Trying to put it again into blankflash mode resulted in an error. YMMV
Hi, it's been a long weekend here. I'm up and running now. ROM compiles and works nicely. I have one residual issue when updating from a build generated by me. The recovery accepts it (keys verify) but fails at the last stage (3/3) after updating some of the partitions. After this the moto will not boot any more and requires a full image file upload. Not sure why this is and if it's only on my own phone.
But overall, things look nice. Great job @jeferson1979 and for the help in setting this up.
There's an issue with TWRP 3.6.9. I tried to use it to make a nandroid backup of a running AICP (test keys) and I skipped the data partition. The backup seemed properly done (no errors).
However, rebooting the phone never gets past the initial bootloader screen. This is only after making a backup, no restore.
I tried restoring the boot image, then system and it failed with an error. Second thing I tried was flashing my current build of AICP (different keys that original). Booting works, but decoding the data (which is encrypted) resulted in an error. The message says "password is correct, but the data is corrupt and cannot be decoded". This is weird because it says the same even with a totally bogus password.
So, seems that booting in TWRP will damage the data partition. Is this due to the different selinux context? Any other suggestion for making a nandroid backup? Recompile TWRP for Moto Deen ?
I'm be willing to help/compile/work on this. Let me know where to dig
I'm trying to get my moto up to standard of being a daily driver and reliable enough to be safe with the data in it.
I think there's a lot of life left in it.
Let me know. Thank you.
xdadevc said:
There's an issue with TWRP 3.6.9. I tried to use it to make a nandroid backup of a running AICP (test keys) and I skipped the data partition. The backup seemed properly done (no errors).
However, rebooting the phone never gets past the initial bootloader screen. This is only after making a backup, no restore.
I tried restoring the boot image, then system and it failed with an error. Second thing I tried was flashing my current build of AICP (different keys that original). Booting works, but decoding the data (which is encrypted) resulted in an error. The message says "password is correct, but the data is corrupt and cannot be decoded". This is weird because it says the same even with a totally bogus password.
So, seems that booting in TWRP will damage the data partition. Is this due to the different selinux context? Any other suggestion for making a nandroid backup? Recompile TWRP for Moto Deen ?
I'm be willing to help/compile/work on this. Let me know where to dig
I'm trying to get my moto up to standard of being a daily driver and reliable enough to be safe with the data in it.
I think there's a lot of life left in it.
Let me know. Thank you.
Click to expand...
Click to collapse
It's a know issue of TWRP last years, also, encryption doesn't work either. And you're right, TWRP makes selinux contexts goes nuts

Categories

Resources