Related
Without the inclusion of proper documentation included with an Android Rom or an Android Build users will start filling up the HD2 Android Development Forum with why this wont work when it does on someone elses Rom. To stop this from happening there will be a requirement when creating a Thread for a Rom with Android included, or an Android Build.
------------------------------------------
------------------------------------------
If you are making a Rom with Android built in or an Android Build that is run from haret then please INCLUDE with your file a readme.txt file in the ROOT of your release archive with the following information:
*What BUILD version?
An internal version # that can be used to identify the authors exact release (e.g. my-rom-v0.5.zip) for easier reference for the users and fellow developers benefiting from the release.
*Which kernel image and kernel modules are used?
Where are zImage and modules.ko originally downloaded (in case the chef didn't compile on their own) and where is the kernel source code for the kernel and modules.
In case the chef did not compile on his own, he should still be able find out where the source code is.
(The license under which the Linux kernel is released requires the distribution of the source code that was used when distributing builds.)
*What rootfilesystems are used?
Where was it taken from, what does it include (android version it's based on etc) and in case of self compilation, where is the source code.
(In case of most windows mobile shipped devices that's often some rootfs file e.g. named android.ext2 and an initial ram filesystem often named initrd.cpio.gz).
*ChangeLog*
A ChangeLog is really an essential addition in every build as it informs the end user what modifications have been made from the last build. This will save you ALOT of questions as to what has been added, deleted or modified and therefore is a requirement for everyones benefit.
*WindowsMobile version your Android Build was tested on*
Please include your WinMo Build version, HTC OemDrivers (if known), XIP (if known) and Radio version so that users know what the Android Build was tested on and can replicate if neccessary for fault finding purposes.
------------------------------------------
------------------------------------------
If you are unable to obtain any of this information and thus can't make it available through an included readme.txt you should not distribute your rom and keep it for personal use only.
If you are using an exact copy of a present release (e.g. in case of a WinCE rom that has an android 'dual boot' option) you must include the readme.txt from the original rom chef.
If you release a Rom and do not have the required information then you will be asked to either create and include a readme.txt file with your Rom or ask for the thread to be deleted.
If you have any comments or questions on this please feel free to post.
Mark.
** reserved **
Thanks a lot for the quick action, Mark. I am glad to see a first positive response.
If this will establish I hope that
*users are informed about what they get
=>less unneeded questions and thus more room for constructive feedback
*developers have an easier time to benefit from present releases
*new developers must try to get an understanding of what they are doing
=>more quality releases
The original post can be found here.
I think it would be nice to hammer out the readme.txt requirements together with chefs so we can get some convention that satisfies everybody.
edit: Think it will really be good to always put readme.txt in root of release archive so everybody knows where to look for it.
dcordes said:
edit: Think it will really be good to always put readme.txt in root of release archive so everybody knows where to look for it.
Click to expand...
Click to collapse
Edited the 1st post to include this
Mark.
Will be following this convention for any future releases
DarkStone1337 said:
Will be following this convention for any future releases
Click to expand...
Click to collapse
Thank you
Future releases soon I hope lol
Mark.
May I suggest that the readme include the date of ROM compilation, as well as the date the kernel and root file systems files. I think this will help users and chefs to easily build there own compilations and keep track of it's validity.
And a title format like: [date]-[name]-[version]-{[kernel]-[kerneldate]}-{[modules]-[modules-date]}-[rootfs] (just like rules for 'regular' roms). Both for the post and the archive preferably?
Personally I switch between versions a lot, to find differences/improvements/bugs.
Clear archive-naming should simplyfy this .
Excellent rules! We need to improve stability of ports and eliminate all unnecessary questions !
P.S. Hope there won't be any "bogus", or "copy-paste-claim" ROM-s.
dcordes an mskip +1
ahbad said:
May I suggest that the readme include the date of ROM compilation, as well as the date the kernel and root file systems files. I think this will help users and chefs to easily build there own compilations and keep track of it's validity.
Click to expand...
Click to collapse
Very good idea. I think we should at least add the rom release date to minimum required readme.txt information.
For the rootfs release date I think we should leave it up to the chefs because I think it will be hard to find out in many cases. Reason is rootfilesystems get passed on 20 times...
In case of the kernel release date it might be a good idea to add it. should be easy to find out. When you grab the kernel e.g. from the two sources I link to in the thread
http://oe.netripper.com/files/htcleo_autobuild/
http://cotulla.pp.ru/leo/Android/
you can just copy paste the date from filename or information on the site. This would be very useful assuming the kernel images will be removed at some point.
On a side note: For both kernel examples the source code repository to add in readme.txt is
git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git htc-msm-2.6.32
gitweb: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-msm-2.6.32
So currently in every leo rom readme.txt this must be linked to as kernel source reference. netripper autobuild zImages using this exact source code and cotulla zImages share same codebase (although currently the latest changes are unavailable but will be added in git soon)
shufflez said:
And a title format like: [date]-[name]-[version]-{[kernel]-[kerneldate]}-{[modules]-[modules-date]}-[rootfs] (just like rules for 'regular' roms). Both for the post and the archive preferably?
Personally I switch between versions a lot, to find differences/improvements/bugs.
Clear archive-naming should simplyfy this .
Click to expand...
Click to collapse
To me that seems over exaggerated. Rom version in file name should be enough. Rest can be looked up in readme.txt
So what does everybody think? If we add the release date of kernel and completed rom, do we have an agreement ? In that case we should compile an example and add it in the first post.
best regards
your right dcordes too much information in the title can be a bad thing. Something more like
[Date] [Name] [Version] [Build] [maybe Kernel version]
That should be Enough i think so for Example
[21/07] [Darkstone1337] [v5] [Eclair w/sense] [2.6.32]
Everything else should stay a change log for people to read
David Balfour said:
your right dcordes too much information in the title can be a bad thing. Something more like
[Date] [Name] [Version] [Build] [maybe Kernel version]
That should be Enough i think so for Example
[21/07] [Darkstone1337] [v5] [Eclair w/sense] [2.6.32]
Everything else should stay a change log for people to read
Click to expand...
Click to collapse
I am sticking with my opinion:
*in filename require internal chef rom version
*in readme.txt add:
-rom release date
-kernel release date
Mark what do you think? Any other opinions?
Install to folder
May be a good idea install all files to appropriate folder, not directly root of SDcard as in last darkstone FROYO. Greatly simplify process of testing and changes between several images and don't messy root. Switching between different versions is than as easy as renaming directory.
I think we should also leave directory structure etc to the chef as long as readme.txt with all the required information exists in archive root so users can find it easily.
so do we have some agreement here? Mark ? If so you should update the first post to compile final set of information needed and clarify that it is not a nice extra but a requirement.
dcordes said:
I am sticking with my opinion:
*in filename require internal chef rom version
*in readme.txt add:
-rom release date
-kernel release date
Mark what do you think? Any other opinions?
Click to expand...
Click to collapse
I agree with you on this theres no need to make things more complicated than they need to be. Although there does need to be some sort of standard for the thread title.
And no I cant think of anything else right now that needs to go in.
dcordes said:
I think we should also leave directory structure etc to the chef as long as readme.txt with all the required information exists in archive root so users can find it easily.
so do we have some agreement here? Mark ? If so you should update the first post to compile final set of information needed and clarify that it is not a nice extra but a requirement.
Click to expand...
Click to collapse
Also agree that its upto the chef how they want their files set up as long as its clearly stated in the readme.txt what to do to get it working.
Everything sounds fine What needs adding to the first post to make it complete?
Sorry I have been working on my Loader but its all finished now (I hope).
Mark.
HD2 Android Image & Instructions
Hi All,
Can somebody confirm if there is a working Android image for the HD2 yet? From reading previous threads, it would seem there is still some technical challenges, no image is available yet.
If I am wrong, please could somebody tell me the location of an image and instructions so I can install Android on my HD2? I am struggling with WM6.5 and I much prefer Android. I have used WM for 9-years now but it just doesn't compare - partially because there are limited decent apps available.
All the best,
Youdaler
youdaler said:
Hi All,
Can somebody confirm if there is a working Android image for the HD2 yet? From reading previous threads, it would seem there is still some technical challenges, no image is available yet.
If I am wrong, please could somebody tell me the location of an image and instructions so I can install Android on my HD2? I am struggling with WM6.5 and I much prefer Android. I have used WM for 9-years now but it just doesn't compare - partially because there are limited decent apps available.
All the best,
Youdaler
Click to expand...
Click to collapse
I will just give you a friendly warning this time as it is your first post. This thread is for the discussion of information to be included by Android builders.
If you look in the Android forum then you will see working builds by DarkStone and by Dan1j3l. Look at their threads for how to load Android. to answer your question yes Android does work (95%) on the HD2.
Please confirm you have read this so I can delete these posts and keep the thread clean. In futured please only post in the correct thread and if you arent sure then post in the Q&A thread at the top of the Android forum.
Mark.
Understand. Thanks for clarifying.
I think we should extend the readme.txt items with some section like 'expected issues' or 'known problems' .
And in the readme.txt , could help too:
Tested with:
-WinMo rom x.xx.xx
-Radio rom 2.xx.xx
Sent from my HTC Desire using XDA App
Starship Kernel is being developed in conjunction with the not yet posted Starship Rom. Like I had done with the KK incarnation of the Starship Rom I am also posting the Kernel separately for anyone who may not like the Rom's Theme. Though unlikely as that may sound because I have spent much time and effort with the Kernel am posting the Kernel separately so it can be used with other Roms and not just Starship.
If you are looking for new features to play with this will not be the Kernel for you. It is designed to improve the overall experience as if it was not there. At this point and probably never you wont find over clocking or voltage controls to play with but rather just a more efficient overall experience.
Each Kernel Download section contains a link to the commit list for both the purpose of following rules about posting links to Kernel Sources as well as serving as a change log. You will find in the main branch all Linux Kernel Increment Updates are grouped into one commit. This is to easily distinguish what commits have been made as part of the Linux Kernel Increment Updates from other additions/optimizations that are not part of the Linux Version Updates. You can find descriptions of each change made as part of the Increment Updates in the staging branch. In other words the second link below the download links will give a description off the changes made in the Linux Version Updates .
Downloads
AOSP/Stock (Android Version 5.1.1)
AOSP/Stock Kernel is compiles using Google's GCC 4.8 toolchain and tested tested on the Stock 5.1.1 Rom as well as AOSP compiled Rom using unmodified pure 5.1.1 Source code. The Kernel may or may not work on custom Roms based on 5.1.1 depending on what changes have been made by the Roms developer and how far the Rom has strayed from the original source code. In most cases if the Rom is AOSP based the Kernel will work but provide no guarantee as am not testing with every ROM available. If you do find a Rom the Kernel does not work with feel free to comment but please include what Kernel was used that did not work as I may be able to shed light on reasons why and provide a workaround if possible. Most of incompatibility will find that the Kernel is not the issue rather what is included inside the boot.img like Ramdisk iinit.rc files that set permissions and create the Rom file-system.
Starship-lollipop-5.1_Kernel-3.4.91_r1
https://www.androidfilehost.com/?fid=24052804347767806
Starship-lollipop-5.1_Kernel-3.4.88_r1
https://www.androidfilehost.com/?fid=24052804347766347
Starship-lollipop-5.1_Kernel-3.4.86_r1
https://www.androidfilehost.com/?fid=24052804347760505
Starship-lollipop-5.1_Kernel-3.4.83_r1
https://www.androidfilehost.com/?fid=24052804347756685
Source / Change-log
https://github.com/Starship-Android/android_kernel_lge_hammerhead-starship/commits/lollipop
Including individual explanation of changes included as part of Linux version increment update patches.
https://github.com/Starship-Android/android_kernel_lge_hammerhead-starship/commits/lollipop_staging
CM-12.1
CM-12.1 Kernels may be updated more frequently without posting a new date so don’t be surprised to see multiple release number increments. In most cases there has been no change in the Kernel itself but update frequently as development is fast moving. Because of this some of the files that get packaged into the boot.img along with the Kernel may change and cause issues. Because of this will update as frequently as I can to insure everything packaged into the boot.img is up to date.
Starship-CM-12.1_Kernel-3.4.88_r1
https://www.androidfilehost.com/?fid=24052804347766796
Starship-CM-12.1_Kernel-3.4.86_r1
https://www.androidfilehost.com/?fid=24052804347760507
Starship-CM-12.1_Kernel-3.4.80_r1
https://www.androidfilehost.com/?fid=23991606952613802
Source / Change-log
https://github.com/Starship-Android/android_kernel_lge_hammerhead-starship/commits/cm-12.1_staging
Donations
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=MMEVCWUX83SXJ
I am not responsible for any effect using the downloads from this forum my have on any device and you download and use at your own risk.
Just decided to include the CM-11 Kernel for anyone who may be using CM-11. Is a nice Kernel and gave me an extra hour or two battery so recompiling with a few new commits I have been using in both CM-12 & AOSP. Will post in a few. Checking nothing else may have changed on the CM side with the rest of the boot.img and will post in a bit.
I will try out the AOSP kernel tonight or tomorrow, we are under blizzard conditions right now and can't mess with phone because of work (boss & I texting back and fourth)
Thanks for your work
Sent from my rooted RCT6203W46 using xda-dev app
Downloading now!
Sent from my Nexus 5 using XDA Free mobile app
rickballs said:
Downloading now!
Sent from my Nexus 5 using XDA Free mobile app
Click to expand...
Click to collapse
Sorry about this then but have uploaded an update. I had intended on holding off until reaching Linux version 3.4.40 as it is the version I had left off with for Kit-Kat and have just been modifying each version increment patch from the Kit-Kat 3.4 Kernel for Lollipop. Anyhow last night before bed had used my Bluetooth Headset with the current version and sounded like I had gone out and bought a brand new higher end set so decided to post the update now. Found in the past Android can have a completely different experience when it comes to different BT devices like for example the same headset had become completely unusable on my N7 with constant skips and pauses on 4.4.4 after working beautifully on 4.4.3 so hope others can hear the same boost in overall audio quality including BT headsets.
Updated Kernels with a few new optimizations and 3.4.36 version update
Ok will try it
Can't download from devhost. Anyone else is having problema?
gengi said:
Can't download from devhost. Anyone else is having problema?
Click to expand...
Click to collapse
Looks to be up and running. Can try direct links though.
updated so links are no longer current.
Well it feels like with all the side track projects been talking Starship L long enogh maybe some of those who have sent PM's asking about the lollipop update are starting to become doubters so decided to post up a few screen shots. Was going to finish a few things then go over the theme image by image and color by color but think instead after finishing up a few things will post and then start going over each apk over again for touching up, fixing and adding missed optimizations including Kernel updating along the way. Once again not for everyone so haters can hate and I just keep doing it because its what I like doing.
Made new boot.img for Stock / AOSP 5.1.0 as old image used in 5.0 - 5.0.2 caused boot loops.
The MultiROM not work with this kernel? :-O
dado70 said:
The MultiROM not work with this kernel? :-O
Click to expand...
Click to collapse
Honestly have been meaning but have not tried MultiROM. Looked over at the thread and see allot of mention about the boot.img and modifications. If I had to guess with the limited knowledge I have would say if not working is not so much the Kernel but the boot.img in the same way that both the Stock / AOSP zips posted are the same exact Kernel inside but changes made to files like the init.rc inside the 5.1.0 boot.img that creates the file system and sets permissions among a score of other things caused 5.1.0 from booting properly after updating and flashing the boot.img. As developers we use the name Kernel but there is much more inside than the actual Kernel. In some cases can be more than a dozen other scripts and other files inside. Will need to try and learn a bit about MultiROM. Out of curiosity was it Stock or CM giving you issues?
Little more reading and looks like not everyone including CM has updated to include new bootloader version checks to include new bootloader from the 5..1.0 update. So for example I needed to change the bootloader version in CM source or nightly builds will not flash in TWRP without errors.
Maybe an update on this if flashing CM version, seems latest CM12 is receiving errors flashing with some recovery versions and must be installed via adb / fastboot. Article was not specific on the reason but may be the cause.
Added updates to version 3.4.42 for both 5.1.0 and under. The 5.0.2 zip should work for all stock and AOSP Roms from 5.0 - 5.0.2. Because of changes in 5.1.0 boot.img 5.1.0 will not boot when used with a lower Android Version.
Slightly disappointed as today had planned on posting full Starship Rom but now updating for 5.1.0 so maybe another week maybe two
So any details on what this kernel does? Or is our just close to stock?
CM12 Kernel is on hold until 5.1.0 version update. No reason testing anything new until can confirm everything will still work next week. Also figures the same week I had planned on posting the full Starship Rom the 5.1.0 update hit so now am back in testing optimizing phase for a bit longer.
3.30.2015 update
Linux version has been updated to version 3.4.55
All MR1 changes added to the 5.1.0 AOSP Kernel have been merged into the Kernel
https://github.com/Starship-Android...mmit/8ed8c47ff15f1c5fdd6707f7a52f76110aed6cbf
4.6.2015 update
Not much on the AOSP/Stock side. Wanted to post a cm12 update so decided to post the AOSP/Stock kernel earlier than I would normally with a few Linux version update patches. With that said updating the Kernel only takes a minute or so and not like asking to flash a new Rom. Kernels are easy and these days faster to flash than g-apps. Also used the 5.1.0_r3 source to compile the boot image for 5.1 instead of 5.1.0_r1 source I had been using. Honestly though did not check if anything changed that is packed into the boot.img along with the Kernel between r1 & r3 so may or may not make any difference what so ever.
Forgot, marked the cm-12.1 kernel as beta just because cm-12.1 is pretty much beta. Otherwise the Starship 12.1 Kernel is the Starship CM12 Kernel merged with the Cyanogen 12.1 Kernel . Not that the two had been far apart to start but the 12.1 CM Kernel merged into the Starship cm12 kernel clean as a whistle with 0 conflicts. Was pretty happy about that so going foreword will just be working on the 12.1 Kernel with the Starship cm-12 Kernel soon going the way of the 5.0 - 5.0.2 Stock/AOSP Starship Kernels.
Now finally since the actual Starship Rom I have been working on since the darn preview release ending as mostly caf based with CM-12.1 coming together can start updating from 5.0.2 into 5.1 as had just finished going over the first draft and was about to post when the 5.1 update hit. Otherwise wanted to post the first draft and then go over the entire Rom a second time looking over the theme images, features and optimizations with a magnifying glass.
Have updated both Stock / AOSP and cm-12.1 Kernels up to Linux 3.4.65 with a few other additions and weeding. Has and been running pretty sweet on both so far.
Stock / AOSP 3.4.65 Kernel boot.img has been compiled using the 5.1.1 AOSP Source and tested on both 5.1.0 & 5.1.1 with no issue and as mentioned above running pretty sweet.
I cant install on aicp 5.1.1
Sent from my Nexus 5 using XDA Premium HD app
Introduction:So I see you have found my Android M Preview ROM thread. So... You all might of seen this. It's Sony announcing that it's AOSP open line of Xperia devices can now build Android M and is showing devs how to build it. Apparently things aren't exactly that way. Google created under it's source code, an alpha branch for the upcoming Android M, what that branch contains is mostly Android Lollipop code and some Android M stuff. This branch will evolve to become Android M, but at it's current state, the ROM is in between Android lollipop and M (kind of a weird mix of a sort that's why the build number is 5.1.51 and the easter egg is the one of lollipop). I will however provide weekly (hopefully) builds of Android M as it becomes more M than L. Keep in mind that the current release of the ROM (as of 25-6-2015) does not contain the new API's (for devs that are interested). You can see Sony's official explanation here. If you are still interested though in checking out the current state of Android M be my guest though keep in mind that in it's current state it is FAR from a daily driver (modem and camera are the most major of bugs currently) and most if not all of the cool features on Android M developer preview for the Nexus line probably are not currently included (as on 25-6-15).
Warning
This works only on UNLOCKED BOOTLOADERS. Keep in mind that the ROM was built for the D6603 I don't know if it will work with any other variant of the Z3. In addition flashing this might erase recovery on some devices. Also I take no responsibility of whatever may happen by using this ROM.
Downloads (please read the Introduction if you haven't, its important )Kernel
System
Userdata
Installation:1. Backup EVERYTHING (Your SD card included. This ROM has proven to be unpredictable as of storage on some handsets).
2. Download the Kernel, System and Userdata images
3. Get yourself a working ADB/Fastboot installation (more on that on the kernel page)
4. Flash the kernel as described on it's page (Steps 1-7)
5. While still in fastboot mode enter these commands in the command prompt:
Code:
fastboot flash system (directory of system image)
fastboot flash userdata (direcotry of userdata image)
6. Reboot your device and wait for it to start up
Bugs:
Graphical Glitches
Camera
Modem (no phone calls/messages/data etc.)
Bluetooth
Random Force Closes in most Apps
Recents (some times)
Random other stuff
Erases all storage (internal and external) on some handsets
Screenshots:
Here you go.
Credits:
The rest of team Pear Crew
akateha
My Family & Friends
Sony and it's AOSP project
XDA
Google
Changelog:
----- Build I -----
Initial release.
Synced the latest android-m-preview branch
Most Android M features completely missing, ROM is like a hybrid of Lollipop&M
Bugs:
Graphical Glitches
Camera
Modem (no phone calls/messages/data etc.)
Bluetooth
Random Force Closes in most Apps
Recents (some times)
Random other stuff
I can't believe what you just posted
Hahaha @Griffiths_Anna why so?
@CedArctic
it may be that the flashing the rom erase the baseband
have you tried to reinstall a baseband after flash the rom?
@Gustavo RD78
Actually I haven't, even Sony states that Camera & Modem are guaranteed broken. Even if the modem was fixed (which I believe it will in the next few weeks) the ROM still needs a lot of work for all the other bugs. Although about the baseband, I think M requires a special version of the baseband because even when you flash the official M preview over the Nexus 5, you have to flash a new baseband that is compatible with Android M. I am currently away from my Z3 but if someone tries it out and confirms it working I would gladly add it to the main thread.
Wow, that was fast, need i say more??
@corpsegrinder62 Actually, considering the announcement date it is fast. I dualbooted my PC with linux just 36 hours ago, downloaded the sources and compiled... XD
Gustavo RD78 said:
@CedArctic
it may be that the flashing the rom erase the baseband
have you tried to reinstall a baseband after flash the rom?
Click to expand...
Click to collapse
Some modem components are stored on /system and not included for legal reasons in Sony's AOSP binary releases. https://github.com/SuperBenevolent/aosp-vendor-qcom-proprietary
At least with L-MR1, the ONLY things missing for modem to work are the blobs above. Dunno about M, I'm not bothering to mess with it until official M release.
Woaw, nice to see android m being worked on even though it's in its early stages.
Is that my build you are running?
Installed a few minutes ago. Thank you for compiling the source code.
Am I wrong or can´t I flash GApps?
Edit: Also I cannot use any storage. Not internal and not sd card
@Silveryard Yeah there are like lots of bugs... I hope some will be solved in the future. Storage is definetely one of them. I never tried to flash gapps though
It´s because some .apk files (like the play framework) cannot be installed with adb install command and require a custom recovery kernel or root or root for writing permissions in "system"
I don´t know much about compiling a system image but is it possible to place the gapps files into the right folder right before compiling everything in one file? This would help much and would make this preview much more usable in daily life.
Thank you! I'll be trying this on my D6653.
Made an installation video.
How To: Flash Android M Alpha for Xperia Z3: https://youtu.be/rJgYnqv3ZPM
Good news
CedArctic said:
@Silveryard Yeah there are like lots of bugs... I hope some will be solved in the future. Storage is definetely one of them. I never tried to flash gapps though
Click to expand...
Click to collapse
http://forum.xda-developers.com/and...v-android-m-apps-framework-deodexing-t3166000
@squabbi Cool bro @M-Rom Congrats for your work bro, I saw the FlyMe OS port... simply loved it... although I'm curious how did you port it? Because I tried to do so in the past... @Aaahh I'll take a look into it. I think storage is just the storage-list.xml in the framework.... Thanks for the guide
CedArctic said:
@squabbi Cool bro @M-Rom Congrats for your work bro, I saw the FlyMe OS port... simply loved it... although I'm curious how did you port it? Because I tried to do so in the past... @Aaahh I'll take a look into it. I think storage is just the storage-list.xml in the framework.... Thanks for the guide
Click to expand...
Click to collapse
What? I'm not sure what your talking about
Just to repeat, those are the actual M preview apps and I "fixed" them so that you can add them to your rom
@Aaahh you posted a quote of me about storage and I said now that I think I know that the issue is in the storage-list.xml in the framework. I will include your apps in the next build, but for now I am focusing on a different project until M becomes more stable...
Even though I get security updates for my Android Devices, I see the kernel version almost never changes. Recently, I have heard of an old kernel security bug that allowed anyone to get the root access (dirty COW) was finally fixed. That is, virtually *all* Android devices are critically vulnerable, right?
For example, if this kind of serious kernel bug was fixed on October 2016, and later I get a security update and the device shows Android Security Patch Level has become something like "10 November 2016", does this guarantee the kernel bug found before that date has been fixed? Or does it only mean the bugs in Android itself have been fixed?
Since the kernel version usually never changes even after installing Android updates, I wonder if the kernel version stays the same when kernel bugs are fixed. Or I should just give up and buy new devices?
Hi Guys hope you r donig well ♥
and suggestions about a stable rom & kernel for my 2gb version
i don't play pubg or games , only use my phone for camera and social media
i do prefer N roms cuz most of the people say that pie still have some issues
thanks for your time guys ♥
Citrus-caf obviously. Though it's a little bit old, i.e. Dec, 18. Nevertheless, it's the most stable among all. It's the only Pie rom for kenzo having SE Linux enforcing. Flash it with orangefox recovery and opengapps 64 bit nano package. Good luck.
Stabe and Up-to-date Custom ROM for Redmi Note 3, meet /e/!
Mo'men Hesham said:
Hi Guys hope you r donig well
and suggestions about a stable rom & kernel for my 2gb version
i don't play pubg or games , only use my phone for camera and social media
i do prefer N roms cuz most of the people say that pie still have some issues
thanks for your time guys
Click to expand...
Click to collapse
Hi Mo'men Hesham,
I strongly suggest /e/OS, from eFoundation (for Redmi Note 3 - kenzo)
Characteristics:
1. Stable (android 7/nougat);
2. Secure (latest security patch, SELinux enforcing, Phone Encryption)
3. Frequent updates (built-in updater);
4. Official nightly builds (on gitlab);
5. Privacy oriented (Privacy Guard, MicroG, ...);
6. Elegent & consistent experience;
7. Optional online services & a welcoming community.
Useful links
/e/OS ROM download: https://images.ecloud.global/dev/kenzo/
Insall instruction: https://gitlab.e.foundation/e/wiki/en/wikis/device/kenzo/install
/e/ project: https://e.foundation/
awalis said:
Hi Mo'men Hesham,
I strongly suggest /e/OS, from eFoundation (for Redmi Note 3 - kenzo)
Characteristics:
1. Stable (android 7/nougat);
2. Secure (latest security patch, SELinux enforcing, Phone Encryption)
3. Frequent updates (built-in updater);
4. Official nightly builds (on gitlab);
5. Privacy oriented (Privacy Guard, MicroG, ...);
6. Elegent & consistent experience;
7. Optional online services & a welcoming community.
Useful links
/e/OS ROM download: https://images.ecloud.global/dev/kenzo/
Insall instruction: https://gitlab.e.foundation/e/wiki/en/wikis/device/kenzo/install
/e/ project: https://e.foundation/
Click to expand...
Click to collapse
/e/ has this nasty bug that powers down the device at certain battery percentage, highly unstable. Also kernel (stock LineageOS 14.1) hasn't been updated in years which makes this security oriented ROM unsecure.
Hello n0b0dy666,
n0b0dy666 said:
/e/ has this nasty bug that powers down the device at certain battery percentage
Click to expand...
Click to collapse
I never experienced that bug on /e/ so far, my battery goes as down as 1% very often without any issue (which is terrible for its longevity actually)
n0b0dy666 said:
highly unstable
Click to expand...
Click to collapse
in my experience at least, it is very stable. I was on Havoc OS before, which wasn't that stable.
n0b0dy666 said:
Also kernel (stock LineageOS 14.1) hasn't been updated in years
Click to expand...
Click to collapse
Could you elaborate on that kernel issue please?
note that at the the present time, the "Phone Status" screen displays the following:
Kernel version: 3.10.105-lineageos-g92430f1a110 .... Fri Jul 5 02:59:21 UTC 2019
and
Android security patch level: june 5, 2019
Regards,
awalis said:
Hello n0b0dy666,
I never experienced that bug so far, my battery goes as down as 1% very often without any issue (which is terrible for its longevity actually)
in my experience at least, it is very stable. I was on Havoc OS before, which wasn't that stable.
Could you elaborate on that kernel issue please?
note that at the the present time, the "Phone Status" screen displays the following:
Kernel version: 3.10.105-lineageos-g92430f1a110 .... Fri Jul 5 02:59:21 UTC 2019
and
Android security patch level: june 5, 2019
Regards,
Click to expand...
Click to collapse
I was referring to the battery bug as being unstable. It's a bug within stock kenzo LineageOS 14.1 kernel which /e/ is powered by. Which takes me to the security part; there are system level patches, which are up to date, no problem with that and kernel level patches. Kernel was last updated (not built, different thing) on November 2017, which makes your device vulnerable to some serious exploits.
n0b0dy666 said:
I was referring to the battery bug as being unstable. It's a bug within stock kenzo LineageOS 14.1 kernel which /e/ is powered by.
Click to expand...
Click to collapse
Oh, now I see what you mean. I used to have that issue for a while back when I was on Lineage OS, but after I replaced my two years old battery, that behavior stopped completely! so I just put the blame on the battery age.
n0b0dy666 said:
there are system level patches, which are up to date, no problem with that and kernel level patches. Kernel was last updated (not built, different thing) on November 2017, which makes your device vulnerable to some serious exploits.
Click to expand...
Click to collapse
Thank you for the explanation, I just looked it up. So the Linux kernel 3.10.y reached its End Of Life almost two years ago! and the date displayed on "Settings > About phone" is just the actual building date. Well that's a serious security flaw related to the vendor/device itself, whatever the Custom ROM one chooses to install.
That being said, and if the OP still wants to keep his device, /e/OS is a right choice compared to the other Custom ROMs, for the remaining reasons stated in my first reply.
Cordially,