Dóe anyone please tell me what is the different between them
I wanna know too
the way i see it:
com2- official 6.5 out on phones now
com3&5 - new bottom start bar
Please help us understand
Go here:
http://forum.xda-developers.com/showthread.php?t=446730
and read all at the end of post one.
I'll just describe the current states of those COM branches...
COM2 - Builds 218XX, which is exactly the official WM6.5 released in 6th October, 2009. The UI remains the same as in builds 211XX to 217XX.
COM3 - Builds 230XX, the UI from 23001 to 23021 is the same as COM2's UI. But starting from 23022, the UI keeps changing even till now.
COM4 - Builds 234XX, a branch which contains new features, but no more new builds has been leaked since 23420. Some changes in this branch were implantated back into the COM3 branch.
COM5 - Builds 235XX, only few information of this branch was leaked. The only thing I know temporarily is that 23502 is older than 23081...
Related
If anyone is interested, here is a patch which merges Dell's 309 release with the CodeAurora gingerbread kernel for the Streak. (It's not really 7zipped, but I didn't realize bz2 wasn't a legal extension here). It compiles but I'm wrestling with an error creating the System.map file.
If anyone knows someone at Dell such that we can get a newer drop than 309, I'd be happy to merge that instead.
Gingerbread kernel progress
I've managed to push my changes up to github.
https://github.com/coredog64
There are two repositories:
Dell-Streak-Device-Tree, which I cloned from an existing Froyo version by Mistadmin (credit where credit is due ). The only significant changes are the removal of some prebuilt modules which wouldn't work with the new kernel and massaging of make files to eliminate LOCAL_MODULE_TAGS errors on build.
streak-android, which is the CodeAurora kernel sources with Dell's alpha level Gingerbread changes merged in. As DJ_Steve mentioned in another thread, the 4329 drivers out of CodeAurora don't compile, so I replaced them with the latest and greatest from CyanogenMod.
The only other significant change was to add tun.ko and cifs.ko to the list of modules being built.
The tree builds (yay!) but it only builds the image for a generic device. It does build a kernel but not an image for the Streak.
If someone has some time to take a look and give me some pointers I would appreciate it.
Deleted
https://review.lineageos.org/#/q/pr...rnel_huawei_kiwi+branch:cm-13.0+status:merged
I stopped from giving each CVE an own topic, this is already very time consuming without having to do so.
Basically you can see CVEs in the kernel-tree, not in the device-tree (All from Jan 08 are January CVEs, including some of todays patches which were missing on our tracker until just recently)
We have our internal means of sharing CVEs along with additional infos (does it even apply, which kernel version, links to patches for our specific kernel, ...) and to track the status of each.
For the security string: that one was usually updated globally but as basically all devices had a fresh start on 14.1 branch, 13 is mostly orphaned now - therefore the string is old, which doesn't mean we don't work on it
BadDaemon said:
https://review.lineageos.org/#/q/pr...rnel_huawei_kiwi+branch:cm-13.0+status:merged
I stopped from giving each CVE an own topic, this is already very time consuming without having to do so.
Basically you can see CVEs in the kernel-tree, not in the device-tree (All from Jan 08 are January CVEs, including some of todays patches which were missing on our tracker until just recently)
We have our internal means of sharing CVEs along with additional infos (does it even apply, which kernel version, links to patches for our specific kernel, ...) and to track the status of each.
For the security string: that one was usually updated globally but as basically all devices had a fresh start on 14.1 branch, 13 is mostly orphaned now - therefore the string is old, which doesn't mean we don't work on it
Click to expand...
Click to collapse
Okay! That definitely helps. And we all appreciate the time you spend on it
Does this mean that the displayed patch level in About Phone won't necessarily show the current date, despite having the proper CVEs?
animeme said:
Okay! That definitely helps. And we all appreciate the time you spend on it
Does this mean that the displayed patch level in About Phone won't necessarily show the current date, despite having the proper CVEs?
Click to expand...
Click to collapse
Yep, that's what it means the phone can't know by itself which level it has, someone has to tell it
https://review.lineageos.org/#/c/159052/ <- pick that one for your personal build maybe, then you might feel better seeing January instead of Dec
Deleted
Deleted
Lineage CICD Project
This is my personal effort given to you, the community, which spends a lot of hours to craft a fully-functional and perfectly tuned ROM for our beloved Smartphones!
What is it?
This project aims to provide a Build system for Android Developers which will be able to build an Android ROM for a different set of Codenames given, automatically for you, ( by default ) every night. Not only built stock sources that are already available on LineageOS Github account, but feel free to build even your custom code thanks to the support of local_manifests/*.xml fully supported by this Docker.
Where can I find it
CICD
- Github: https://github.com/julianxhokaxhiu/docker-lineage-cicd
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/docker-lineage-cicd/
OTA
- GIthub: https://github.com/julianxhokaxhiu/LineageOTA
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/lineageota/
- XDA: https://forum.xda-developers.com/showthread.php?t=2636334
Why?
As you all remember the transition from CyanogenMod to LineageOS was not smooth. Even today we are not granted with Nightly Builds, but with Weekly, because of capacity issues on providing such an amazing plethora of supported Devices ROM ZIPs ready to be flashed.
Therefore this projects aims on providing an easy-to-use build system which may help you on providing a Ready-To-Flash ZIP at the end of each Build round.
How does it work?
This is a pre-packaged Docker system based on Debian, with all the dependencies in place to correctly build ( even in an optimized way ) any LineageOS codename ROM. A cronjob will take care to start the build script on the configured time ( by default 10:00 UTC ~= 02:00 PDT ), which then will take care to build every codename given with an environment variable to the Docker.
All you need from now on is just the Docker Engine installed on your favourite Linux distribution.
Bonus!
Of course the ZIP that will be produced needs to be transferred to the device in order to flash it. Such a boring task...what if we can automate it through OTA?
As you all know, my first big project I've ever started for XDA was the OTA Server which perfectly emulates all the required calls to make it working with ( old and deprecated now ) CyanogenMod ROMS, as well as with ( long life to ) LineageOS, right now, today!
All you need to do is to configure an Environment variable in the Docker to say where your OTA Server is located. The URL will the be added automatically for you inside the build.prop file as cm.updater.uri=$OTA_URL.
...but wait, there is more!
Since the OTA Server is written in PHP, you all know that is a headache to prepare the system to make it working. A lot of user complained in the original Thread that was difficult for them to understand how to setup it correctly, therefore a fully working autonomous Docker is there for you, ready to serve the OTA Layer for you built ROMs!
I want to use it right now!
I am pretty sure you want! The Docker has now been tested for a nearly a Month and I'm successfully installing my own builds for a couple of weeks on my devices ( really a great satisfaction! ).
If you want to run it as well, I suggest you to take a look at this Bash script that will run for you the Dockers, already talking to each other. Since the script has been studied to work on top of the "VPS Powered By Docker" project, I suggest you to take a look at it. Although nothing is preventing you to use it in your favourite way.
Requirements
See the detailed list on the project README.
What about License
All my projects are always developed with MIT license, which means feel free to do what you want with it. I don't really care if you do business with it, it was a great challenge for me reaching this autonomous entity to run, therefore I don't mind of possible outcomes of it. Although Issues are always welcome for improvements, if any found, of suggestion for a possible feature enhancements.
Future plans?
At the moment I have some ideas, which I may, or may not, be able to implement as I am not a professional Android Developer. Although some nice to have points are:
- Possibility to build ANY Android distro ( from AOSP to any fork of it )
- Possibility to have changelogs of every nightly build ( attached as *.txt and *.html format, next to the built ROM )
- Maybe a logo?
Thanks for Awesome Work
Thanks for awesome work.
Hello!
This is a development thread for the project of upgrading of the Linux kernel for the U8500 platform.
Builds provided here (at the moment of writing this message) are not considered to be used as a daily driver, by any means, - these are rather a dev preview versions.
For now, there are a several LK builds (the highest currently supported kernel version is 3.10).
Because builds here are really not stable, I'll just leave a disclaimer here.
Code:
#include <std/disclaimer.h>
/*
* I am not responsible for bricked devices, dead SD cards, thermonuclear
* war, or the current economic crisis caused by you following these
* directions. YOU are choosing to make these modificiations, and
* if you point your finger at me for messing up your device, I will
* laugh at you.
*/
Working features
RIL
Camera (front & rear) - only works in <3.8
Video (playback & recording)
Audio (playback & recording)
Wifi
Bluetooth (broken in >=3.8, needs a workaround to manually startup)
USB, ADB
Tethering (not tested)
GPS (not tested)
Sensors
Known bugs
IRQs are mishandled by some device drivers (abb_btemp, abb_fg)
proximity sensor might not work (not tested, cause it's broken on my device)
deep sleep might not work at a times
MMC driver works unreliably in >=3.8 (contiguous usage might lead in a data corruption)
networking is not fully-functional (no mobile data)*
camera is broken in 3.8
*some other features of the android kernel might not present - it's because these kernels lacks android-specific patches.
Sources
LK 3.5
LK 3.6
LK 3.7
LK 3.8
LK 3.9
LK 3.10
Downloads
http://xda.mister-freeze.eu/XDA-files/ChronoMonochrome/misc/upgrading
Installation
install chrono kernel r5.2 or higher (this is needed to pick up the necessary scripts, incl. bootscripts, etc)
reboot to recovery
install build linked in "Downloads" section
Credits
Linux kernel development community
Google
ST-Ericcson
Samsung
Team Canjica
XDA:DevDB Information
U8500 Linux kernel upgrading project, Kernel for the Samsung Galaxy Ace II
Contributors
ChronoMonochrome
Kernel Special Features:
Version Information
Status: Alpha
Created 2017-05-09
Last Updated 2017-05-10
Reserved
Porting
The porting a higher kernel version tehnique I'll describe here is not intended to be a guide for dummies. I'll assume you've already built a kernel for your device, familiar with git versioning control usage and with some porting / coding tehniques.
Firstly, you need a cleaned source for your device. By "cleaned" I mean, there are no Linux incremental patches, android changes applied, manufacture-specific patches are avoided when possible and so on - you need sources as closest to a "pure" Linux kernel as possible. Otherwise you'll have later need to deal with conflicts resolution, you'll most likely be unable to resolve and the kernel won't boot.
So, without a further forewords, the tehnique is below:
1) As was previously mentioned, a clean kernel source is required, I'll assume we are starting from LK-3.4 ( https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/ea228ee0f5e9935841aff25c62fa163cd78dc01d ) and porting a higher kernel versions. A kernel base needs to be tested for any bugs just to distinguish, which bugs were intruduced during porting from those ones that already present in a kernel base.
2) The following steps will mostly use git bisect and git merge commands in order to merge all the changes from a higher kernel versions and help to find / resolve the bugs that were introduced. I suggest copying a git kernel repo that you use for building to a somewhere else, so you can use it , e.g. for grepping a different versions source, bisecting the revisions and so on, so don't need to bother messing up in your main repo that you use for build.
3) Firstly, lets just try to merge a higher kernel version, e.g. LK 3.5 by issuing a command git merge lk-3.5. You'll likely have a lot of merge conflicts, most of which you can resolve with resetting the paths to a some revision (either a kernel base - lk 3.4, or the version you do port, or just another suitable conflict resolution). So I suggest to write those paths to a text file, like so:
Code:
arch/arm/boot
arch/arm/mach-ux500
arch/arm/plat-nomadik
drivers/mmc
include/linux/mmc
drivers/usb
include/linux/usb
drivers/mfd
include/linux/mfd
...
Write all the paths you intend to reset to the kernel base, you most likely need to re-use them later. To actually perform a resetting source, you can issue
Code:
for path in $(cat file_with_a_paths.txt | xargs)
do
git checkout COMMIT $path
done
Be sure not to put to this file anything not the device-specific! Resetting to the kernel base should be avoided when possible (never ever try resetting archictecture-specific paths, e.g. arch/arm/kernel, arch/arm/mm and so on - unless you really know that kernel will boot thereafter, instead, you have to manually resolve such conflicts). Resolve any other conflicts by resetting paths to the porting source (e.g. LK 3.5).
Note. While resetting with a paths is probably not the most accurate tehnique, but people don't live that long to use more accurate approach, e.g. performing git cherry-pick for every upstream commit and then manually resolving all the conflicts, you'll just sooner or later get bothered and will abandon it.
4) When you're done with the previous steps you can try building kernel. You'll likely have a build errors - because some part of a source got not updated (e.g. the device-specific drivers), you need manually implement the necessary by a higher kernel version changes. Firstly check if an upstream kernel contains the necessary fixes (example: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/9fae8c449b710f502662da1cbcf26ece5a098af9 , https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/fe027c25d6db0d100937deb5248e249ec5b24ee7 ). If the driver you are porting doesn't exist in the upstream, you can also try to find a similar change and mimic it: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/5f2e7afbf2ac3284dc62b3d96a0627c7f99ed4e9 ( ported similarly to https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/526c597 ). In the worst case scenario you will need to examine the upstream changes and apply the changes so that the drivers complies to the upstream changes: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/ea6432d167 .
5) If everything is done properly and you're lucky enough, the compiled kernel might already bootup. If not, you'll need to find a culprint that doesn't let the device to boot up. Switch to a copy of your kernel sources, reset the source to the base kernel version (e.g. LK 3.4), issue git bisect good, then issue git bisect bad lk-3.5, git will reset to a somewhere in a middle between of LK 3.4 and LK 3.5.
6) Save your changes in the kernel repo, by assigning a some branch to it, switch to the source base, merge all the fixes you've already introduced, then merge the revision you have got in the previous step by bisecting the tree. Repeat these steps until you'll find a first bad commit.
7) If you are already on this step, the most trickiest part starts here - testing (hopefully) working kernel for bugs (if any). While logs can be useful sometimes (so you can google the failing messages and find something useful), there are also many bugs you can find only performing git bisect tehnique decribed above.
The decribed algorithm only possible thanks to having a clean kernel source. The usage of this guide is not limited only to the kernel porting, it can be used on other projects as well, this is just what I've come across to, when I've ever started porting Linux kernel versions higher than LK3.4.
Reserved
I wonder if any of this expertise couldn't look pretty cool here too.
Wooooowwwewe
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Seriously!
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Wow, that's incredible
Exynos4412 already got some mainline support, it would be very nice to have this one supported too.
Aaaaand it's done, kinda.
ST-Ericsson NovaThor U8500 - postmarketOS
wiki.postmarketos.org
device/testing/linux-postmarketos-stericsson · master · postmarketOS / pmaports · GitLab
postmarketOS package build recipes
gitlab.com
Hello all,
Thanks to the PixelExperience-developers and @jeangraff30, this is my unofficial build containing the November-2021 security patches.
These are the build instructions I followed. For the last months, I have built the ROM like this, ever since 'ali' was dropped as an official PE device. To me, it seems very stable and complete. Battery consumption is not higher than normal.
Update: removed obsolete download links; please see the most recent posts in this thread. Thanks!
ZIP: PixelExperience_Plus_ali-11.0-20211109-0728-UNOFFICIAL.zip
MD5: PixelExperience_Plus_ali-11.0-20211109-0728-UNOFFICIAL.zip.md5sum
ASC: PixelExperience_Plus_ali-11.0-20211109-0728-UNOFFICIAL.zip.md5sum.asc
Known bugs:
- none so far
Known thing NOT included:
- Moto Actions (fingerprint gestures and more)
- 180 degrees display flip (upside down)
Disclaimer:
I am not an Android developer. For the moment, I'm not able to add, remove or tweak any features in this ROM.
My builds are as great as the PixelExperience- and upstream folks make the source code to be.
Please don't expect me to provide anything more than a regular build of PE11+. Android 12 will probably never become available for our device.
Kind regards,
FW
Hello all,
A small success has found its way into my Android building experience. I think I've successfully integrated "Moto Gestures" into this ROM. The user can now do the "chop-chop" to use the flash-light, and double-twist to turn on the camera. Other gestures are available, but I haven't tested them.
Please test and let me know whether the MotoGestures work as expected. See Settings -> System -> Advanced -> "Moto Gestures" ("Moto Acties" in Dutch).
I have not yet found a way to use fingerprint gestures. Any help in this would be appreciated.
Update: removed obsolete download links; please see the most recent posts in this thread. Thanks!
ZIP: PixelExperience_Plus_ali-11.0-20211127-1313-UNOFFICIAL.zip
MD5: PixelExperience_Plus_ali-11.0-20211127-1313-UNOFFICIAL.zip.md5sum
ASC: PixelExperience_Plus_ali-11.0-20211127-1313-UNOFFICIAL.zip.md5sum.asc
Thanks and kind regards,
FWieP
Hello all,
Thanks to the PixelExperience-developers and @jeangraff30, this is my unofficial build containing the December-2021 security patches.
These are the build instructions I followed. For the last months, I have built the ROM like this, ever since 'ali' was dropped as an official PE device. To me, it seems very stable and complete. Battery consumption is not higher than normal.
Update: Removed download links. Please see final post in this thread.
ZIP: PixelExperience_Plus_ali-11.0-20211216-0728-UNOFFICIAL.zip
MD5: PixelExperience_Plus_ali-11.0-20211216-0728-UNOFFICIAL.zip.md5sum
ASC: PixelExperience_Plus_ali-11.0-20211216-0728-UNOFFICIAL.zip.md5sum.asc
Known bugs:
- none so far
Known thing NOT included:
- Moto Actions (no fingerprint gestures, but flashlight gestures and proximity sensors work)
- 180 degrees display flip (upside down)
Disclaimer:
I am not an Android developer. For the moment, I'm not able to add, remove or tweak any features in this ROM.
My builds are as great as the PixelExperience- and upstream folks make the source code to be.
Please don't expect me to provide anything more than a regular build of PE11+. Android 12 will probably never become available for our device.
Kind regards,
FWieP
Dear all,
Today I have marked this thread as discontinued, and removed the links for its downloads. There has been no update or support on the Pixel Experience side since December 2021. It is no longer possible for me to build an up-to-date PE+ for our device.
Meanwhile, I've been building LineageOS 18.1 and LineageOS 19.1 for the ali-ROM each month, with up-to-date security patches. I'm very happy and satisfied with its functionality, stability and battery usage. Most importantly, so is my wife .
Thanks, see you around,
FWieP