Related
Hi And Welcome To a Non-Tested Version of Android 6.0.0 on the xoom (Maybe 5.1.1 Not Sure) But back to the topic
This is mostly 5.1.1 but maybe with new of fixed features (I've never tested it as I said)
Here is how to install (I found this on another area)
1. ROOT YOUR DEVICE
2. Install BigPart TWRP
3. Wipe your system and flash the zip file
Here is the zip file
(I'm having Issues of Attaching The File So Please Wait)
XDA:DevDB Information
Android 6.0.0 or Android 5.1.1, ROM for the Motorola Xoom
Contributors
MichaelTech, Schischu, dreamcwli, michie
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 2.6.x
ROM Firmware Required: Rooted BigPart
Based On: OmniRom
Version Information
Status: Alpha
Created 2015-11-19
Last Updated 2015-11-19
so is this rom 5.1.1 or 6.0? id love to try it out...
I just resurrected my old xoom and converted it to bigpart.
waiting for the zip....
Waiting for test it.
Did you build this rom? If so, how can you not know what version of Android it is?
MichaelTech said:
(I've never tested it as I said)
Here is how to install (I found this on another area)
Click to expand...
Click to collapse
Can you provide more information please?
Just "copy n paste" from "other area" is not very trustworthy... i'm sorry to say.
I would love to have 6.0 on Xoom, but I want it to be wit ha Git Repo or anything and not only an ominous zip file from somewhere...
so please, more information is the key!
sdthelord said:
Can you provide more information please?
Just "copy n paste" from "other area" is not very trustworthy... i'm sorry to say.
I would love to have 6.0 on Xoom, but I want it to be wit ha Git Repo or anything and not only an ominous zip file from somewhere...
so please, more information is the key!
Click to expand...
Click to collapse
Based on this post, I think that, best-case scenario, he just kanged Schischu's 5.1.1 build and maybe themed it to look like 6.0. But I'm betting we never see a zip file.
As with everyone else I am curious to this. [6.0.0/5.1.1(Not Sure)] <--- this seems a little strange. It can only be one Android version. If it's 5.1.1 with some cherry picks and tweaks, that's great but just say.
Also some source would be good so we can establish what it actually is. Upload to androidfilehost or something similar if you can't attach.
P.S OmniRom wanted me to make a rom so perfectly fine
MichaelTech said:
P.S OmniRom wanted me to make a rom so perfectly fine
Click to expand...
Click to collapse
Look we shouldn't be fighting about whos rom it is It's just code that matters
MichaelTech said:
Look we shouldn't be fighting about whos rom it is It's just code that matters
Click to expand...
Click to collapse
Here is the error I keep getting
vBulletin Message
Invalid post specified. This can happen for a variety of reasons-- most likely because the thread or post you are trying to view has been moved or deleted. Please return to the forum home and browse for another similiar post.
but nothing happened to this page so what is this problem
MichaelTech said:
Look we shouldn't be fighting about whos rom it is It's just code that matters
Click to expand...
Click to collapse
Speaking of ROM's, when can we expect yours? If the item you posted in #11 is still the zip attachment problem, have you thought about trying the suggestion from Matt4321?
brewer75 said:
Speaking of ROM's, when can we expect yours? If the item you posted in #11 is still the zip attachment problem, have you thought about trying the suggestion from Matt4321?
Click to expand...
Click to collapse
I can when you solve my problem I keep having
MichaelTech said:
I can when you solve my problem I keep having
Click to expand...
Click to collapse
The Download is now available in the downloads tab
here is info
Modified Launcher3
Modified SoundRecorder
Modified PackageInstaller
Android 5.1.1 with tweaks
gapps and super su are not included so please download them
If the OP did not do some coding on our outdated kernel and just synced omnirom sources, or even worse, just replaced some apk's in the flashable zip, all bugs are still there. If you did alter the kernel code you have to apply to GPL and post kernel sources.
I don't mean any disrespect but I kinda have the feeling that you don't have alot of experience with coding. (Please correct me if I'm wrong though) Posting untested software can give inexperienced users alot of problems and could be potential dangerous with our altered partion layout.
This wont have any benefit over Schisu's rom for now so I really have to advise you to wait for updated kernel sources before posting.
michie said:
If the OP did not do some coding on our outdated kernel and just synced omnirom sources, or even worse, just replaced some apk's in the flashable zip, all bugs are still there. If you did alter the kernel code you have to apply to GPL and post kernel sources.
I don't mean any disrespect but I kinda have the feeling that you don't have alot of experience with coding. (Please correct me if I'm wrong though) Posting untested software can give inexperienced users alot of problems and could be potential dangerous with our altered partion layout.
This wont have any benefit over Schisu's rom for now so I really have to advise you to wait for updated kernel sources before posting.
Click to expand...
Click to collapse
First yes that was very mean
second many other roms use these old kernels like OmniRom 5.1.1 for the xoom
third im a level 8 of 10 coder
Download not possible. File not found.
MichaelTech said:
First yes that was very mean
second many other roms use these old kernels like OmniRom 5.1.1 for the xoom
third im a level 8 of 10 coder
Click to expand...
Click to collapse
Like I said, I don't mean any disrespect my friend. The Xoom needs talented developers but not knowing if your rom is android 6 or 5 raises questions
You should contact the old member of team EOS or Schischu.
Good luck.
michie said:
Like I said, I don't mean any disrespect my friend. The Xoom needs talented developers but not knowing if your rom is android 6 or 5 raises questions
You should contact the old member of team EOS or Schischu.
Good luck.
Click to expand...
Click to collapse
I mostly belive its android 5.1.1
MichaelTech said:
im a level 8 of 10 coder
Click to expand...
Click to collapse
How many more XP do you need before you level up to 9?
What a joke...
CyanogenMod was brilliant for old devices. You could take CM9, tweak it around, and install it on something like the Galaxy Ace GT-S5830. You could breathe life into an old device.
Will there be older versions of LineageOS to accomplish the same thing? For example, an Android 4.2 Jelly Bean LineageOS? Or will it go no lower than Nougat 7.1?
Doofitator said:
CyanogenMod was brilliant for old devices. You could take CM9, tweak it around, and install it on something like the Galaxy Ace GT-S5830. You could breathe life into an old device.
Will there be older versions of LineageOS to accomplish the same thing? For example, an Android 4.2 Jelly Bean LineageOS? Or will it go no lower than Nougat 7.1?
Click to expand...
Click to collapse
Any device that was actively being developed when CM ended should be picked up by Lineage OS. If the device was no longer supported by CM, it is not likely to be supported now.
It goes back to 6.0.1 but no further.
It will do both, apparently.....
Someone appears to have updated the cm-12.1 branch, FWIW. I'm wondering if they're slowly working backwards.
Sent from my HTC One M8 using Tapatalk
MJPollard said:
Someone appears to have updated the cm-12.1 branch, FWIW. I'm wondering if they're slowly working backwards.
Click to expand...
Click to collapse
That would be my assumption since it's probably a lot easier to find people with knowledge to build CM13/12.1 than people with building knowledge for CM7 per say.
LilAnt530 said:
That would be my assumption since it's probably a lot easier to find people with knowledge to build CM13/12.1 than people with building knowledge for CM7 per say.
Click to expand...
Click to collapse
Funny you should say that, because I had to do just that very thing. I own an old phone (Motorola Atrix 4G) that never officially got support beyond CM7, so I've created my own custom CM7 for it (I'm using it as a glorified media player, but it's also allowed me to hone up on my Android ROM tinkering skills). When CM became LinOS, I created a Github organization (https://github.com/CM-Archive) to preserve the CM "gingerbread" branch, and found that there were a few things that need to be changed in order to make a clean compile. I'd offer to bring the "gingerbread" branch on LineageOS up to date for those few people who really need the CM7 code, as I've already done the work and know what needs to be changed, but as I've never made any contributions to CM or any ROM project, I don't know how to go about it. Can anyone tell me what I need to do? Something easy to follow, not "Get the frimfram and keloplotz the FTL missengibble on the gonfropple."
MJPollard said:
Funny you should say that, because I had to do just that very thing. I own an old phone (Motorola Atrix 4G) that never officially got support beyond CM7, so I've created my own custom CM7 for it (I'm using it as a glorified media player, but it's also allowed me to hone up on my Android ROM tinkering skills). When CM became LinOS, I created a Github organization (https://github.com/CM-Archive) to preserve the CM "gingerbread" branch, and found that there were a few things that need to be changed in order to make a clean compile. I'd offer to bring the "gingerbread" branch on LineageOS up to date for those few people who really need the CM7 code, as I've already done the work and know what needs to be changed, but as I've never made any contributions to CM or any ROM project, I don't know how to go about it. Can anyone tell me what I need to do? Something easy to follow, not "Get the frimfram and keloplotz the FTL missengibble on the gonfropple."
Click to expand...
Click to collapse
That's pretty epic dude! I have an LG Lucid vs840 from that had a CM9 out fot it was considering doing the same thing. As for helping them with their efforts I have no idea where to start.
But I do have a question, do you think it'd be very hard to update the cm7 cm9 or cm11 to Marshmallow devices? This might sound foolish but im still curious lol
The CM repo is moved wholesale to LineageOS, so if you know how to build, you could still build any version you like from the new source, provided that the older version was there previously in CM. I've built Lineage 13 (CM13) for several of my devices just now since I still need Xposed.
You can't expect any useful updates for <CM12.1 though, as CM had stopped working on them long ago. Not worth the extra effort of maintaining them, plus unfixable security holes.
Not looking to maintain them, simply to update them to compile from the LinOS repo. Specifically, the default.xml in the android package needs the references to CyanogenMod changed to LineageOS, and other references need to be changed as well. Once that's done, nothing further needs to be done.
Sent from my HTC One M8 using Tapatalk
Hi im looking for lineageOS 13.0-20170513-nightly-x2 this must be the last official version of that rom right?
i got it at my device but delete the zip and i dont found any working download link...
did someone got it for me please?
thx chris
jhedfors said:
Any device that was actively being developed when CM ended should be picked up by Lineage OS. If the device was no longer supported by CM, it is not likely to be supported now.
Click to expand...
Click to collapse
You say that, but there was CM for my old 2011 LG phone but I would be tremendously surprised if a LOS ROM ever shows up because there doesn't seem to be any active development for that device anymore. Makes me sad because I would love to have LOS on it (and security updates newer than 2012) but I wouldn't bank on it... the newest CM ROM I can find for it is from 2015.
This release is only tested on the SM-T560NU USA (gtelwifiue).
This kernel is based on vince2678's port of LineageOS, with a couple of updates and optimizations.
This kernel has only been tested with vince's cm14.1 releases.
Flashable zips use a modified version of the AnyKernel2 system. While only tested on cm14.1, it may work on other ROMs, since it does not modify your initrd.
Very special thanks to vince2678.
Without his effort on this device, this release would not be possible.
Updates:
2017-06-10:
First build for CM14.1
Features:
DriveDroid Mass Storage and CD-ROM Support
Built with gcc-linaro-4.8-2015.06-x86_64_arm-eabi toolchain
Additional CPU optimizations
Updated CPU assembly optimizations
Various security patches
XPad (xbox 360 and xbox one) gamepad support
Known issues:
None
How to Install:
1. Download the latest release zip
2. Transfer zip to your device (or skip this step if sideloading)
3. Reboot into TWRP Recovery [Volume Up+Home] (If you need TWRP, first install mine or vince2678's.)
4a. Find the zip in the TWRP install browser, and install it
-OR-
4b. Sideload the zip using adb.
5. Reboot to system and enjoy
How much faster is it with the new optimizations?
Standard Kernel (click for full benchmark):
Noire Kernel (click for full benchmark):
What does "dirty" mean?
Whenever you modify a git repo and do not commit the changes, it will flag the kernel as "dirty".
Rather than forking the git repo, I use a clean copy of vince's repo, then apply my patches over it.
Because this isn't really how git was designed to be used, the build system sees it as "dirty".
It is nothing to worry about, as it is not harmful in any way.
Getting the kernel
Releases can be found on my site. (Check the header on the download page for a link to the source directory for tools to build your own):
https://files.persona.cc/zefie/files/cell/SM-T560NU/kernel/cm14.1
If/when there are more than one release, the most recent release should be on top, but verify the Last Modified date to be sure of the latest release.
Also be aware you will need to reflash anytime you update the main CM14.1 OS, as it will overwrite the kernel.
Bugs and issues
As vince's CM14.1 release is a rolling release, depending on many different sources, unexpected issues may come up in either the upstream code, his code, or my code.
Before submitting any reports to vince, be sure you are using his kernel (reflash the cm zip without flashing mine, preferably with a clean install)
Before submitting any reports to me, be sure the issue is not caused by the current release of CM14.1 (aka doesn't happen when you try the above).
No warranty is implied or provided. Be sure to have backups before flashing. But this is a no-brainer.
bump, because new release and target (was cm13, now cm14.1)
This kernel helped me to finally have USB OTG working by default, great job! :good:
Can you give us more detailed info about optimizations? Does your kernel have any impact on battery life?
jon355 said:
Can you give us more detailed info about optimizations? Does your kernel have any impact on battery life?
Click to expand...
Click to collapse
I haven't tested thoroughly but they shouldn't.
The optimizations are some patches that update the arm assembly functions to use features available in our CPUs that were not previously used.
As well as compiling while telling the compiler that we are using a cortex-a53 (in armv7 mode) (by default it just compiled generic armv7 with old armv5/6 assembly).
In short, they aren't overclocks, just using more of the processor's full potential, which is already sitting there doing nothing. Therefore, it shouldn't have a huge impact on battery life.
The CPU patches are here: https://files.persona.cc/zefie/files/cell/SM-T560NU/kernel/common-source/cpu_opts.patch.xz
Fun fact: Our CPU is actually armv8 64-bit, but we can't use it because we depend on Samsung's proprietary binaries, which are compiled in 32-bit (armv7 mode)
Sm-t560 <> smt560nu
Hey,
I'd like to Install this ROM, but obviously i get the message that it's not supported for my Device (in TWRP on flash attempt)
Mine is from the EU so, probably why..
Any chance to get this ROM to work for it?
Akineesan said:
Hey,
I'd like to Install this ROM, but obviously i get the message that it's not supported for my Device (in TWRP on flash attempt)
Mine is from the EU so, probably why..
Any chance to get this ROM to work for it?
Click to expand...
Click to collapse
No.
Unfortunately, Samsung made several hardware changes, including the CPU, when they brought this device to the USA.
You could almost think of the SM-T560NU as the "SM-T560 New".
It is a newer model with revamped hardware, and thus not compatible with ROMs made for the other.
Sorry.
zefie said:
No.
Unfortunately, Samsung made several hardware changes, including the CPU, when they brought this device to the USA.
You could almost think of the SM-T560NU as the "SM-T560 New".
It is a newer model with revamped hardware, and thus not compatible with ROMs made for the other.
Sorry.
Click to expand...
Click to collapse
Alright, thanks for the Quick follow-up!
zefie said:
I haven't tested thoroughly but they shouldn't.
The optimizations are some patches that update the arm assembly functions to use features available in our CPUs that were not previously used.
As well as compiling while telling the compiler that we are using a cortex-a53 (in armv7 mode) (by default it just compiled generic armv7 with old armv5/6 assembly).
In short, they aren't overclocks, just using more of the processor's full potential, which is already sitting there doing nothing. Therefore, it shouldn't have a huge impact on battery life.
The CPU patches are here: https://files.persona.cc/zefie/files/cell/SM-T560NU/kernel/common-source/cpu_opts.patch.xz
Fun fact: Our CPU is actually armv8 64-bit, but we can't use it because we depend on Samsung's proprietary binaries, which are compiled in 32-bit (armv7 mode)
Click to expand...
Click to collapse
Great info. What optimizations were done on OTG mass storage? On stock LOS 14.1 kernel, USB OTG wasn't working for me while with your kernel it works flawlessly.
Jacsd said:
Great info. What optimizations were done on OTG mass storage? On stock LOS 14.1 kernel, USB OTG wasn't working for me while with your kernel it works flawlessly.
Click to expand...
Click to collapse
Honestly none of my patches do anything USB related, except DriveDroid, but that lets the tablet be a device (by hosting disk images), not anything to do with connecting a device to it. Therefore, I cannot take the credit for that. Vince must have fixed it in his kernel. I built this with the latest code at the time, code that may have been more recent than the last lineage build of his that you tried.
zefie said:
Honestly none of my patches do anything USB related, except DriveDroid, but that lets the tablet be a device (by hosting disk images), not anything to do with connecting a device to it. Therefore, I cannot take the credit for that. Vince must have fixed it in his kernel. I built this with the latest code at the time, code that may have been more recent than the last lineage build of his that you tried.
Click to expand...
Click to collapse
I tried latest build and a few older builds, on every I was stucked in the loop of mounting and unmonting USB device. I only managed to enable USB OTG when I installed StickMount. It seems Drive Droid does the same. Will you continue work on this kernel?
Jacsd said:
I tried latest build and a few older builds, on every I was stucked in the loop of mounting and unmonting USB device. I only managed to enable USB OTG when I installed StickMount. It seems Drive Droid does the same. Will you continue work on this kernel?
Click to expand...
Click to collapse
I'll update it if there are any necessary updates for performance or security, or any issues are found, but for now it seems fairly stable and should be alright for a while.
zefie said:
I haven't tested thoroughly but they shouldn't.
The optimizations are some patches that update the arm assembly functions to use features available in our CPUs that were not previously used.
As well as compiling while telling the compiler that we are using a cortex-a53 (in armv7 mode) (by default it just compiled generic armv7 with old armv5/6 assembly).
In short, they aren't overclocks, just using more of the processor's full potential, which is already sitting there doing nothing. Therefore, it shouldn't have a huge impact on battery life.
The CPU patches are here: https://files.persona.cc/zefie/files/cell/SM-T560NU/kernel/common-source/cpu_opts.patch.xz
Fun fact: Our CPU is actually armv8 64-bit, but we can't use it because we depend on Samsung's proprietary binaries, which are compiled in 32-bit (armv7 mode)
Click to expand...
Click to collapse
Tnx for detailed answer. Btw, I tested your LOS 13 build and it's very smooth and battery life is great. Only issue I encountered so far is when charging offline, screen doesn't go off and there is no charging percents showed. Also, can you sync with the latest LIneage changes? Can you replace stock browser with the Jelly and stock camera with the Snap camera?
jon355 said:
Tnx for detailed answer. Btw, I tested your LOS 13 build and it's very smooth and battery life is great. Only issue I encountered so far is when charging offline, screen doesn't go off and there is no charging percents showed. Also, can you sync with the latest LIneage changes? Can you replace stock browser with the Jelly and stock camera with the Snap camera?
Click to expand...
Click to collapse
The thread for that is over here:
https://forum.xda-developers.com/showthread.php?t=3632745
Also, I am unable to reproduce the issue with the screen not shutting off. There is no percentage, but my screen shuts off while locked when charger is plugged in. Percentage and timeout can probably be configured in settings. I sync with Lineage every update. An update will come sometime this month with July's security patches.
As for replacing stock apps, I'll look into it. As the thread says, this is mostly for my use, hence why it wasn't publicly announced before. If I find the apps useful I will see about integration.
Wondering if this is still supported?
zefie said:
The thread for that is over here:
https://forum.xda-developers.com/showthread.php?t=3632745
Also, I am unable to reproduce the issue with the screen not shutting off. There is no percentage, but my screen shuts off while locked when charger is plugged in. Percentage and timeout can probably be configured in settings. I sync with Lineage every update. An update will come sometime this month with July's security patches.
As for replacing stock apps, I'll look into it. As the thread says, this is mostly for my use, hence why it wasn't publicly announced before. If I find the apps useful I will see about integration.
Click to expand...
Click to collapse
From the title you can tell if this still works. For example will it work with official LineageOS and what not. Hoping to get a response so I can overclock my tablet
Bigority said:
From the title you can tell if this still works. For example will it work with official LineageOS and what not. Hoping to get a response so I can overclock my tablet
Click to expand...
Click to collapse
Should still work. I haven't messed with the SM-T560NU in a while. If I recall the Lineage build system was creating broken builds, I'm running 14.1-20171121-NIGHTLY-gtelwifiue and Noire Kernel still works with that.
As for newer builds, last time I tried (some time between xmas and new years), all of the more recent Lineage builds would not boot, with or without my kernel. If trying newer Lineage NIGHTLYs, try without my kernel first, then try with if it does boot.
Vince has kinda abandoned the SM-T560NU, although I'm not sure it is a fair reason to abandon us, because we didn't test on a completely different device, but his choice is his alone, and as such, without him working on Lineage, the newer builds are likely to stay broken unless either he comes back to fix it, or someone else takes over (don't look at me).
zefie said:
Should still work. I haven't messed with the SM-T560NU in a while. If I recall the Lineage build system was creating broken builds, I'm running 14.1-20171121-NIGHTLY-gtelwifiue and Noire Kernel still works with that.
As for newer builds, last time I tried (some time between xmas and new years), all of the more recent Lineage builds would not boot, with or without my kernel. If trying newer Lineage NIGHTLYs, try without my kernel first, then try with if it does boot.
Vince has kinda abandoned the SM-T560NU, although I'm not sure it is a fair reason to abandon us, because we didn't test on a completely different device, but his choice is his alone, and as such, without him working on Lineage, the newer builds are likely to stay broken unless either he comes back to fix it, or someone else takes over (don't look at me).
Click to expand...
Click to collapse
For it to work properly should I try your port of LINEAGEOS or should I try Vince's port of Cyanogen Mod?
Bigority said:
For it to work properly should I try your port of LINEAGEOS or should I try Vince's port of Cyanogen Mod?
Click to expand...
Click to collapse
This kernel is for vince's 14.1. My 13.0 already uses Noire kernel and this release should not be flashed with that
zefie said:
This kernel is for vince's 14.1. My 13.0 already uses Noire kernel and this release should not be flashed with that
Click to expand...
Click to collapse
Alright thanks
zefie said:
This kernel is for vince's 14.1. My 13.0 already uses Noire kernel and this release should not be flashed with that
Click to expand...
Click to collapse
The link isn't working to download the kernel :l
Edit: It was working just my internet was too ****ty too load it.
Ive been enjoying Resurrection Remix [Unofficial] rom and was wondering if they or any other rom for the Xperia Z5 P will support Oreo?
There is no kernel so unfortunately no
tset351 said:
There is no kernel so unfortunately no
Click to expand...
Click to collapse
???
zacharias.maladroit said:
???
Click to expand...
Click to collapse
Well there are no kernel sources nor binaries, blobs etc. so I guess there will no custom rom be available anytime soon but please correct me if I'm wrong. I would be glad to have Oreo on my Z5P.
tset351 said:
Well there are no kernel sources nor binaries, blobs etc. so I guess there will no custom rom be available anytime soon but please correct me if I'm wrong. I would be glad to have Oreo on my Z5P.
Click to expand...
Click to collapse
The developer seems to be busy so allow me to answer (though I'm not that experienced). I'm pretty sure that Sony always releases it's phone's kernel sources. Phone hardware doesn't change from an update so when the sources are released they can be used to create a kernel for any android version (basically developers need access to unique hardware). Blobs are like closed-source kernel modules. They're provided with the kernel source but the manufacturer doesn't want them to be copyrighted or tampered with. So I'm sure that Oreo will be available on your device, just give the developers some time. And please don't answer questions if you don't know what you're talking about (at least write that you're inexperienced).
Nik0laTesla said:
The developer seems to be busy so allow me to answer (though I'm not that experienced). I'm pretty sure that Sony always releases it's phone's kernel sources. Phone hardware doesn't change from an update so when the sources are released they can be used to create a kernel for any android version (basically developers need access to unique hardware). Blobs are like closed-source kernel modules. They're provided with the kernel source but the manufacturer doesn't want them to be copyrighted or tampered with. So I'm sure that Oreo will be available on your device, just give the developers some time. And please don't answer questions if you don't know what you're talking about (at least write that you're inexperienced).
Click to expand...
Click to collapse
I am a very inexperienced person.
For MSM8994 platform there is only 3.10 kernel sources available, at least on sony's developer page. On open devices resource list, there are binaries for Z5 premium for 5.1, 6.0, 6.0.1, 7.0 and 7.1 but unfortunately no 8.0 or 8.1. And well, developers can take their time - as long as they want because I don't use that cell phone anymore and I won't expect any custom Rom changes anytime soon especially for a 2015 Device which had very less development going on since its launch.
But once again, I am very inexperienced.
Nik0laTesla said:
The developer seems to be busy so allow me to answer (though I'm not that experienced). I'm pretty sure that Sony always releases it's phone's kernel sources. Phone hardware doesn't change from an update so when the sources are released they can be used to create a kernel for any android version (basically developers need access to unique hardware). Blobs are like closed-source kernel modules. They're provided with the kernel source but the manufacturer doesn't want them to be copyrighted or tampered with. So I'm sure that Oreo will be available on your device, just give the developers some time.
Click to expand...
Click to collapse
Ok, sorry I got a bit mixed up in the devices :laugh:. Either way Snapdragon provides up to date documentation on their SOC's (which is the most important hardware component on the device) so developers should still be able to provide Oreo. And you are right the Z5 premium is an old device and support usually drops as soon as the developer gets rid of that device. But it's weird how much attention different devices get. For example I have a Oneplus X (SD801, I know it's ancient) (didn't even get Nougat) and there are multiple Oreo 8.1 ROMs available.
Hi guys.
I have some questions about the new android treble feature.
The way it is advertised, it seems to be the END of the fragmentation problem on android. But i dont know if it is over advertised.
1) "The A/B partition system is only for seamless update."
I've read this on the internet and the only difference between A and A/B is that A will update like older androids while A/B will be with the phone turned on with only a reboot being necessary. This shouldn't be something that will make treble more or less useful for the end-users.
2) Why I dont see people talking about system repartitioning the phone to enable A/B partition? Most phones have 32GB, with most being over 20GB in /data. Why not just repartition 1GB to enable A/B partition?
3) "The treble updates will still be released by the phone's manufaturer."
Really? I dont know if the updates are comming from google or phone manufacturer. Can someone confirm?
It does not make any sense to try to stop the fragmentation issue by still leaving the update task on the manufacturer's side...
After some time they will stop updating anyway.
4) "Android treble will be useless if the phone does not come with native treble support."
I really don't understand this. Ive read this in reddit I believe. But installing a custom treble supported rom wouldn't be easier to perform updates on the custom rom?
My thoughts are that the updates are going to be handled by google. By doing so, we could install any custom rom and forget it because "google will update it from now on". This makes sense to me. If treble is not heading to this, then they are doing it wrong...
IMO, I think that treble would be great if users could perform:
Get your old android phone's manufaturer proprietary files;
Save those files in a vendor folder;
Execute them in android 8 and on;
Leading every android device to the latest android version.
(This in a perfect world. I know this option is a dream.)
BUT, I believe this could be an option at least for the devices that received the oreo update (because they received the "updated proprietary files" that would work for the new android treble and by consequence, on all new android versions.
If so is true, the best that could happen is for custom rom devs, create their roms by packing the vendor files, integrating with AOSP and linking the updates from the google server. Done, phone will be "forever updated".
Any comments on those, please?
Thank you.
facsi2 said:
Hi guys.
I have some questions about the new android treble feature.
The way it is advertised, it seems to be the END of the fragmentation problem on android. But i dont know if it is over advertised.
1) "The A/B partition system is only for seamless update."
I've read this on the internet and the only difference between A and A/B is that A will update like older androids while A/B will be with the phone turned on with only a reboot being necessary. This shouldn't be something that will make treble more or less useful for the end-users.
2) Why I dont see people talking about system repartitioning the phone to enable A/B partition? Most phones have 32GB, with most being over 20GB in /data. Why not just repartition 1GB to enable A/B partition?
3) "The treble updates will still be released by the phone's manufaturer."
Really? I dont know if the updates are comming from google or phone manufacturer. Can someone confirm?
It does not make any sense to try to stop the fragmentation issue by still leaving the update task on the manufacturer's side...
After some time they will stop updating anyway.
4) "Android treble will be useless if the phone does not come with native treble support."
I really don't understand this. Ive read this in reddit I believe. But installing a custom treble supported rom wouldn't be easier to perform updates on the custom rom?
My thoughts are that the updates are going to be handled by google. By doing so, we could install any custom rom and forget it because "google will update it from now on". This makes sense to me. If treble is not heading to this, then they are doing it wrong...
IMO, I think that treble would be great if users could perform:
Get your old android phone's manufaturer proprietary files;
Save those files in a vendor folder;
Execute them in android 8 and on;
Leading every android device to the latest android version.
(This in a perfect world. I know this option is a dream.)
BUT, I believe this could be an option at least for the devices that received the oreo update (because they received the "updated proprietary files" that would work for the new android treble and by consequence, on all new android versions.
If so is true, the best that could happen is for custom rom devs, create their roms by packing the vendor files, integrating with AOSP and linking the updates from the google server. Done, phone will be "forever updated".
Any comments on those, please?
Thank you.
Click to expand...
Click to collapse
1) A/B devices also have a thing called "skip_initfs". In older devices, which is indeed A-only, we have the kernel ramdisk in boot partition. But in A/B devices, the boot ramdisk is only for recovery - when booting the system, the system actually contains the initramfs instead and it gets mounted to / (rootfs) instead of /system.
In short, A/B devices have init and ramdisk all in the system partition. This means Treble ROM's for A/B devices can easily have their own initfs, which makes things a little easier.
2) It also needs bootloader (either SBL or ABOOT, can't remember) support for AB, and these are almost never open source.
3) Treble allows OEM's (the hardware, e.g. Qualcomm) and the ODM (the brand, e.g. Xiaomi) to work independently. Treble provides a contract that the ODM and OEM must each pass verification black-box style, allowing independent development without reliance on the other. Best analogy I can think of is how drivers for Windows work - they don't need to know about what edition of Windows or model of PC it is; they just need to follow standards when making their hardware drivers - and if they do they can be sure that it should work with any other software.
Theoretically, Android P GSI should work straight away on a Treble-enabled Oreo phone. Maybe only with minimal changes - still too early to say. But this is the idea of it.
4) Not entirely true. Unofficial Treble (e.g. like we did for Mi A1) allows us to use GSI's thanks to Phh's work. And unlike many other official Treble devices, we have 100% compatibility with GSI's thanks to the fact that that we can fix GSI stuff on our own end. Many Treble devices are not properly "GSI-ready" vendor implementations, a common theme is that they still put essential Camera stuff in their system ROM instead of vendor (Treble verification I guess doesn't care about Camera support, sadly).
Updates from Google directly is a different program entirely; that's only for devices in Android One program.
Treble support with blobs from before Oreo is practically impossible. They need to be either modified and recompiled with the VNDK standards, or a very smart person needs to shim them. Don't ever expect a pre-Oreo device without source code to be Treble compatible - it's a monumental task that basically requires reverse-engineering the proprietary blobs. If you don't find that useful, then those are the breaks - this stuff was only introduced relatively recently. Treble is not a time machine
But again: Treble does NOT mean "updates directly from Google". That's only for official Android One devices.
Maybe one day Google will have an official thing akin to GSI. But not today. As it is, GSI - generic Treble ROM's - are the love child of Phh, there is no such thing as official updates directly from Google outside of Android One (and Pixel ofc).
As for your other speculation, it's mostly redundant - apparently, all devices that launch with Android P are required to have Treble. If I remember correctly. If the pre-P device is popular and open enough, then yeah you will get unofficial Treble (like we did with Mi A1). But that's all up to the device community. But just to reiterate one more time - this does NOT mean updates will come directly from Google.
In case you're wondering why the updates won't come directly from Google (and I predict that this will never be the case, outside of Android One program devices) - simple fact is because Android != Google. Google will never force Android vendors to use Google servers or update channel because Android itself is a very open platform; Treble is an architectural change regarding HAL abstraction - not an enforcement of Google doctrine. It'd be absurd if they did pull a stunt like that; would be like GNU saying "hey Ubuntu, Debian, and all you other guys - you have to use GNU update servers now, all your own servers are not allowed".
Many thanks, Dan. The smart thing to do is hope a new good phone gets released with latest android. Then we can keep if for a longer time thanks to treble. Planned obsolescence sucks.
Just for the curiosity, I own a moto z play and a galaxy s5 (just because of the IR blaster).
facsi2 said:
Many thanks, Dan. The smart thing to do is hope a new good phone gets released with latest android. Then we can keep if for a longer time thanks to treble. Planned obsolescence sucks.
Just for the curiosity, I own a moto z play and a galaxy s5 (just because of the IR blaster).
Click to expand...
Click to collapse
I have to say I am very glad I got the Mi A1. They did take a while to release the source code, but being an Android One device it was already "Treble-ready" - the HAL and vendor files were already binderized, as per requirements for Treble (that's the most difficult part in getting a Treble device).
My next device may be the A2, or a Pixel, it really depends on how long I keep this device (probably a while yet, since it's definitely getting P officially even).
And yeah, being a Xiaomi, they always have IR
CosmicDan said:
In case you're wondering why the updates won't come directly from Google (and I predict that this will never be the case, outside of Android One program devices) - simple fact is because Android != Google. Google will never force Android vendors to use Google servers or update channel because Android itself is a very open platform; Treble is an architectural change regarding HAL abstraction - not an enforcement of Google doctrine. It'd be absurd if they did pull a stunt like that; would be like GNU saying "hey Ubuntu, Debian, and all you other guys - you have to use GNU update servers now, all your own servers are not allowed".
Click to expand...
Click to collapse
I think in google (Android) updates being sent by google itself as it is the one who releases android security patches.
I took a look on Mi A1. it only misses NFC. I might wait another year to change my phone.
thanks
facsi2 said:
I think in google (Android) updates being sent by google itself as it is the one who releases android security patches.
I took a look on Mi A1. it only misses NFC. I might wait another year to change my phone.
thanks
Click to expand...
Click to collapse
What do you mean? Security updates can't be sent directly from Google, because every device is different and usually heavily modified at the source code level.
The whole point of Android One is that they are relatively pure, bit they still need to compile seperate security updates for different devices.
In short, there's no such thing as generic firmware, every firmware and therefore every update is still device-specific. Excluding GSI of course, which is not an official thing remember.
True about NFC, I never used it so forgot.
CosmicDan said:
What do you mean? Security updates can't be sent directly from Google, because every device is different and usually heavily modified at the source code level.
The whole point of Android One is that they are relatively pure, bit they still need to compile seperate security updates for different devices.
In short, there's no such thing as generic firmware, every firmware and therefore every update is still device-specific. Excluding GSI of course, which is not an official thing remember.
True about NFC, I never used it so forgot.
Click to expand...
Click to collapse
Isnt google responsible for those security updates in a general ROM and then manufacturers have to port that update for their devices?
https://source.android.com/security/bulletin/
What I meant was with treble, we could update our android directly from google, without having to wait for the manufacturer. Pretty much as how windows update work.
facsi2 said:
Isnt google responsible for those security updates in a general ROM and then manufacturers have to port that update for their devices?
https://source.android.com/security/bulletin/
What I meant was with treble, we could update our android directly from google, without having to wait for the manufacturer. Pretty much as how windows update work.
Click to expand...
Click to collapse
Yes, that's how they work.
But no, we cannot. As I said multiple times already - there is no such thing as a generic device to Google. GSI is created by Phh. Generic updates simply do not exist.
If Google ever makes an official GSI of some sort, or Phh works with someone to make an OTA system for his GSI's, then it could happen. But I wouldn't hold my breath for either of those things - the first one I already explained why it isn't feasible yet, and the second one costs too much money.
CosmicDan said:
Yes, that's how they work.
But no, we cannot. As I said multiple times already - there is no such thing as a generic device to Google. GSI is created by Phh. Generic updates simply do not exist.
If Google ever makes an official GSI of some sort, or Phh works with someone to make an OTA system for his GSI's, then it could happen. But I wouldn't hold my breath for either of those things - the first one I already explained why it isn't feasible yet, and the second one costs too much money.
Click to expand...
Click to collapse
I am confused. What is android AOSP rom then?
facsi2 said:
I am confused. What is android AOSP rom then?
Click to expand...
Click to collapse
https://en.m.wikipedia.org/wiki/Android_(operating_system)#AOSP
Read the "Development" paragraph. The following "Update schedule" section goes on the explain the history and situation of how updates work, basically the same as what I've already said.
got it. Many thanks.
Treble will be really useful for the users.
Btw, do you know if the source code released for moto z play the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP...
facsi2 said:
got it. Many thanks.
Treble will be really useful for the users.
Btw, do you know if the source code released for moto z play the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP...
Click to expand...
Click to collapse
Useful for users and developers!
I don't know what you mean by that question. By "same update" do you mean repartition for Treble?
CosmicDan said:
Useful for users and developers!
I don't know what you mean by that question. By "same update" do you mean repartition for Treble?
Click to expand...
Click to collapse
I ended up editing the phrase before sending it and I didn't fully checked it:
Do you know if the source code released for moto z play IS the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP
What I am asking is if the source code available for Moto z play have the contents to be able to port treble as you did on mi a1. I don't know by looking the contents on GitHub, if the code available is complete for that job.
Thanks
facsi2 said:
I ended up editing the phrase before sending it and I didn't fully checked it:
Do you know if the source code released for moto z play IS the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP
What I am asking is if the source code available for Moto z play have the contents to be able to port treble as you did on mi a1. I don't know by looking the contents on GitHub, if the code available is complete for that job.
Thanks
Click to expand...
Click to collapse
To port Treble to a device, these things are needed:
1) All the source code required to build standard AOSP, e.g. device tree and kernel. If you already have custom ROM's working f well for you device, this will likely be true.
2) Binderized vendor HAL. If you have *official* Oreo update from Motorola, this MAY be true. Manual inspection of compatibility_matrix.xml is required here, if everything in there matches the Treble requirements as listed on Android Developers then chances are it is ready.
3) An unused partition of ~500MB or more for Vendor, or the ability to repartition the device (many Qualcomm devices are standard GPT partitioned eMMC these days, if it is then it's possible).
That's a summary of the requirements. Obviously some technical investigation is required. Forward that info to any device developers who are interested in the project.
I read somewhere that device to be even updated to Pie have to have enabled Treble? Oreo required it only for launched devices and Pie require it from ALL devices.
Is it right or not? Unfortunately I cannot find it again
CosmicDan said:
To port Treble to a device, these things are needed:
1) All the source code required to build standard AOSP, e.g. device tree and kernel. If you already have custom ROM's working f well for you device, this will likely be true.
2) Binderized vendor HAL. If you have *official* Oreo update from Motorola, this MAY be true. Manual inspection of compatibility_matrix.xml is required here, if everything in there matches the Treble requirements as listed on Android Developers then chances are it is ready.
3) An unused partition of ~500MB or more for Vendor, or the ability to repartition the device (many Qualcomm devices are standard GPT partitioned eMMC these days, if it is then it's possible).
That's a summary of the requirements. Obviously some technical investigation is required. Forward that info to any device developers who are interested in the project.
Click to expand...
Click to collapse
About re-partitioning android device, is there a tool, command or anything universal to all the phones, like how in linux you can re-partition what and how you want. For example, I never saw a re-partition "mod" for samsung devices (ex. to give more space on /system). There is only one reason I can think of.
If samsung "download mode" is stored on a read-only pre-programmed chip, then re-partition should be no problem. If anything goes wrong, just flash stock firmware with CSC or flash official .PIT file.
If that is the case then there are no risks in re-partitioning a device.
There is a tool that can edit .PIT files, but what if someone wipes the bootloader partition?
Would "download mode" still be there for a roll-back, or would the device be permenantly bricked?
Is re-partition-ing safe?
If it is, then why doesn't any 3rd party recovery have an option for that, kinda like GPARTED. Is it impossible or what?
And if bootloader gets wiped, is there a way to re-program the device to the working order?
Sry for so many questions. Already tried to search but never got a straight-forward answer.
Shadow7107 said:
About re-partitioning android device, is there a tool, command or anything universal to all the phones, like how in linux you can re-partition what and how you want. For example, I never saw a re-partition "mod" for samsung devices (ex. to give more space on /system). There is only one reason I can think of.
If samsung "download mode" is stored on a read-only pre-programmed chip, then re-partition should be no problem. If anything goes wrong, just flash stock firmware with CSC or flash official .PIT file.
If that is the case then there are no risks in re-partitioning a device.
There is a tool that can edit .PIT files, but what if someone wipes the bootloader partition?
Would "download mode" still be there for a roll-back, or would the device be permenantly bricked?
Is re-partition-ing safe?
If it is, then why doesn't any 3rd party recovery have an option for that, kinda like GPARTED. Is it impossible or what?
And if bootloader gets wiped, is there a way to re-program the device to the working order?
Sry for so many questions. Already tried to search but never got a straight-forward answer.
Click to expand...
Click to collapse
No, nothing is standard when it comes to embedded systems (which our devices are). By "standard on Linux", you must mean "Standard on x86-based Linux" - which is mostly all MBR or GPT (but even then there are other less-common standards)
But as I said - many Qualcomm devices are in fact standard GPT, you can just use gdisk (a fork of fdisk which is better choice for GPT partition maps).
Repartitioning is relatively safe on SOME devices because they have an emergency bootloader/downloader which is on it's own EEPROM and not the eMMC or whatever. You will have to research the device for yourself to see if it has any "unbrick" capability. Again, many qualcomm devices have what is called "EDL mode" - EDL mode is still possible even if you "cat /dev/null > /dev/block/mmcblk0" for example - albeit you may need to disassemble the device to access test point to get it to be kicked into there.