Neutrino Kernel for the OnePlus 6(T) has officially touched down on XDA due to ongoing popular demand, some friendly goading, and user willingness to assist me in maintaining this thread. This is far from a new kernel, some of you may already be familiar with the project as it has been under active development since January 2019. For those of you who haven't, welcome. I'm going to attempt to keep this as concise as possible as I understand that the longer these things become, the less likely they are to be read and comprehended. Shall we begin?
Design Philosophy:
The primary motivation for this project was to craft a kernel based on pure CAF source, discarding as much OnePlus code as possible and performing a minimal import of only that which was necessary to retain full device functionality. In addition to being up-to-date with the latest CAF SDM845 source, Neutrino is also current with the android-4.9 common kernel by way of CAF SDX merges.
Neutrino is intended to target efficiency over raw performance without compromising user experience, stability is prioritized over gimmicks. This is a simple kernel, built using the latest sources for this SoC from Qualcomm, AOSP, and linux-stable.
EAS development and optimization is a primary focus, as a kernel developer who needs to ensure that their products function uniformly regardless of what software it is paired with I have made every effort to minimize userspace involvement in scheduling decisions and instead replicate these processes using in-kernel logic where possible.
Neutrino is compatible with both stock OxygenOS and custom ROMs on both OnePlus 6 and OnePlus 6T. However, I personally own only fajita and primarily use OxygenOS. Thus, that is the device and operating system that Neutrino is specifically designed and tested for use with and in all fairness is the only combination that I can guarantee flawless compatibility with 100% of the time. That being said many (most of) my current users are on various custom ROMs and in it's current state Neutrino should be solid regardless of what ROM or device you choose to use it with, but it is not impossible that certain ROM/device-specific issues may crop up in the future. To that end, I am relying on potential OP6/custom ROM users to alert and assist me in resolving any complications that may arise.
Neutrino is intended to be a flash-and-go experience that does not require user intervention to get the most out of. You are of course, free to tune settings as you see fit, but you should not feel obligated to do so and I wouldn't necessarily recommend it unless you truly feel as though you know what you're doing and why. Most critical settings have been hardcoded in kernel source and blocked from userspace interference during initialization. For rooted users, some additional settings will also be applied via the NeutrinoSettings module, which is baked into the kernel zip and installed only if root is detected. This module, along with any traces of Neutrino's installation will be automatically removed when another kernel is installed, so you need not think too hard about cleaning up after yourself when changing kernels.
Features:
* RELEASE NOTES *
I will do my best to construct a summarized list of key kernel features going forward, but for the time being I highly recommend that you read through the existing notes I've made accompanying all past and present official releases up to this point. This will give you a very good idea of what to expect from Neutrino, where it came from, and where it's going.
Support:
As mentioned, development on this project has been in progress for quite some time, part of the reason I've been hesitant to promote it publicly is the expectations that come along with that. At the end of the day, I'm doing this because I want to create the best kernel I can for my own personal use. Everyone is welcome to come along for the ride, but please understand that I already have a fairly concrete vision of what I intend this project to be so while you are welcome to make suggestions, it's likely that I've already heard them and have not obliged for one reason or another. Please do not ask me to include features such as, Wakelock Blocker, Klapse, Dynamic Fsync, etc. There are plenty of avenues to explore for things of this nature, this is not one of them.
As far as support for legitimate issues encountered while using Neutrino, I am happy to assist in any way that I can provided you help me help you by providing the appropriate supporting documentation, specifically dmesg (as well as pstore if a reboot occurs), for everyone's convenience and ease of use, I highly recommend using the SysLog app when reporting bugs as it will dump everything I could possibly need to see and package it in a zip archive that you can easily share with me.
While I will do my best to actively monitor and address questions and concerns brought up in this thread, I do recommend those seeking more direct support as well as access to current test builds which may not be made publicly available join my existing OnePlus 6/6T Development group on Telegram for the latest Neutrino Kernel news and discussion.
F2FS:
This kernel includes comprehensive f2fs support if desired, current with f2fs-stable/linux-4.9.y, and may be used with both encrypted and decrypted devices as per @arter97 instructions:
arter97 said:
Flash f2fs_tools_for_twrp.zip from TWRP. This won’t format your /data partition.
This will replace TWRP's f2fs tools with the latest version and pass the correct parameter to mkfs.f2fs, which is necessary.
This needs to be done everytime you enter TWRP, if you want to re-format to f2fs.
After formatting, or flashing a new ROM or an OTA, /vendor’s fstab needs to be changed.
Flash f2fs_fstab.zip to convert fstab to f2fs again. This won’t format your /data partition.
Sidenote for those using f2fs:
I've got a report that my f2fs conversion tools weren't applying appropriate optimizations.
If you're using f2fs, just flash this zip from the recovery just to make sure you have up-to-date extensions list for f2fs.
http://arter97.com/browse/f2fs/optimize
Click to expand...
Click to collapse
Current f2fs conversion tools available here
Special Thanks to some select individuals who's work I've drawn inspiration from, directly or otherwise:
@arter97
@joshuous
@nathanchance
@RenderBroken
@Sultanxda
XDA:DevDB Information
Neutrino Kernel for the OnePlus 6T
Current Stable Release: 4.9.196-NeutrinoKernel-sagitta
Build Date: 2019-10-10
Previous Releases: https://github.com/0ctobot/neutrino_kernel_oneplus_sdm845/releases
Kernel Source: https://github.com/0ctobot/neutrino_kernel_oneplus_sdm845
Reserved
4.9.196-NeutrinoKernel-sagitta
4.9.196-NeutrinoKernel-sagitta
Developer: @return.of.octobot
Date: 10/10/19
Device: Unified
Download:
https://github.com/0ctobot/neutrino...nel-sagitta/NeutrinoKernel-fajita-sagitta.zip
Release Notes:
https://github.com/0ctobot/neutrino...5/releases/tag/4.9.196-NeutrinoKernel-sagitta
Neutrino Kernel release for OnePlus 6T (fajita)
Linux Version: 4.9.196
Neutrino Subversion: sagitta
HEAD: 0333ca1
__________________________________________________
Changelog (Summarized):
Update to Linux 4.9.186
Update to LA.UM.8.3.r1-06100-sdm845.0
Rollback to Pie WLAN Drivers and update to LA.UM.7.8.r1-07100-SDM710.0 (qcacld-3.0, qcacmn, fw-api)
Inline with current f2fs-stable/linux-4.9.y
Update and improve Rapid GC handling
DC Dimming fix via @OnePlusOSS OBT17 (c0fa16e)
Restore OEM project_info framework
Various optimizations for Android 10
Sync Android 10 kernel configs
Fix display brightness issues on ROMs using OverlayFS
Implement in-kernel Android version check (9a129fd, 85f53e3)
Avoid root preservation attempts on Android 10 *
Disable zRAM/Swap
Mainline LZ4 updates
* For the time being, Android 10 users should reflash Magisk manually following kernel installation to avoid inconsistent and unpredictable behavior which could result in loss of root. For Pie users, root preservation is still intact and will function as it always has.
__________________________________________________
AnyKernel 3:
Eliminate NeutrinoSettings module and remaining Magisk dependencies. Currently, all critical parameter tuning is handled in kernel, any additional benefits afforded by the module have dwindled over time and no longer justify the added complexity.
(Complete Changelog)
Signed-off-by: Adam W. Willis <[email protected]>
Click to expand...
Click to collapse
Ok, new kernel. Good!!
abalam said:
Ok, new kernel. Good!!
Click to expand...
Click to collapse
It's not that new, he just only published it in xda. By far one of the best kernel I have tested on the op6t. Give it a shot.
hooray for octobot. It's here
10/10 best kernel I've used to date! Hats off to Octobot.
Christ, this thread got posted about a dozen times, what a way to make entrance.
Delete
Best Kernel i've used on this phone.
Have tried multiple and always go back to this one.
Hats off to you Dev.
Glad to see you here! We always need more devs like @return.of.octobot. Those that have the attention for details along with a willingness to help foster better community are in shorter and shorter supply.
Been using Neutrino for a while on Bootleggers. Hands down, the best kernel out there.
Outstanding to see this here. It's a great kernel that is already well polished and stable
@return.of.octobot
Welcome here [emoji6]
You got issues with creating thread with the DevDB, too? [emoji23]
Happened to me a time ago. [emoji16]
Works on latest beta or AOSP ROM only
excellent kernel, best of the best. thanks for effort and good job.
Whppedy whoppedy
Your kernel is XDA's property.
pappschlumpf said:
@return.of.octobot
Welcome here [emoji6]
You got issues with creating thread with the DevDB, too? [emoji23]
Happened to me a time ago. [emoji16]
If you like my work [emoji4] https://paypal.me/pappschlumpf
Click to expand...
Click to collapse
I don't see the point of plugging your PayPal on someone else's thread when the OP hasn't even plugged his own
Wow! Using Neutrino for a couple of weeks now and it's been really smooth with great battery life.
Was curious on how to report any issues since all I could find was the GitHub page. Thanks a lot for starting a thread here.
I've had just one issue, random reboot when trying to unlock screen using fp. It's happened twice in a week. No logs yet since I couldn't find a thread or telegram group, but will post of this happens again.
Anyone faced this at all?
Star_king12 said:
Seriously? Promoting your own paypal in someone else's thread? How can you even go any lower?
Click to expand...
Click to collapse
Buddy that's my signature in Tapatalk of the OP7 Pro. Is that really a problem for you, LOL. I just wanted to post a welcome. I'll edit my post, you maybe too, bye.
Gesendet von meinem xXx_NoLimits_7.6 on ONEPLUS A6003 mit Tapatalk
---------- Post added at 12:41 AM ---------- Previous post was at 12:38 AM ----------
anirudhgupta109 said:
I don't see the point of plugging your PayPal on someone else's thread when the OP hasn't even plugged his own
Click to expand...
Click to collapse
Accidentally, edit your post too and it is gone.
Anyway, problems you have, funny [emoji23]
Gesendet von meinem xXx_NoLimits_7.6 on ONEPLUS A6003 mit Tapatalk
Related
hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J
Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1
ETA
depending on problems and developers that will join
from 6 months to NEVER
This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus
I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.
All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?
CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.
Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse
FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page
diff is 5mb on proper tag
pushed on github
nice to see so many developers trying to help
FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes
I'd like to start this out by stating that these are personal builds. I'm not trying to compete with @transi1's developer prowess; on the contrary, I feel he's done a fantastic job with TWRP 3.0.0 and porting CM13 over to the kindles, and he's part of the reason why I'm motivated to do this side project. I'm releasing these for the purpose of bettering the Marshmallow experience on our aging kindles. I want to see if a different build configuration will help improve performance and reduce lag. I'm also wanting to learn my way through the nuances of ROM development, so I intend on starting small.
Click to expand...
Click to collapse
READ THIS BEFORE PROCEEDING ANY FURTHER
I don't intend to fray any circuits when I compile these builds. However, there's always a chance that something could really go wrong and inadvertently damage your device. In such an event, I (and the awesome XDA community) will try our best to help get you back up and running. However, please don't try to sue me if your device:
doesn't work as a result of flashing this;
initiates a nuclear meltdown, or;
doesn't permit your alarm clock to function normally.
By flashing, you automatically assume responsibility for any loss of data, functionality, or facial hair. Although a 10% tip would be nice if it started printing out money.
Click to expand...
Click to collapse
Downloads:
click the Downloads tab at the top of the page, or just click here. I'm also mirroring this on Google Drive for convenience. Builds will go up on AndroidFileHost. Use this link to find and download the latest releases.
OpenGapps: use ARM, 6.0, package of your choice (I'll create a custom .gapps-config later)
SuperSU: make sure to run echo SYSTEMLESS=false>>/data/.supersu in the TWRP terminal (advanced -> terminal) before flashing SuperSU, or else you'll have to perform a restore via fastboot (credit to @r3t3ch for finding the solution)
Features:
[*]Compiled with UBERTC 4.9
UBERTC toolchain causes the post-compiled builds with the 3.0.72+ kernel to break in a really embarrassing way, so this isn't used for now
based on CM13
more to come!
Known issues in post #2
Changelog in post #3
Feel free to respond to this thread to comment or report a bug. I'm open to all feedback.
Credit where credit is due
@Hashcode, because we wouldn't have CM on our kindles at all without him.
@BuQQzz for some mentoring & advice
@transi1 for porting CM13 and providing some useful fixes for build errors
XDA:DevDB Information
[jem] CM redux, ROM for the Amazon 7" Kindle Fire HD
Contributors
monster1612, Hashcode, transi1, BuQQzz
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.0.x
Based On: CyanogenMod
Version Information
Status: Alpha
Created 2016-03-29
Last Updated 2016-08-07
Known issues
Bugs affecting all CM13-based ROMs on the kindle
Screen artifacts when playing video from Snapchat, Vine, etc.
Audio chops in and out often
Other bugs currently afflicting the other CM13 ROMs for this device
Camera currently doesn't work (although it is functional in the 3/20 RR build and earlier ROMs for jem)
Side note: This camera issue is prevalent w/ transi1's CM13 3/28 build, so it's not specific to this ROM only.
Play Store & Setup Wizard FCs
CM pushed a commit to fix the FCs, so now every ROM built from this point forward should be OK with flashing the latest gapps. (thanks to @r3t3ch for the find)
Changelog
08/07/2016
experimental backtracking to kernel 3.0.84+
July '16 AOSP patches (hoping 8/1/16's patchset made it in there too)
07/01/2016
doing yet another revert to the 3.0.72+ kernel, prior to transi's backporting of the newer one (3.0.101+) that broke the camera
June '16 AOSP patches, plus just about everything CM pushed up until 7/1/16
reverting from UBERTC toolchains to native CM/AOSP one
05/20/2016
defecting to BlissRoms-Devices GH for newest device config files
05/2016 security patches from AOSP, et al.
04/27/2016
refreshing CM sources & obtaining latest sources from transi1
04/09/2016
revert the 4/4 kernel reversion; back to 3.0.101(+)
carry in latest edits from transi1 to try to fix the camera
04/04/2016
revert to kernel 3.0.72+
first build that's been mostly summoned from my local jenkins install - now future builds should automatically upload to the AFH server
03/29/2016
initial build!
Roadmap
The following is a list of features I think will make it onto future builds. Feel free to contribute any suggestions, bug reports, etc.
Layers/RRO theming support
Custom boot animation (or at least one scaled to the kindle's screen size)
Possible removal of some unused stock apps (I'll package them into a separate flashable .zip in case)
Publication of a custom .gapps-config file for use with opengapps packages
I'm going to attempt to resolve the infamous camera bug by starting from a known good point in time and backtracking up through transi's kernel commits. This means a lot more frequent builds (sometimes unstable!) in the next couple days. I hope you guys are ready for more testing.
So far, it seems like transi's github commits to the common device repos may have fixed the camera (thus the reason why I didn't release another backtrack through the kernel commits). However, I don't know for sure, as I haven't tested out today's build yet. Any testers coming from earlier builds should not dirty flash this release; a clean wipe would be preferable. Feel free to let me know how things go.
Today's nightly has nothing special in terms of features, etc. However, I'm going to start implementing features as outlined in the roadmap. As usual, do let me know if there's something you'd like to see.
Some updates...
I still haven't gotten around to trying to bring RRO to this ROM. Apparently, CM's theme engine (which should have been compatible with RRO, but isn't) has conflicts with RRO/layers, and those have discouraged me from bringing RRO in (so far).
I think TWRP 3.0.2 needs to be built for both jem & tate. That release has some important fixes regarding encrypted backups, and even the TWRP people themselves recommend you stop using 3.0.1 if you use encrypted backups. I'm going to build for another ROM (hai there, OmniROM!) and compile against that source for TWRP. EDIT: transi said he'd wait till TWRP 3.0.3 is released to compile it, so we can stand to wait for it.
More updates...
It's been a while since the last build. Obviously, this one I just uploaded is about 2 weeks old at the time of writing. You may be wondering why I took so long to drop this build. It's complicated:
I was seriously curious as to how the camera managed to break down during transi's kernel backporting in mid-/late March. Such curiosity led me to attempt to revert the device repos to a stable state so I could build against 3.0.72+ instead of 3.0.101+.
My reversion efforts were successful (for the most part). I was able to get the process to succeed like normal, but when I tested out the builds (compiled against UBERTC), there was a breaking issue. The camera worked well enough (as I expected), but as soon as I tapped any textbox at all (even the password prompt for a WiFi network that required one), the screen would glitch out and force a reboot. I thought that maybe it was an error on CM's part, so I waited a day or so and compiled again, getting the same issue. At that point, I was baffled and decided to recompile with CM's native toolchain instead of UBERTC.
That build was on 7/1, and is the build that was uploaded an hour ago. I had it built then, but was waiting for a good time to test it out to see if that issue was resolved. Sure enough, when I tested it out tonight, it didn't occur.
Also, you may have noticed that I changed the ROM project name to CM redux. I did this to signify that this project won't be a full-on verbatim port of CM. (right now it is, but that's beside the point.) The name won't officially show up in the ROM itself until the next build, most likely.
Finally, some planned changes:
I'm going to continue with my backtracking scheme. I want to know exactly which commit is responsible for the software failure of the camera.
Obvious name change in the ROM, mentioned earlier.
Replacing CM's theme engine with RRO(?)
CM bloat cleanup. The ROM itself boots in 30 seconds, which is nice and all, but I'd like to try to trim it down a little more.
Good version,thanks. But it often wifi reconnect , can it fix?
wizard_mini said:
Good version,thanks. But it often wifi reconnect , can it fix?
Click to expand...
Click to collapse
I have that same issue with other 6.x ROMs, but I'm not sure what the cause is. Could you get a logcat as soon as that issue pops up again?
monster1612 said:
I have that same issue with other 6.x ROMs, but I'm not sure what the cause is. Could you get a logcat as soon as that issue pops up again?
Click to expand...
Click to collapse
It looks like WiFi 2g link no problems, 5g often reconnect. Let me test more time
Android system cost battery drain more than screen, is it normal?
wizard_mini said:
Android system cost battery drain more than screen, is it normal?
Click to expand...
Click to collapse
That depends on what apps you have installed, how heavily you use the device, and other factors. Try installing BetterBatteryStats as a system app, using it for a few days, and then report back some of the data it collects.
I flash the opengapps pico,when I install G-mail app , it said I must add a Google account,but I already setup my Google account, then I can't open gmail. Why?
wizard_mini said:
I flash the opengapps pico,when I install G-mail app , it said I must add a Google account,but I already setup my Google account, then I can't open gmail. Why?
Click to expand...
Click to collapse
I ran into this same problem using RessurectionRemix. I had to install an older version of Gmail, then update it from the Play Store.
Try this version:
http://forum.xda-developers.com/showthread.php?t=1181033
That's not the one I used, but I used a similar version from here somewhere.
sirp0p0 said:
I ran into this same problem using RessurectionRemix. I had to install an older version of Gmail, then update it from the Play Store.
Try this version:
http://forum.xda-developers.com/showthread.php?t=1181033
That's not the one I used, but I used a similar version from here somewhere.
Click to expand...
Click to collapse
It's a good solution,, I fix it, thanks
monster1612 said:
That depends on what apps you have installed, how heavily you use the device, and other factors. Try installing BetterBatteryStats as a system app, using it for a few days, and then report back some of the data it collects.
Click to expand...
Click to collapse
I use 4hours screen on and 7hours screen off cost 92% battery.
wizard_mini said:
I use 4hours screen on and 7hours screen off cost 92% battery.
Click to expand...
Click to collapse
I have a similar issue when I let my kindle sit overnight. I'm guessing it might be a commit that I reversed when I reverted to the 3.0.72+ source. I'll do a new build within the next few days with a few kernel updates thrown in.
monster1612 said:
I have a similar issue when I let my kindle sit overnight. I'm guessing it might be a commit that I reversed when I reverted to the 3.0.72+ source. I'll do a new build within the next few days with a few kernel updates thrown in.
Click to expand...
Click to collapse
Thanks. I am expecting it!
Introduction
Hello everyone, this is a thread to introduce both users and kernel developers to the concept of linux-stable as well as give developers some tips and a tree to either merge into their own, use as a base, or just as a reference. Feel free to ask questions and enjoy!
What is it?
linux-stable is, as the name implies, the stable branch of the Linux kernel, the base of Android. The phone could not run without the Linux kernel (at least not without reworking a lot of stuff). The Android kernels are based on the longterm stable trees:
Longterm
There are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees.
Click to expand...
Click to collapse
Source: https://www.kernel.org/category/releases.html
All Linux development happens on the master branch, which is governed by Linus Torvalds. When issues are discovered there, the fixes are applied then backported to these various stable trees for consumption. It is not uncommon for a fix to need to go back a few years.
There is a LOT more information available in the notes repo in the android-linux-stable organization if you care to learn more in-depth: https://github.com/android-linux-stable/notes
What does this mean for me?
If you are a developer, this means you should be merging these changes into your own tree. These are vetted, stable fixes to real world problems and they are being handed out for free. It does not take long to get up to date (as you can just merge this tree directly into your own or do it yourself using the tree as a reference) and once you are up to date, there is usually a release once every two weeks, give or take. I provide a rebuttal to a lot of various complaints here. If you still feel like there is a good reason not to do this, please let me know, I'll be happy to try and debate on it!
If you are a user, it means that you should be looking for and using kernels that have these fixes, as it shows the developers care for your security and stability. The current version for this device is 3.18.100 and the current version upstream is 3.18.124 so all you need to do is go into Settings > About phone and look at the kernel version to know if you are up to date.
How do I use?
If you are a developer, the reference tree is located in the android-linux-stable organization: https://github.com/android-linux-stable/marlin
This can either be merged into your existing kernel tree if you have one or be used as a fresh base. You do not need my permission to use it nor do you need to give me credit (although it would be appreciated).
If you are a user, use a kernel that has the changes added in!
Getting notified about updates
There are a few ways to get notified of linux-stable updates:
The linux-kernel-announce mailing list: http://vger.kernel.org/vger-lists.html#linux-kernel-announce
The android-linux-stable Telegram channel: https://t.me/alsupdates
Subscribe to this thread
Follow me on Google+ or Twitter
Getting help
If you have any issues with getting these changes into your tree or want to ask a question, there are a few different ways to do it:
Post in this thread
Join the linux-stable support chat on Telegram: https://t.me/joinchat/C1UAJ1EMSX31PCFdwLnOSg
File an issue either in the android-linux-stable notes repo or the android-linux-stable repo for this device
When requesting help, please give some solid details as to what you are struggling with, as I am happy to provide assistant and clarity but not to do something for you (unless I screwed up).
3.18.88 has been merged in.
3.18.89 has been merged in.
3.18.90 has been merged in.
3.18.91 has been merged in (conflict notes).
Hi Nathan, thanks for the code - built the kernel and flashed (wasn't easy at first). All working well, will use it at a later stage when I build the ROM. BTW, I am running the factory image. Credit also to Anykernel for the zip file
GeyerA said:
Hi Nathan, thanks for the code - built the kernel and flashed (wasn't easy at first). All working well, will use it at a later stage when I build the ROM. BTW, I am running the factory image. Credit also to Anykernel for the zip file
Click to expand...
Click to collapse
Not a Dev, but totally would like to give this a try if you have a zip. On the factory image + twrp 3.2.1
Sent from my [device_name] using XDA-Developers Legacy app
Hi, No problem. There you go... Just flash in TWRP and feedback if all went ok
3.18.92 has been merged in.
Hi, thanks for the code, compiled it against linaro 6.4 (built the cross-compiler following your thread). Tested for one day. All smooth. Sharing the job for those who might be interested. BTW, flashed it directly from fastboot....
Code:
fastboot flash kernel Image.lz4-dtb
Hi, added WireGuard support.
@ nathanchance, sorry, do not mean to hijack your thread...
GeyerA said:
Hi, added WireGuard support.
@ nathanchance, sorry, do not mean to hijack your thread...
Click to expand...
Click to collapse
No worries lol, gives it some life :silly:
Sent from my Pixel 2 XL using XDA Labs
GeyerA said:
Hi, added WireGuard support.
@ nathanchance, sorry, do not mean to hijack your thread...
Click to expand...
Click to collapse
Running this now, so far so good! Thanks!
Definitely interested in wire guard, but currently use WindScribe and am not sure how to properly configure it.
Will try and Frankenstein a config file together tonight and report back [emoji106]
Thanks again
Sent from my [device_name] using XDA-Developers Legacy app
Hi, question. Added DSPManager to my ROM and see that it always gets killed. Can you support the idea to build the kernel with
Code:
CONFIG_SECURITY_SELINUX=n
. Will this get me the kernel permissive and any disadvantages with this? I also see that Viper4android needs a permissive kernel.
3.18.93 has been merged in.
Somebody willing to do a build of the update to flash with fastboot?
I would if I could (still learning how to build myself)
Thnx in advance.
Cheers
Sent from my Google Pixel using XDA Labs
Sgace said:
Somebody willing to do a build of the update to flash with fastboot?
I would if I could
Thnx in advance.
Cheers
Sent from my Google Pixel using XDA Labs
Click to expand...
Click to collapse
Was just going to ask if someone could point me to a good resource on how to do so. Will post anything I manage to do [emoji106]
Sent from my [device_name] using XDA-Developers Legacy app
jimbub said:
Was just going to ask if someone could point me to a good resource on how to do so. Will post anything I manage to do [emoji106]
Click to expand...
Click to collapse
Hi,
I used this for the most part: https://forum.xda-developers.com/yureka/help/guide-compiling-64-bit-android-kernel-t3352728
And this:
https://forum.xda-developers.com/an...-how-to-compile-android-kernel-t3627297/page1
Was very helpful and am building right now
Credits to those guys offcourse.
Sent from my Google Pixel using XDA Labs
Sgace said:
Hi,
I used this for the most part: https://forum.xda-developers.com/yureka/help/guide-compiling-64-bit-android-kernel-t3352728
And this:
https://forum.xda-developers.com/an...-how-to-compile-android-kernel-t3627297/page1
Was very helpful and am building right now
Credits to those guys offcourse.
Sent from my Google Pixel using XDA Labs
Click to expand...
Click to collapse
If it's ok, here is my personal first ever self built kernel from source. It's 3.18.93 and flashable in fastboot (unzip the zip and then: fastboot flash kernel Image.lz4-dtb)
Offcourse thnx to @nathanchance for the source and all the work!
Cheers
Sgace said:
If it's ok, here is my personal first ever self built kernel from source. It's 3.18.93 and flashable in fastboot (unzip the zip and then: fastboot flash kernel Image.lz4-dtb)
Offcourse thnx to @nathanchance for the source and all the work!
Cheers
Click to expand...
Click to collapse
Thanks for doing this, very much appreciate it! For some reason though, this prevented my phone from booting. Ended up restoring my boot partition and things are well now!
Neutrino Kernel began as an effort to keep the stock LineageOS 15.1 kernel up-to-date with the latest linux-stable releases and has since evolved into an intensive crash course in maintaining my own custom kernel. Although some of you would accuse me of modesty, I think it's important to acknowledge that I am a "kernel developer" in the same way that Amy Schumer is a "comedian". That is to say, my work is highly derivative and built on the backs of individuals who are far more talented than I am. My role here is to have a vision, establish a design philosophy, and use the resources at my disposal to bring that vision to fruition.
Those of you who've perused my staging repo will know that I'm very particular about cleanliness. All changes and additions are vetted based on viability and purpose. Neutrino is based on kernel.lnx.4.4.r35-rel, pure CAF source for Android 9.0 tracking and upstreamed to the latest linux-stable release. I have manually rebased Essential's stock kernel source on top of CAF using relevant OEM commits from PPR1.181005.034. All major features and patchsets are assembled on independent staging branches of this codebase base and merged into the release repository.
I do not commit changes that I cannot justify or explain, and I do not go on indiscriminate cherry-picking sprees. There are a handful of developers that I highly respect, and who's projects have served as inspiration for my own. My intention is to incorporate the best of what they've brought to the table in a way that most effectively achieves and enhances this project's design goals.
I like to think that Neutrino is relatively subdued in terms of "features", with a stronger focus on optimizations over fluff. That being said, there have been quite a few additions which I feel have merit in terms of increased performance and/or efficiency provided the former does not compromise the later:
Revamped EAS implementation for Pie
sultanxda's CPU/GPU Boost Drivers
Dynamic SchedTune Boosting
Maple I/O Scheduler
Broader subsystem support for Power Efficient Workqueues
KCAL Color Control
Backlight Dimmer
Fsync Toggle (enabled by default)
GPU Underclock @ 180 MHz
CPU (partial) Overclock, Silver Cores @ 2035 MHz
Boeffla Wakelock Blocker v1.1.0
Wireguard Support
VDSO Support
Treewide memory allocation/overflow patches from mainline
OOM Reaper and various memory management enhancements to improve LMK
Treewide compiler warnings corrected
Built with self-compiled Clang 8.0.3 and GCC 8.2.0 toolchains, with a local initialization sanitizer and polly optimization flags
INSTALLATION:
**Neutrino now utilizes AnyKernel2 zip format for universal compatibility**
As a result, you can now flash this kernel on just about anything including Oreo/Pie custom and stock ROMs. The only requirement is that your firmware is current and up-to-date with PPR1.180905.036 at a minimum. Flashing on older firmware will result in broken input detection and a non-functional touchscreen.
That being said, this is an EAS kernel and is best suited for use on EAS-compatible ROMs. Just because it can be flashed on stock does not mean that you should do so. Installation on ROMs which do not natively support EAS (such as stock) will likely result in sub-optimal battery performance and I will not entertain any complaints stemming from the use of Neutrino on ROMs which are incompatible with EAS. Stock support is a perk and an experiment on my part, please do not make me regret giving you the ability to flash on stock, I will drop public support for it if this disclaimer is routinely ignored. If you choose not to heed my recommendations, you are doing so at your own discretion.
For ease of use, I would recommend using an app with built-in zip flashing functionality such as EX Kernel Manager or FK Kernel Manager. Of course, I cannot expect all of you to utilize a paid app for installation and as such, conventional installation via TWRP is certainly possible as well.
Neutrino will preserve existing Magisk installation during kernel update, meaning if you already have Magisk installed on your device you need not worry about reflashing Magisk when updating your kernel. If you do not already have Magisk installed and desire root access then Magisk zip must be flashed following kernel zip via TWRP.
DOWNLOADS:
Current releases can be downloaded here.
Archival builds (boot images) for lineage-15.1 can be found here.
SOURCE & SPECS:
Neutrino Kernel Source
Neutrino Staging Repo
Changelog
Linux Kernel Version: 4.4.166
CAF Release: LA.UM.7.4.r1-03900-8x98.0
Neutrino Kernel Version: hercules
Clang Version: neutrino clang 8.0.0-r348460
Build Date: 20181206
@return.of.octobot Awesome! Thanks for bringing us upstream updates! So if I've understood it correctly if I do flash the root version and want to take an ota update, I'll have to revert to stock kernel for the lineage os version I was on or flash the non root version that you've provided us with before updating?
You're as awesome as you are humble. Thank you for this. Life is getting easier and easier for common users thanks to contributions like this. Awesome.
Arju said:
@return.of.octobot Awesome! Thanks for bringing us upstream updates! So if I've understood it correctly if I do flash the root version and want to take an ota update, I'll have to revert to stock kernel for the lineage os version I was on or flash the non root version that you've provided us with before updating?
Click to expand...
Click to collapse
When I had magisk installed and was running lineage... The OTA program didn't care about signatures...
Since it's not a Delta... It's not patching anything... Just overwriting what is currently there... So it SHOULDN'T matter...
Sent from my PH-1 using XDA Labs
rignfool said:
When I had magisk installed and was running lineage... The OTA program didn't care about signatures...
Since it's not a Delta... It's not patching anything... Just overwriting what is currently there... So it SHOULDN'T matter...
Sent from my PH-1 using XDA Labs
Click to expand...
Click to collapse
Hey, great to see you here. I remember you from the Nexus 6 forums. Thanks for the answer
Arju said:
Hey, great to see you here. I remember you from the Nexus 6 forums. Thanks for the answer
Click to expand...
Click to collapse
Yeah... I couldn't help myself... When I found out buying this phone was a direct thank-you to Andy Rubin...
Sent from my PH-1 using XDA Labs
Arju said:
@return.of.octobot Awesome! Thanks for bringing us upstream updates! So if I've understood it correctly if I do flash the root version and want to take an ota update, I'll have to revert to stock kernel for the lineage os version I was on or flash the non root version that you've provided us with before updating?
Click to expand...
Click to collapse
rignfool said:
When I had magisk installed and was running lineage... The OTA program didn't care about signatures...
Since it's not a Delta... It's not patching anything... Just overwriting what is currently there... So it SHOULDN'T matter...
Sent from my PH-1 using XDA Labs
Click to expand...
Click to collapse
He is right, I was recommending that the unrooted image be flashed prior to OTA but you could also certainly restore the boot.img that was originally included in invisiblek's build for maximum peace of mind. I would tend to agree that it doesn't actually matter as the OTA should be installing a completely new image on the opposite slot so I'm not sure what difference it would make, I was just leaning my instructions towards the safe side, perhaps I'll try and clean them up.
only for lineage can it work on aosp rom?
Sent from my PH-1 using Tapatalk
kakabobo said:
only for lineage can it work on aosp rom?
Click to expand...
Click to collapse
Yeah, it's literally built from Lineage source with upstream Linux kernel merged in. I wouldn't recommended flashing this on AOSP any more than I would recommended flashing the stock Lineage kernel on an AOSP build. Even if it booted I imagine there's a good chance it would break things to the point of being unusable. That being said, I haven't tried it so I'm only speculating. If you do, make sure you've got a copy of your ROMs stock boot.img to recover with. But seriously, I wouldn't.
return.of.octobot said:
Will be uploading 4.4.118 images within the next day or two, currently experimenting with merging the latest CAF tags into upstream source. Jury's still out on whether or not that's going to prove successful but I will be releasing standard linux-stable builds regardless.
Click to expand...
Click to collapse
Without further ado, 4.4.118 images are available for download here.
Same deal as before, built from unadulterated upstream linux-stable source. Stock and Pre-Patched Magisk variants available.
I did manage to get a CAF-based version of this kernel building and booting, however it broke my touchscreen and is clearly not ready for public consumption. So, until further notice we're going to stick with the 'if it ain't broke..' philosophy, although you may or may not see me releasing some experimental builds in the future.
For now, enjoy 4.4.118
***OP updated for 4.4.118 release, revised comprehensive installation instructions***
return.of.octobot said:
***OP updated for 4.4.118 release, revised comprehensive installation instructions***
Click to expand...
Click to collapse
That's for the build today right?
shooterlgk said:
That's for the build today right?
Click to expand...
Click to collapse
In theory these images should work on any LineageOS install, regardless of build date, but yes it's compatible with both the 02/26 and 02/28 releases from invisiblek. I've updated the screenshot in OP which shows this kernel installed on the latest Lineage OTA.
return.of.octobot said:
***OP updated for 4.4.118 release, revised comprehensive installation instructions***
Click to expand...
Click to collapse
flashed your kernel with magisk support on todays (28th) lineageos build. Magisk is not passing safteynet.
edit: followed your instruction to patch the boot img using magisk and now it passes safteynet. had to use the non patched on from here.
Arju said:
flashed your kernel with magisk support on todays (28th) lineageos build. Magisk is not passing safteynet.
edit: followed your instruction to patch the boot img using magisk and now it passes safteynet. had to use the non patched on from here.
Click to expand...
Click to collapse
Good to know, I'll have to make note of your findings in the OP. I would've never figured that out myself as I've got xposed installed and to the best of my knowledge my SafetyNet checks will always fail because if it. I've really just been offering the prepatched images because I thought it would be helpful to allow some to bypass the step of patching manually. However, I'll have to consider whether it might be a better idea to just provide the clean image with instructions on how to patch it.
return.of.octobot said:
Good to know, I'll have to make note of your findings in the OP. I would've never figured that out myself as I've got xposed installed and to the best of my knowledge my SafetyNet checks will always fail because if it. I've really just been offering the prepatched images because I thought it would be helpful to allow some to bypass the step of patching manually. However, I'll have to consider whether it might be a better idea to just provide the clean image with instructions on how to patch it.
Click to expand...
Click to collapse
So this is what I did.
1. Flashed lineage os. Set it up.
2. Flashed your kernel (non magisk version) using fastboot and booted back into rom. (Not sure if this is necessary as I later on flash the patches version by magisk manager).
3. Install magisk manager. Have the non magisk version of your boot image on my phone. Patch it with magisk manager.
4. Transfered the patched boot image to computer.
5. Flashed the patches boot image using the computer (fastboot). Reboot into system.
6. Safetynet check passes.
Arju said:
So this is what I did.
1. Flashed lineage os. Set it up.
2. Flashed your kernel (non magisk version) using fastboot and booted back into rom. (Not sure if this is necessary as I later on flash the patches version by magisk manager).
3. Install magisk manager. Have the non magisk version of your boot image on my phone. Patch it with magisk manager.
4. Transfered the patched boot image to computer.
5. Flashed the patches boot image using the computer (fastboot). Reboot into system.
6. Safetynet check passes.
Click to expand...
Click to collapse
Thanks for sharing. I essentially went through the same process to patch these images myself after they were built, perhaps there is some kind of security measure in place where the boot.img needs to be installed to the same device it was patched on? I find it strange that it would successfully root the device, but not pass SafetyNet. I'll think on that and figure out if it makes more sense to just release unpatched builds in the future.
return.of.octobot said:
Yeah, it's literally built from Lineage source with upstream Linux kernel merged in. I wouldn't recommended flashing this on AOSP any more than I would recommended flashing the stock Lineage kernel on an AOSP build. Even if it booted I imagine there's a good chance it would break things to the point of being unusable. That being said, I haven't tried it so I'm only speculating. If you do, make sure you've got a copy of your ROMs stock boot.img to recover with. But seriously, I wouldn't.
Click to expand...
Click to collapse
I flashed it on AOSIP without issue. Not sure if it's considered the same as AOSP.....
return.of.octobot said:
Thanks for sharing. I essentially went through the same process to patch these images myself after they were built, perhaps there is some kind of security measure in place where the boot.img needs to be installed to the same device it was patched on? I find it strange that it would successfully root the device, but not pass SafetyNet. I'll think on that and figure out if it makes more sense to just release unpatched builds in the future.
Click to expand...
Click to collapse
I wouldn't realy mind and I think it would make it easier for you too. If the patching is unique per phone then it makes sense that we patch it ourselves. But we need upstreamed updated kernels!!! so don't stop doing those!!
Arju said:
I wouldn't realy mind and I think it would make it easier for you too. If the patching is unique per phone then it makes sense that we patch it ourselves. But we need upstreamed updated kernels!!! so don't stop doing those!!
Click to expand...
Click to collapse
Yeah of course, no sooner had I uploaded 118 than 119 was pushed. I'm not sure if I'll be able to get one out for each release before the next one comes out, but I'm going to be keeping these updated a frequently as I can. Anyway, I was only speculating about device-specific images, but I'm going to try and flash an image that was patched by my buddy and see if I can reproduce any issues. Regardless, I'll likely stick to uploading unpatched images in the future.
New build up at sx.ix5.org, use version 2018-10-30.
Changelog here: https://sx.ix5.org/changelog.html
Install guide: Flashing AOSP on Xperia XZ
XDA:DevDB Information
AOSP Pie based on Sony Open Devices Project, ROM for the Sony Xperia XZ
Contributors
local__hero, fastbooking, oshmoun
Source Code: https://git.ix5.org/felix/local-manifests-ix5/src/branch/ix5-customizations
ROM OS Version: 9.x Pie
ROM Kernel: Linux 4.x
ROM Firmware Required: .184 / .192
Based On: AOSP
Version Information
Status: Nightly
Created 2018-11-09
Last Updated 2019-05-17
Reporting bugs
Important: Read the bug list before posting. Anyone can add bugs to the list, just follow the rules.
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
Don't make me ask you for logs every time!
I will repeat the rules again here:
Rules:
New bugs must include version where error popped up and which oem version you are using
Only reproducible errors
Should include adb logcat (linked in a pastebin service like https://del.dog)
Must include clear description what is wrong
If it is a visual/SystemUI bug, only report it here
If it is an internal bug(e.g. fingerprint crashes device), report it to the Sony bugtracker as well!
Always try to fix the bug yourself first! Then submit a pull request to Sony
Must search if error has already been reported (bug tracker, this document, dev buglist)
If you've reported the issue somewhere else already and just want to track it here as well, add a link
Before reporting a bug, always make sure to isolate it. That means, wipe everything, install only the ROM without GApps and Magisk and see if the problem still exists. Only then report the bug!
---
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
---
In 9.11
1. Everything still works
2. Charging with plugged at screen off works
3. On gcam portrait mode and night photo gives purple glitched image
And phone seems to be faster.
Bug: 9.11 with oem v2- Clean install
- Hotspot not working
- Phone call issue - Mic and speaker not working, cannot hear anything or say anything << Listed in the bug
- Top speaker not working
Still testing.
An update
Yes, we know calling is kinda broken right now on both oem versions. Yes, we know you have problems with dualsim devices because you didn't flash the dualsim patcher. Yes, battery life isn't very good because we are testing out some increased CPU frequencies so video doesn't stutter. (you can go back to the 11-05 build which has the old CPU freqs and compare).
We're aware of a lot of these issues, and they are all tracked in the current buglist (see post #2).
Development happens mostly in the Sony open devices program, with a few heroic volunteers contributing. Right now, a lot of work is being done to get the current flagships(think XZ2, XZ3) to a semi-stable state, but work for our device is done as well.
You can check progress in the sonyxperiadev repos. E.g. recently, some changes to the telephony HAL integration have been made, see the common device repo.
Why is it taking so long to fix all this?
Sony buys many of their processors from Qualcomm. Lots of stuff in phones is proprietary and covered in patents, and you can only get the source code if you sign an NDA. So even if Sony wanted to, they could not release the source for a lot of things.
See all the files with the name "qti" in them? That's Qualcomm Technologies, Inc. See all the repos named something like "qcom-something-something"? That's Qualcomm.
When there's a problem, we have to report it to Sony, who report it to Qualcomm. This takes time already. And don't forget Qualcomm has suppliers as well, and so on and so on. The same is true for other parts, e.g. the Wi-Fi chips are from Broadcom.
Then, support for hardware stuff is on many levels. A lot of low-level drivers that are driving the hardware are on the /odm partition(the one that the oemv1/v2 blobs get flashed to). Then there is work to be done tweaking the actual hardware abstraction layer(HAL) interfaces that work with these driver blobs. Then there are kernel drivers that can go wrong and mess up. Then it can be a problem somewhere higher up in the Android frameworks. Lots of detective work.
If new blobs from Qualcomm come out, Sony itself needs to do some testing, and then releases a new oem version. It won't just magically work, we need to tweak the SODP vendor side as well. It could be as easy as changing a version to a newer one, but it could also be a lot harder. The sonyxperiadev crew knows what's needed to integrate these new blobs, but it still takes time and testing.
Qualcomm provide the a lot of the source code to work with their hardware and blobs from the higher-level Android side in their CodeAurora forum (CAF) repositories. The relevant changes then get merged into the sonyxperiadev repos and we can test if it works(or if something new is broken...).
For more info, read the Android documentation on hardware etc.
The chip in our phone, the MSM8996, is quite old already(even the SDM845 in the XZ2/3 is already quite old in processor standards). We can be luck that Qualcomm still provides support. But it's not a priority to them, they want to sell new
ones of course. That is also a reason updates can take longer.
Regarding full forced-reboot crashes:
Sadly, as of now, for some people the "/sys/fs/pstore" folder does not get populated after a crash. This is important to diagnose what happened.
You can apply this patch to force a kernel panic on every reboot, but I would recommend that you do
so only if you know what you are doing.
Regarding battery life:
Please install BetterBatteryStats
and find out what is draining the battery.
This could really help us out! But first, make sure you are not running any GApps, because the Google Mobile Services are a massive pile of battery drain.
If you absolutely have to use GApps, please run only the "pico" GApps version!
---
About the posts here:
Like 90% of posts here and in the old thread are full of people who just plain refuse to read, asking how to install or demanding someone help them out with something that has already been answered time and time again. This makes it extremely annoying for the us who have to scroll through pages of useless stuff to find the genuine bug reports. You do realize this site is literally named "xda-developers", right? If you're unclear on the concept, please read this: https://forum.xda-developers.com/showpost.php?p=16682226&postcount=2441
"This doesn't work!" - "This thing crashes!" - That gives us almost no clue what is happening. We need logs, or we can't do anything about it. I have only one phone, and I only use the stock ROM. There are a lot of nice testers who send others and me helpful bug reports, with detailed explanations in what circumstances it occured, with proper logs.
With that info, the Sony open devices team and us can actually look into issues.
So please, if something doesn't work AND we are not aware of it yet, post it to the bug list (not here!) and attach a link to a log that you uploaded, e.g. to a service like hastebin.com.
nhicko95 said:
how is battery life?
Click to expand...
Click to collapse
Test it out, please. And don't forget to report the diagnosed battery stats.
DarkPrinciple said:
I should be able to get to 12 lunch with my battery being more than 50%
Click to expand...
Click to collapse
I've tweaked for more performance right now, but you can use 11-05 to get old CPU freqs. Also, please help hunt down what is draining the battery, it's most likely too many held wakelocks, but it could be any number of things.
bihslk said:
So what is the latest and best working version of this rom?
Click to expand...
Click to collapse
It's literally in the first post.
bihslk said:
Rom is pretty OK but really annoying top speaker bug. Only lower one works.
Click to expand...
Click to collapse
That is already in the bug list. Please read the bug list before posting.
Update 2018-11-16
Some new developments are happening.
Oem binaries version 3 are out. This should give improved power management. The SODP team has also worked on getting audio handling during calls to work. A big thanks to oshmoun for his work on the audio manager. This change was introduced on the 11-15 build. The issue of no call audio when a bluetooth headset is connected is still present as of now.
Changed IRQ handling (PR by Angelo/"kholk"). This should give better battery life and maybe faster wakeup from deep sleep. But could also lead to instabilities and crashes. Send logs & pstore, see post #2. This change was introduced on the 11-15 build.
Testing kernel 4.9.137 i in progress (we are currently on .103). This means stability and security enhancements from upstream linux. Thanks to Nathan Chance who opened this pull request..
But some of those upstream changes might be incompatible with our Sony kernel, so we have to test that. Send logs & pstore, see post #2. This change was introduced in the 11-16 build. If the 11-15 and 11-16 builds are unstable, revert to an older one. But please be brave and run them for at least a day to get us logs of potential crashes.
---
optixperiaa said:
I am always confused about "flash latest stock ftf" part about roms as a newbie.. if we flash sony's ftf how can we flash rom ? isnt it overwrite ?
Click to expand...
Click to collapse
Your phone software is made up of many layers. The ROMs like omni or this AOSP-based one only modify your /system and /boot partitions.
But when you update your stock firmware via flashtool, you also update your phone modem firmware, your qnovo charging controller firmware, your lower-level bootloaders etc. That is why we instruct you to update to the latest stock firmware. You could theoretically skip flashing /system in flashtool(because it will get overwritten anyway, as you've already discovered) and directly flash a custom ROM afterwards.
When you're coming from omni, there is no need to flash stock firmware again in between, because your other partitions stay the same. Just a new /oem is needed.
viori said:
flash omni_kagura-2018-11-20_UNOFFICIAL_TESTBUILD-2
Click to expand...
Click to collapse
Again, please keep this thread about development for AOSP. The omni builds are not meant for you.
If you have trouble installing then simply don't use it.
DO NOT POST HERE FOR HELP OR YOU WILL BE REPORTED. Read everything before posting.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
The OP has requested that you do not post questions in this thread, please use the thread he states in the OP to do that.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
Click to expand...
Click to collapse
Thanks
Thread cleaned
General update
Newer builds will have selinux set to "enforcing". Most denials should have been fixed or are irrelevant. If you encounter any problems, selinux-related or anything else, please report them to the Sony bugtracker or - even better - submit a pull request to the selinux-policy repo.
Update 1: vendor blobs aren't binderized correctly atm, so no network. You can set selinux back to permissive to fix most issues atm.
The Wi-Fi hotspot has been fixed thanks to oshmoun. In newer builds, it should be using less battery.
Next thing we're going to tackle is deep sleep and battery drain. Big pain point and one of the last blockers, apart from the camera and bluetooth in-call audio.
You might have noticed that the omnirom device trees have been updated to 9.0. Nightly testing builds work fine, but they have the same issues as the AOSP-based ones.
Work is also under way to get a Pie-based TWRP recovery stable, with support for FDE encryption(this means that you will be able to back up your encrypted installations). Mounting /userdata works, but the builds are not ready for public release yet.
Update
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
local__hero said:
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
Click to expand...
Click to collapse
Great job.
I already built a custom Pie kernel about a week ago to gain better performance but the charging bug was driving me insane :crying:
I guess now's the time to go back to the mighty Pie and try building a nice and hopefully stable Marrow Kernel.
Cheers
Finally a new build is out!
I can't pass safety net on latest build.
Any ideas what should I use ?
Since modules for spoofing fingerprint simply don't work.
I tried universal safety net fix but with no avail.
V 12.15
Charging working fine. But i have problem with camera, photos are very dark.
Sometimes touch screen not working and i need to switch the screen and on again.
ov2rey said:
Sometimes touch screen not working and i need to switch the screen and on again.
Click to expand...
Click to collapse
Disable Dt2w
oem v4 is out
DahakePL said:
Disable Dt2w
Click to expand...
Click to collapse
Thank you It's work!
Layns said:
oem v4 is out
Click to expand...
Click to collapse
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
ov2rey said:
Thank you It's work!
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
Click to expand...
Click to collapse
I tried it works fine but the camera sucks and the sound is bad, the screen opening with double tap is running slow, the charge is a little quick