Now that Android O developer preview has dropped. I feel like the devs should drop working on 7.1.2 and just go straight to Android O when they create an AOSP branch on it. Any devs planning on doing that?
That will almost be impossible as with 7.1.2 Android O will be 64 bit. Porting back to our 32 bit device will be next to impossible
zelendel said:
That will almost be impossible as with 7.1.2 Android O will be 64 bit. Porting back to our 32 bit device will be next to impossible
Click to expand...
Click to collapse
Ok, so what's next, after 7.1.1 in AOSP for our Shamu? Nothing?
gothy.gothy said:
Ok, so what's next, after 7.1.1 in AOSP for our Shamu? Nothing?
Click to expand...
Click to collapse
Android O is only in Dev preview stage. The code is bound to change and the full code is not there for us to compile. So if anyone actually are going to try then they are going to build a messy hacked build and have to start all over again when next preview comes. Best is to wait until Android O launched at fall when the final code gets pushed to aosp and that's the right time for developers to work on Android O for our Shamus. In short, now is not the right time.
gothy.gothy said:
Ok, so what's next, after 7.1.1 in AOSP for our Shamu? Nothing?
Click to expand...
Click to collapse
No one is sure. It very well maybe the last AOSP we see. It will still be worked on i am sure but I doubt we will see anything past it for the shamu. This is why many devs have moved to other devices like the 6p or the 3t.
Arju said:
Android O is only in Dev preview stage. The code is bound to change and the full code is not there for us to compile. So if anyone actually are going to try then they are going to build a messy hacked build and have to start all over again when next preview comes. Best is to wait until Android O launched at fall when the final code gets pushed to aosp and that's the right time for developers to work on Android O for our Shamus. In short, now is not the right time.
Click to expand...
Click to collapse
No, not about the time I asked, but the possibility to have Android O, doesn't matter when.
I asked what will be after 7.1.1.
---------- Post added at 11:21 PM ---------- Previous post was at 11:19 PM ----------
zelendel said:
No one is sure. It very well maybe the last AOSP we see. It will still be worked on i am sure but I doubt we will see anything past it for the shamu. This is why many devs have moved to other devices like the 6p or the 3t.
Click to expand...
Click to collapse
Well, it is a pity, because it's a very good device!
@gothy.gothy We will probably see Android O through the unofficial route and I'm sure the Nexus 6 will live to see another year, but further than that it's hard to predict. Zelendel is right that it will only get harder and harder by time and when apps only starts supporting 64bit and looses support for 32bit then we're out of the game. We might get a sloppy hack of a build but loose app support in future major updates after Android O. So the best would be to move to a device that runs 64bit.
rester555 said:
Now that Android O developer preview has dropped. I feel like the devs should drop working on 7.1.2 and just go straight to Android O when they create an AOSP branch on it. Any devs planning on doing that?
Click to expand...
Click to collapse
No developers are "working" on 7.1.2 (except maybe a few brave kernel developers), because the source isn't pushed to AOSP until the final release.
zelendel said:
That will almost be impossible as with 7.1.2 Android O will be 64 bit. Porting back to our 32 bit device will be next to impossible
Click to expand...
Click to collapse
I don't mean to start a flame war, but this just isn't right. There has been no effort to "remove" 32-bit support. In fact, the Nexus Player is still a 32-bit device (albeit x86) which is supported by O, it may be 64-bit hardware, but due to proprietary firmware, they decided to have the 2nd-stage bootloader, and kernel/user-space boot in 32-bit mode. It has the O preview out now. Plus the 32-bit toolchains still get active support, and even 64-bit devices (i.e. angler/marlin) run some amount of arm(32) code in the form of their proprietary firmware/libraries, so we'll always need the ability to run 32-bit code on Android, and therefore, not stripping 32-bit compatibility from Android.
Also, there haven't been any specific moves by Google in terms of AOSP source away from 32-bit support.
gothy.gothy said:
Ok, so what's next, after 7.1.1 in AOSP for our Shamu? Nothing?
Click to expand...
Click to collapse
I'd bet just about any amount of money the Nexus 6 will see O once source drops.
zelendel said:
No one is sure. It very well maybe the last AOSP we see. It will still be worked on i am sure but I doubt we will see anything past it for the shamu. This is why many devs have moved to other devices like the 6p or the 3t.
Click to expand...
Click to collapse
Why would O be the last AOSP we see? Android is mostly licensed under GPLv3, so they have to release source (that compiles) for the large majority of android. If you're refereeing to the fushcia OS they are creating, according to git logs, it is to be used on intergrated system's, as the kernel they wrote is very minimal.
My apologies gentlemen, I thought that AOSP was pushed on each developer preview. I didn't realize that it doesn't hit the AOSP Branch until the final build.
rester555 said:
My apologies gentlemen, I thought that AOSP was pushed on each developer preview. I didn't realize that it doesn't hit the AOSP Branch until the final build.
Click to expand...
Click to collapse
Hence why you look silly putting up this thread...
npjohnson said:
No developers are "working" on 7.1.2 (except maybe a few brave kernel developers), because the source isn't pushed to AOSP until the final release.
I don't mean to start a flame war, but this just isn't right. There has been no effort to "remove" 32-bit support. In fact, the Nexus Player is still a 32-bit device (albeit x86) which is supported by O, it may be 64-bit hardware, but due to proprietary firmware, they decided to have the 2nd-stage bootloader, and kernel/user-space boot in 32-bit mode. It has the O preview out now. Plus the 32-bit toolchains still get active support, and even 64-bit devices (i.e. angler/marlin) run some amount of arm(32) code in the form of their proprietary firmware/libraries, so we'll always need the ability to run 32-bit code on Android, and therefore, not stripping 32-bit compatibility from Android.
Also, there haven't been any specific moves by Google in terms of AOSP source away from 32-bit support.
I'd bet just about any amount of money the Nexus 6 will see O once source drops.
Why would O be the last AOSP we see? Android is mostly licensed under GPLv3, so they have to release source (that compiles) for the large majority of android. If you're refereeing to the fushcia OS they are creating, according to git logs, it is to be used on intergrated system's, as the kernel they wrote is very minimal.
Click to expand...
Click to collapse
This is where you are mistaken. Android isn't under the GPL. Only the kernel is. Android is under the apache license. Google doesn't have to push any code for Android at all. They could completely stop. Or keep doing what they started with the 6p and that is make the system files like system ui closed sourced.
You really have not been paying attention much. Just look at the last issues the nexus had with the updates. Not to mention not getting all of the stuff in the update that the 62 bit devices got.
zelendel said:
This is where you are mistaken. Android isn't under the GPL. Only the kernel is. Android is under the apache license.
You really have not been paying attention much. Just look at the last issues the nexus had with the updates. Not to mention not getting all of the stuff in the update that the 62 bit devices got.
Click to expand...
Click to collapse
Apologies for the typo there. GPLv3 (which requires source release) ==> Apache (which does not). As you noted though, kernel sources are GPLv3.
I really have been paying attention though. I too wondered why the Nexus 6 didn't get Nougat as quickly, and why the 6P's 7.1.2 updates were delayed. If you do some static disassembly/analysis on the Nexus 6's proprietary blobs (in specific, take a look at the prebuilt qcom binaries, like qmuxd and mm-qcamera and the date they were signed), you can deduce that the reason we saw a delayed 7.1.1 (and 7.0 for that matter) on the Nexus 6 was because QCOM either had issues with the specific hardware peripherals related, or just wasn't keen on working on them. An issue that isn't strictly related to 32-bit support, because we saw the same exact issue with Angler on the initial 7.1.2 Beta release (some blobs which are pre-signed being dated barely before the build date). Plus the Nexus 6 itself was never intended to be a Nexus phone. In an interview with one of the Engineer's who worked on the Nexus 6, they stated that there initially was another manufacturer who backed out last minute, forcing them to use the Moto X Pro shell that shipped in China (the hardware is identical + an IR sensor for Moto Display), so Google hasn't ever been to keen on the Nexus 6.
And, what are you referring to that 64-bit devices got that the Nexus 6 didn't? Other than some of the gestures, I don't see it. The 6, 6P, and 5x all got Assistant (well, everyone did), with 7.1.1, they all got gesture support (the 6 is missing one, I think double-tap to wake? And that's because it never worked reliably on the 6's display panel without significant battery repercussions). None of the Nexus series devices got Pixel Launcher (officially at least), but they're all capable of side-loading it (i.e. no 64-bit only libraries), and none of the Nexus series got the Pixel style navigation bar, but I suppose those two could be written off as 'Pixel Exclusives', and are 32-bit agnostic anyway.
One more shining example of 32-bit getting updates just fine is the Android One program, which contains a boatload of currently supported devices (many of which are expected to get O), many of which are not only 32-bit, but MediaTek powered (unrelated, but still interesting).
npjohnson said:
Apologies for the typo there. GPLv3 (which requires source release) ==> Apache (which does not). As you noted though, kernel sources are GPLv3.
I really have been paying attention though. I too wondered why the Nexus 6 didn't get Nougat as quickly, and why the 6P's 7.1.2 updates were delayed. If you do some static disassembly/analysis on the Nexus 6's proprietary blobs (in specific, take a look at the prebuilt qcom binaries, like qmuxd and mm-qcamera and the date they were signed), you can deduce that the reason we saw a delayed 7.1.1 (and 7.0 for that matter) on the Nexus 6 was because QCOM either had issues with the specific hardware peripherals related, or just wasn't keen on working on them. An issue that isn't strictly related to 32-bit support, because we saw the same exact issue with Angler on the initial 7.1.2 Beta release (some blobs which are pre-signed being dated barely before the build date). Plus the Nexus 6 itself was never intended to be a Nexus phone. In an interview with one of the Engineer's who worked on the Nexus 6, they stated that there initially was another manufacturer who backed out last minute, forcing them to use the Moto X Pro shell that shipped in China (the hardware is identical + an IR sensor for Moto Display), so Google hasn't ever been to keen on the Nexus 6.
And, what are you referring to that 64-bit devices got that the Nexus 6 didn't? Other than some of the gestures, I don't see it. The 6, 6P, and 5x all got Assistant (well, everyone did), with 7.1.1, they all got gesture support (the 6 is missing one, I think double-tap to wake? And that's because it never worked reliably on the 6's display panel without significant battery repercussions). None of the Nexus series devices got Pixel Launcher (officially at least), but they're all capable of side-loading it (i.e. no 64-bit only libraries), and none of the Nexus series got the Pixel style navigation bar, but I suppose those two could be written off as 'Pixel Exclusives', and are 32-bit agnostic anyway.
One more shining example of 32-bit getting updates just fine is the Android One program, which contains a boatload of currently supported devices (many of which are expected to get O), many of which are not only 32-bit, but MediaTek powered (unrelated, but still interesting).
Click to expand...
Click to collapse
If you look close at the one program, it was an epic fail. They seldom see an update. MTK bweing the main reason they dont get updates. Just ask anyone where andoid one is even sold. Many never even saw a single update.
If you look at the official software that was pushed (not what was pushed to AOSP as they are different) to the pixel you will notice things like the system ui being different as google now closed alot of that off.
Delayed/. You mean delayed, pushed, pulled and then reuploaded. Even with things still broken on the n6. I mean even the latest update for it disabled saftynet checks for the nexus 6 as a workaround for the changes in the code that didnt convert properly from 64bit to 32bit.
You have to understand that google doesnt care about anything older. All they are worring about is the pixel line now.
rignfool said:
Hence why you look silly putting up this thread...
Click to expand...
Click to collapse
I don't think I look silly at all. Based on the conversation on the thread. I think it was a good discussion.
It's still possible for Nexus 6 to see Android 8.0 but it's now more of a chicken and egg issues. As for Android 7.1.2, I am sure it's still officially a hybrid build as well. All we can do is wait and see what's in Android 8.0 Oreo source code this early winter.
As for Nexus player, I doubt they locked Long Mode out of firmware, it's impossible because the kernel can call the stack register required for a jump from Protected Mode (32-bit) into Long Mode (64-bit) directly, no matter what (yes, even in MS-DOS). It's up to Google to decide if Nexus Player stay in 32-bit mode - I bet Android 8.0 will allow it to enter Long Mode this time, with the Long Mode option enabled in Linux kernel - only CPU-Z app will tell you whether it's running in 64-bit mode.
we believe in great developers like in lineageOS they are still supporting nexus 4 and nexus 5 without any problems with regularly updates , but if android o is 64 bit that will be the pain
Dr. Mario said:
It's still possible for Nexus 6 to see Android 8.0 but it's now more of a chicken and egg issues. As for Android 7.1.2, I am sure it's still officially a hybrid build as well. All we can do is wait and see what's in Android 8.0 Oreo source code this early winter.
As for Nexus player, I doubt they locked Long Mode out of firmware, it's impossible because the kernel can call the stack register required for a jump from Protected Mode (32-bit) into Long Mode (64-bit) directly, no matter what (yes, even in MS-DOS). It's up to Google to decide if Nexus Player stay in 32-bit mode - I bet Android 8.0 will allow it to enter Long Mode this time, with the Long Mode option enabled in Linux kernel - only CPU-Z app will tell you whether it's running in 64-bit mode.
Click to expand...
Click to collapse
Well, I wish this was right, but the 2-nd Stage Bootloader (a LittleKernel derivative) runs in strictly 32-bit mode, and we are unable to load any 64-bit kernel's, plus, several device firmwares for the Nexus Player (as provided by Intel) are strictly 32-bit, and don't work in 64-bit contexts.
zelendel said:
If you look close at the one program, it was an epic fail. They seldom see an update. MTK bweing the main reason they dont get updates. Just ask anyone where andoid one is even sold. Many never even saw a single update.
If you look at the official software that was pushed (not what was pushed to AOSP as they are different) to the pixel you will notice things like the system ui being different as google now closed alot of that off.
Delayed/. You mean delayed, pushed, pulled and then reuploaded. Even with things still broken on the n6. I mean even the latest update for it disabled saftynet checks for the nexus 6 as a workaround for the changes in the code that didnt convert properly from 64bit to 32bit.
You have to understand that google doesnt care about anything older. All they are worring about is the pixel line now.
Click to expand...
Click to collapse
Several of the One program's phones like, seed, seed2, general mobile 4g, have all not only been hosted on Google's factory image page, and some even got updates much faster than the Nexus 6 did (comical, and ridiculous I agree, but 32-bit non-the-less).
And, with the Pixel's I would agree that Google close sources several app (SystemUI, Frameworks-res, etc.) but it is worth questioning a few things:
1) If they'd given the Nexus's those apps, don't you suppose there'd be some backlash from owners who bought the phone because of its open source nature? The Pixel's made no promise of that.
2) Are the small features they contain even worth it? A blue color scheme (when the old teal is arguably more visually appealing), circular icons (which many hate), and a Night Light Overlay (this is useful, but requires a new hardwarecomposer setup that the 6P just doesn't have, and all the 3rd party/flashable solutions fall back to using a GL shader and the device's battery/performance takes a noticeable compared to the Pixels implementation).
And, as for the SafetyNet check disabling, though Android Police said that, there is literally no proof. The check tokens are still sent, and verified server side, and if you're rooted, the device still fails the authentication. AP threw out some unsubstantiated information. No deivce side-change was needed on the Nexus 6, so they re-uploaded the same factory image, and made a server side change. And nowhere was anything said about it being 64 ==> 32-bit code incompatibility. Do you have any source on that?
npjohnson said:
Well, I wish this was right, but the 2-nd Stage Bootloader (a LittleKernel derivative) runs in strictly 32-bit mode, and we are unable to load any 64-bit kernel's, plus, several device firmwares for the Nexus Player (as provided by Intel) are strictly 32-bit, and don't work in 64-bit contexts.
Several of the One program's phones like, seed, seed2, general mobile 4g, have all not only been hosted on Google's factory image page, and some even got updates much faster than the Nexus 6 did (comical, and ridiculous I agree, but 32-bit non-the-less).
And, with the Pixel's I would agree that Google close sources several app (SystemUI, Frameworks-res, etc.) but it is worth questioning a few things:
1) If they'd given the Nexus's those apps, don't you suppose there'd be some backlash from owners who bought the phone because of its open source nature? The Pixel's made no promise of that.
2) Are the small features they contain even worth it? A blue color scheme (when the old teal is arguably more visually appealing), circular icons (which many hate), and a Night Light Overlay (this is useful, but requires a new hardwarecomposer setup that the 6P just doesn't have, and all the 3rd party/flashable solutions fall back to using a GL shader and the device's battery/performance takes a noticeable compared to the Pixels implementation).
And, as for the SafetyNet check disabling, though Android Police said that, there is literally no proof. The check tokens are still sent, and verified server side, and if you're rooted, the device still fails the authentication. AP threw out some unsubstantiated information. No deivce side-change was needed on the Nexus 6, so they re-uploaded the same factory image, and made a server side change. And nowhere was anything said about it being 64 ==> 32-bit code incompatibility. Do you have any source on that?
Click to expand...
Click to collapse
People these days aways looking for proof when info like this can't be shared openly nor can sources. You would be amazed at things talked about in development chats that don't make it to the users.
Just sit back and watch. I like most other developers have already decided to leave the N6 and get newer devices. When asked about it they already said they will not be converting any 64bit code at all. So anything that is coded for 64 bit devices then the N6 will never see it.
At least I have two agendas on hand; 1. I am already planning on buying the next Nexus (Pixel 2) or similar phone with Qualcomm Snapdragon 835 SOC whose bootloader remain user-unlockable and usable on Verizon network (I absolutely hate Verizon's locked bootloader policy). 2. There's other options, like Ubuntu Touch.
npjohnson said:
No developers are "working" on 7.1.2 (except maybe a few brave kernel developers), because the source isn't pushed to AOSP until the final release.
I don't mean to start a flame war, but this just isn't right. There has been no effort to "remove" 32-bit support. In fact, the Nexus Player is still a 32-bit device (albeit x86) which is supported by O, it may be 64-bit hardware, but due to proprietary firmware, they decided to have the 2nd-stage bootloader, and kernel/user-space boot in 32-bit mode. It has the O preview out now. Plus the 32-bit toolchains still get active support, and even 64-bit devices (i.e. angler/marlin) run some amount of arm(32) code in the form of their proprietary firmware/libraries, so we'll always need the ability to run 32-bit code on Android, and therefore, not stripping 32-bit compatibility from Android.
Also, there haven't been any specific moves by Google in terms of AOSP source away from 32-bit support.
I'd bet just about any amount of money the Nexus 6 will see O once source drops.
Why would O be the last AOSP we see? Android is mostly licensed under GPLv3, so they have to release source (that compiles) for the large majority of android. If you're refereeing to the fushcia OS they are creating, according to git logs, it is to be used on intergrated system's, as the kernel they wrote is very minimal.
Click to expand...
Click to collapse
I sure hope to see Android O on our Shamu! Fingers crossed we'll start to slowly see ROMs after official release and AOSP! Hope it's possible!
---------- Post added at 08:32 PM ---------- Previous post was at 07:58 PM ----------
rester555 said:
I don't think I look silly at all. Based on the conversation on the thread. I think it was a good discussion.
Click to expand...
Click to collapse
There's no such thing as a dumb question, how else does one learn? :angel:
Related
I'm interested in the Nexus 6 but concerned about a support dropoff (i.e., no Android N, O) within 2 years due to ARMv7. I feel like Moore's-Law-wise, phones now can go 3 years, assuming you don't always need the latest and greatest for gaming. I would keep using my Note 2 for another 6-8 months if it weren't for the complete stoppage in OS updates. (I might try CyanogenMod but I personally would like to avoid that if possible.) I would not have said the same thing about my previous smartphones, which began to struggle with webpage rendering after about 18 months.
For anyone who might know more about ARMv7 vs. ARMv8, what are the likely implications regarding the Android roadmap? Is this a major shift that will accelerate obsoletion of today's devices, or nothing special? I understand 32- vs. 64-bit by itself isn't really a huge deal, but I'm more concerned about the larger ARM picture. Thanks in advance.
(BTW I actually have a different but analogous concern about the iPhone 6, which I'm also eyeballing, having only 1GB RAM. I know it performs great today, but if the 6S and 7 have 2+ GB then Apple might drop support inside 2 years. But I understand that's not for this forum.)
FYI, the iPhone 6 has RAM issues already, so I think performance will be pretty sucky on it a year or 2 from now since it is already out of RAM in some situations.
As for Android and the architecture change I really think it is anyones guess right now and even Google themselves may not have yet decided on an answer for sure. On the one hand Google has to keep backwards compatibility for at least 1 more major OS release because of N6 support, and with the release dates the N6 will *probably* have support for 2 more OS releases as far as architecture compatibility. But 3 years? And with the changes already beginning to take place on chipset architecture? IDK, but I think that in 3 major OS releases from now we may be looking at a complete swap to the new 64-bit architecture and instruction sets. I suppose it may be possible that custom ROMs will get the newer OSes booting on old instruction sets, so the Nexus 6 and older models may yet have a long life in them still, but as far as official builds from Google I dont really know.
I'm of the opinion that we're getting pretty close to seeing a split in Android, and the N6 may end up providing the impetus. With 64bit looming for the next Nexus phone, I think it would make sense for Google to take more of a liberal Linux approach, and support both 32bit and 64bit processors. Devices are now at a point where they have more than enough under the hood - RAM, ROM, GPU, etc - so there's no real reason why Google should persist in taking a linear, one architecture approach to mobile development, especially with the Nexus line. I feel that 3 (possibly 4)year AOSP support windows should be viable from this point forward, and other than extreme greed (something Google hasn't displayed yet), there seems to be no reason to drop 32bit support.
In fact, the Nexus 9 is 64bit, while the N6 is only 32bit. Both run 5.0 exceptionally well, so we may already have some semblance of an answer as to what Google's plan is - a relatively low resource UI, that runs on multiple architectures. Of course the carrier update paths will be different, as their primary goal is to generate revenue, but I think Google itself may begin employing longer support windows for its own devices. ?
IMO Google needs to take the opportunity of unification and start off with a clean slate 64bit support across the board with a minimum ram required of at least 6Gig
They should require all manufacture to install vanilla android across all devices so that the experience is the same on all devices in order to compete for a better Android Experience against Apple
Manufacture can have an option for consumers to download their launcher from the playstore and niche smartphones like the note 4 should work ootb with vanilla android
It's interesting that the iPhone outsells android in app purchase yet they sell less phones over all and the biggest issue why is because of user experience not being fluid between computer tablet and phone like with an iPhone iPad and mac laptop or desktop
Google needs to take a mature step in structuring user experience
One more thing since Samsung is loosing so much money if they were to initiate the full real vanilla android experience without TouchWiz on all Samsung products including all current devices by ota update removing all bloatware I think they will be the new Google with a Samsung label and consumers will flock to them I mean they have all the gear to be able to make the android experience real and smooth they will just be supplying the hardware which is their main business anyway I also believe that they should include TouchWiz launcher in the playstore
Hello XDA Community,
I am interested in using the unofficial build of CyanogenMod 14.1 available here, but I would like to learn how to compile on my own from the repository provided by the developer. Unfortunately, I do not know how to go about doing this. Could someone please help me out? I have looked at the CyanogenMod Wiki entry for how to compile CyanogenMod for the Nexus 6, but the information is out of date according to what I was told in a post I made on Stack Exchange's Android Q&A site. The only thing that I understand about the build process is that I need to use Linux, so I have set up a virtual machine in VMware running the latest version of Ubuntu. Where do I go from here?
Thank you,
David B.
David B. said:
Hello XDA Community,
I am interested in using the unofficial build of CyanogenMod 14.1 available here, but I would like to learn how to compile on my own from the repository provided by the developer. Unfortunately, I do not know how to go about doing this. Could someone please help me out? I have looked at the CyanogenMod Wiki entry for how to compile CyanogenMod for the Nexus 6, but the information is out of date according to what I was told in a post I made on Stack Exchange's Android Q&A site. The only thing that I understand about the build process is that I need to use Linux, so I have set up a virtual machine in VMware running the latest version of Ubuntu. Where do I go from here?
Thank you,
David B.
Click to expand...
Click to collapse
To be honest You will be better off dual booting. Compiling with a VM normally has more issues then not.
Then I would look at Google developer page.
Also keep in mind that compiling from CM means you get all the bugs they never fixed. You would be better off going with AOSP and then finding the features you want to add and then add them yourself.
zelendel said:
To be honest You will be better off dual booting. Compiling with a VM normally has more issues then not.
Then I would look at Google developer page.
Also keep in mind that compiling from CM means you get all the bugs they never fixed. You would be better off going with AOSP and then finding the features you want to add and then add them yourself.
Click to expand...
Click to collapse
I would love to build my own CyanogenMod based on AOSP and then merge in the features, but I don't even know how to build directly from AOSP.
Honestly, all I really want is stock with all of the additional developer mode features that CyanogenMod has along with root access. I love the ability to use root without extra apps, and wireless ADB is sweet when I'm too lazy to go get my USB cable. And of course, I want to be able to use future versions of Android on my phone even though 7.0.1 is supposed to be the last version for Shamu. Could I somehow merge those aspects together and just pull patches from AOSP, build, and flash?
Also what's wrong with using a VM to compile? I've read that problems occur if you don't have enough RAM allocated to the VM, but I've assigned it 16GB so that should not be a problem. As for attaching my phone to the VM, I am using VMware, which has better support for removable devices than VirtualBox.
I'm sorry if I misunderstand something you said. It's probably obvious, but I know pretty much nothing about what I am doing which means I'm likely to ask lots of questions that seem ridiculous to those that are well-versed in this sort of thing.
David B. said:
I would love to build my own CyanogenMod based on AOSP and then merge in the features, but I don't even know how to build directly from AOSP.
Honestly, all I really want is stock with all of the additional developer mode features that CyanogenMod has along with root access. I love the ability to use root without extra apps, and wireless ADB is sweet when I'm too lazy to go get my USB cable. And of course, I want to be able to use future versions of Android on my phone even though 7.0.1 is supposed to be the last version for Shamu. Could I somehow merge those aspects together and just pull patches from AOSP, build, and flash?
Also what's wrong with using a VM to compile? I've read that problems occur if you don't have enough RAM allocated to the VM, but I've assigned it 16GB so that should not be a problem. As for attaching my phone to the VM, I am using VMware, which has better support for removable devices than VirtualBox.
I'm sorry if I misunderstand something you said. It's probably obvious, but I know pretty much nothing about what I am doing which means I'm likely to ask lots of questions that seem ridiculous to those that are well-versed in this sort of thing.
Click to expand...
Click to collapse
You do know that there is an app for SU built into CM right? So it is no extra apps then any other rom.
Could you yes but it will be lots of work due to what CM changes in the source code. It is one of the many reasons (on top of years old bugs that were never fixed) That many teams stopped using them as a source. The Shamu will be supported by 3rd party developers for a while to come.
Normally ram is an issue but other issues also happen.
I dont know anything about having to attach your device to VM as I have never used VM due to advise from the developers here.
Asking questions is not that big of a deal as long as you do your research. There are tons of TUT on the site about setting up a build setup. Just use the search and spend a few days reading. Mainly where the licenses are concerned. Also commit authorship. Which is you make your own rom it is very important.
zelendel said:
You do know that there is an app for SU built into CM right? So it is no extra apps then any other rom.
Could you yes but it will be lots of work due to what CM changes in the source code. It is one of the many reasons (on top of years old bugs that were never fixed) That many teams stopped using them as a source. The Shamu will be supported by 3rd party developers for a while to come.
Normally ram is an issue but other issues also happen.
I dont know anything about having to attach your device to VM as I have never used VM due to advise from the developers here.
Asking questions is not that big of a deal as long as you do your research. There are tons of TUT on the site about setting up a build setup. Just use the search and spend a few days reading. Mainly where the licenses are concerned. Also commit authorship. Which is you make your own rom it is very important.
Click to expand...
Click to collapse
Okay, so I have done some research and have a solution for how to use root with stock Android, but as soon as stock Android support is dropped from the Nexus 6 I will have to compile it myself which I am not sure how to do and would like to learn. Do you have any suggestions for what to go to learn since everything I am finding is not about compiling, but is instead about using an existing build?
David B. said:
Okay, so I have done some research and have a solution for how to use root with stock Android, but as soon as stock Android support is dropped from the Nexus 6 I will have to compile it myself which I am not sure how to do and would like to learn. Do you have any suggestions for what to go to learn since everything I am finding is not about compiling, but is instead about using an existing build?
Click to expand...
Click to collapse
Here you go
https://source.android.com/source/initializing.html
Mind you getting root is more then adding an app for it. You will also have to do some kernel edits.
zelendel said:
Here you go
https://source.android.com/source/initializing.html
Mind you getting root is more then adding an app for it. You will also have to do some kernel edits.
Click to expand...
Click to collapse
Thanks! I also found this. I have not really looked at it too much yet, but it seems like it has the potential to help me with what I want. Why would I need to make kernel edits? I thought all I needed to do was use TWRP to flash SuperSU after flashing the ROM.
David B. said:
Thanks! I also found this. I have not really looked at it too much yet, but it seems like it has the potential to help me with what I want. Why would I need to make kernel edits? I thought all I needed to do was use TWRP to flash SuperSU after flashing the ROM.
Click to expand...
Click to collapse
SuperSU edits the kernel when you flash it. Most of what allows root is in the kernel.
Yes that is a great resource. Just take your time and read it. You could have a working set up and build in about 2 days (given the first sync of the source code could take more then 24 hours depending on your connection.
zelendel said:
SuperSU edits the kernel when you flash it. Most of what allows root is in the kernel.
Yes that is a great resource. Just take your time and read it. You could have a working set up and build in about 2 days (given the first sync of the source code could take more then 24 hours depending on your connection.
Click to expand...
Click to collapse
One thing that I still cannot figure out after all of this reading is what to do to get AOSP to build for devices that are not officially supported by it. Granted, this is not a problem for the Nexus 6 right now, but it will be eventually, and I want to know how to handle it when it does become an issue. I've started cloning the repository. My connection gets a top download speed of 60Mbps so it should be reasonably fast.
David B. said:
One thing that I still cannot figure out after all of this reading is what to do to get AOSP to build for devices that are not officially supported by it. Granted, this is not a problem for the Nexus 6 right now, but it will be eventually, and I want to know how to handle it when it does become an issue. I've started cloning the repository. My connection gets a top download speed of 60Mbps so it should be reasonably fast.
Click to expand...
Click to collapse
At that point you will need to know what you are doing as you will have to make the code changes to make it bootable. I hate to say it but the n6 maybe doa after this as anything after 7.1 will need dual partition setup which the n6 doesn't have
zelendel said:
At that point you will need to know what you are doing as you will have to make the code changes to make it bootable. I hate to say it but the n6 maybe doa after this as anything after 7.1 will need dual partition setup which the n6 doesn't have
Click to expand...
Click to collapse
What's stopping the phone from being repartitioned in the same way you repartition a hard drive?
David B. said:
What's stopping the phone from being repartitioned in the same way you repartition a hard drive?
Click to expand...
Click to collapse
The main issue is none of the software for the n6 are made to work with it. All the drivers have to be rewritten. Also all of the new Vulcan graphics drivers won't work on the n6. This is why it didn't get all the features of 7.0
zelendel said:
The main issue is none of the software for the n6 are made to work with it. All the drivers have to be rewritten. Also all of the new Vulcan graphics drivers won't work on the n6. This is why it didn't get all the features of 7.0
Click to expand...
Click to collapse
I had not heard of this before. I was researching it online a bit and I cannot figure out which features are missing from the Nexus 6 version of Nougat. Also, Nougat has to support older hardware for devices that don't support Vulkan, so there's no reason they can't do that for Android O, and it they don't, surely someone smarter than I will be able to hack it together.
David B. said:
I had not heard of this before. I was researching it online a bit and I cannot figure out which features are missing from the Nexus 6 version of Nougat. Also, Nougat has to support older hardware for devices that don't support Vulkan, so there's no reason they can't do that for Android O, and it they don't, surely someone smarter than I will be able to hack it together.
Click to expand...
Click to collapse
That's the thing is android O will only be official supported by devices that can use it. Remember the nexus 6 support ended in October so there won't be an official O release for it.
Will there be a hacked together set up? Oh I'm sure there will be. It will just be without the Vulcan graphics drivers and the new update system which needs the dual partition layout.
The missing features are no background updates, no Vulcan drivers among other things
zelendel said:
That's the thing is android O will only be official supported by devices that can use it. Remember the nexus 6 support ended in October so there won't be an official O release for it.
Will there be a hacked together set up? Oh I'm sure there will be. It will just be without the Vulcan graphics drivers and the new update system which needs the dual partition layout.
The missing features are no background updates, no Vulcan drivers among other things
Click to expand...
Click to collapse
Well if the only things I lose are Vulkan and background updates, I am cool with that. It sounds like Vulkan is intended for games, and since I hate mobile gaming, an adapted build that works with the existing graphics drivers is not a concern at all. As for background updates, I would rather not have those because I like to know when my phone receives updates.
David B. said:
Well if the only things I lose are Vulkan and background updates, I am cool with that. It sounds like Vulkan is intended for games, and since I hate mobile gaming, an adapted build that works with the existing graphics drivers is not a concern at all. As for background updates, I would rather not have those because I like to know when my phone receives updates.
Click to expand...
Click to collapse
The Vulcan driver will be replacing the graphics drivers for everything soon. I can't think of much as I never use stock software.
zelendel said:
The Vulcan driver will be replacing the graphics drivers for everything soon. I can't think of much as I never use stock software.
Click to expand...
Click to collapse
I am sorry, but I am afraid I do not quite understand what it is that you said. What can't you think of?
David B. said:
I am sorry, but I am afraid I do not quite understand what it is that you said. What can't you think of?
Click to expand...
Click to collapse
There were many features that came with 7.0 like the new advanced doze and some other stuff. I dont use stock software and to be honest most of the stuff from 7.0 wasnt even really worth the update to me.
I have had a nexus since day 1 on and off and this was the first time I wasnt excited about the update. Even less with the new updates coming and google locking android down more as well as them moving most of the new stuff to closed sourced stuff. Heck even just having the bootloader unlocked is causing things not to work.
zelendel said:
There were many features that came with 7.0 like the new advanced doze and some other stuff. I dont use stock software and to be honest most of the stuff from 7.0 wasnt even really worth the update to me.
I have had a nexus since day 1 on and off and this was the first time I wasnt excited about the update. Even less with the new updates coming and google locking android down more as well as them moving most of the new stuff to closed sourced stuff. Heck even just having the bootloader unlocked is causing things not to work.
Click to expand...
Click to collapse
Really? What doesn't work with the unlocked bootloader?
David B. said:
Really? What doesn't work with the unlocked bootloader?
Click to expand...
Click to collapse
Things like android pay and saftynet. They are now starting to look for unlocked bootloaders. then you have those that are blocking apps due to root or xposed.
Is there a kind of LTS (long term support) ROM that regularly backports kernel and OS security patches? Kind of like a 6.0.1 with January 2017 patch level? I know I can install most ROMs without GApps (Slimroms is probably my favorite) but most of these ROMs base either off AOSP or CM/LOS which also base off AOSP, so when Google stops patching AOSP, these downstream ROMs stop getting security patches.
I don't really care for Android N as I'm perfectly happy with M but would like to squeeze another year or two out of it.
Just curious if such a thing exists; I'm sure it's no small feat to backport security patches, but it's something I'm very interested in to get the most life out of what's still an excellent device. This likely applies to many other devices as well (N4, N5, OPO, others who have been retired for reason other than money).
Edit: I should add that I'm aware of new tags, such as https://android.googlesource.com/platform/build/+/android-6.0.1_r78 but these seem to stop roughly two years out and don't really seem to have a guarantee of when they'll stop being updated. I'm looking to extend that two year mark to three or four years.
Android doesn't do LTS like Ubuntu. If you want to have the most current security updates, you'll have to update to Android 7.1.1. Security updates will continue for another 12 months.
It would be cool if there was a custom ROM that implemented something like this; not necessarily android per se, but sometimes, especially in an enterprise environment this would be a great idea.
mituzora said:
It would be cool if there was a custom ROM that implemented something like this; not necessarily android per se, but sometimes, especially in an enterprise environment this would be a great idea.
Click to expand...
Click to collapse
This was more what I was thinking of. I know Android officially doesn't go beyond ~2 years but that's what I'd like to see changed. Desktop OSes and software sometimes have these long-life versions (as pointed out, Firefox and Ubuntu to name just two) so it would make sense to start doing this for mobile OSes, certainly in an enterprise environment but a "would be nice" is also for older units or people who really don't care about bleeding edge but don't want to be left behind.
I imagine a model similar to Redhat and it's Enterprise Linux distribution which is open source (and then released by the CentOS folks), though in that case Redhat themselves are doing the backporting and patching. Since Google doesn't do that (pretty much the opposite if you look at their rolling releases for Chrome/Chromium) it would have to be a third party responsibility.
It would be a pretty big undertaking and wouldn't solve any issues that would lie in binary blobs typically used for most the hardware, but it could be a base for others to use if they had something a little more open (or as open as a smart phone can realistically be). In case any security research students are looking for a capstone...
Edit: regarding the "not necessarily android" note; I was thinking about this while I was working on an Ubuntu Touch port. I like how polished Android is and that I can even use it sans-Google apps but being strong-armed into the latest version of the OS is pretty silly. I really don't care about anything N brings from M. The step from L to M was huge and M has been rock solid for me, so I would like to see M used as an LTS base. N is just too weird and buggy, even half a year into it. For me at least.
But why would you stay on 6.0.1 which is noticeably slower than 7.1.1 on N6?
I've not had that experience myself; performance has been either the same or slightly worse but that's very subjective. It's not terribly important if 6.0.1 were used as a base or 7.x, I just picked 6.0.1 as an example because of its maturity and my perceived stability over 7.x.
Nope! Google has stopped pushing security updates to Marshmallow so the latest security patch level you will have is December 2016 on any Marshmallow ROM. Gotta switch to Nougat to continue to get security updates.
The only two ROMs I'm aware of that still push M builds are Mokee and AOKP. But again, just because they have compile dates in January of this year, they are still going to have either the November or December security patch. Backporting is too much work and would be stupid for any dev to waste time on.
Nothing is a waste of time if you're learning.
retro486 said:
Nothing is a waste of time if you're learning.
Click to expand...
Click to collapse
Yes, but as a developer you learn more from the latest version, so it makes more sense to focus on it.
Android is not conceived as a LTS OS, it is made for devices which are meant to be used for two years, so it doesn't makes sense to provide security patches for older versions.
If you're really up to the challenge, you should start a LTS ROM project yourself, because based on your response, I think you like to learn, and I think you'll learn a lot by doing it yourself.
Fair enough. And considering my original question about an LTS edition was answered (several times) I'll leave it at that. Thanks!
Well, while not officially that, but I am on MOB31S, which is a 6.0.1 January security patch official ROM. It is currently the official T Mobile ROM. I'm not sure how you would get it if not on T-mobile.
I know that 7.1.2 on the Nexus 6 is not supported by Google, but anyone know if any of the developers tried incorporating based on the AOSP 7.1.2 chain?
You realize those are preview builds for the other devices right? Code isn't pushed to AOSP yet AFAIK. I think the highest is 7.1.1_r22
edit: maybe it is? https://android.googlesource.com/platform/system/core/+/android-n-mr2-preview-1
Not worth trying at the moment. The source will change from preview to the final build. It's better to wait until the final build gets pushed out and the full source code reaches aosp. In other words, patience, young grasshopper. We will get custom Roms based on 7.1.2 ?
Arju said:
Not worth trying at the moment. The source will change from preview to the final build. It's better to wait until the final build gets pushed out and the full source code reaches aosp. In other words, patience, young grasshopper. We will get custom Roms based on 7.1.2
Click to expand...
Click to collapse
Thanks gentlemen! I understand you want to base on the final build to hopefully get rid of most of the bugs..
and the big improvements between 7.1.1 and 7.1.2 are what?
Personally I think we all get too excited by these updates. Me, I struggle to see the major differences between Kitkat and 7.1.1 (I'm pretty unobservant, but hey, it's just a communication/entertainment device, yeah?) so although I look forward to playing with the new version I raraly see any killer difference. Android, to my eyes, is about as advanced as it can get until it can actually give me a backrub and a cup of fresh-brewed coffee in the morning. I'm not holding my breath...
dahawthorne said:
Personally I think we all get too excited by these updates. Me, I struggle to see the major differences between Kitkat and 7.1.1 (I'm pretty unobservant, but hey, it's just a communication/entertainment device, yeah?) so although I look forward to playing with the new version I raraly see any killer difference. Android, to my eyes, is about as advanced as it can get until it can actually give me a backrub and a cup of fresh-brewed coffee in the morning. I'm not holding my breath...
Click to expand...
Click to collapse
Are you also blind? Because Kitkat and Nougat are miles apart.
I'm short-sighted. No need to be offensive.
Examples? I can play videos, talk to people, text. What major (and I mean major) differences are there then? It's a phone and communications device. Kitkat did that. Nougat is just icing.
Go on, justify your statement rather than just being offended and offensive.
@admiralspeedy: No, @dahawthorne is right in that the changes in Android recently have been more evolutionary than revolutionary. The last really significant change in Android was switching from Dalvik to ART, which was experimental in Android 4.4.x and enabled in Android 5.x. and up.
Note that Material Design isn't a significant change, and neither is SEAndroid enforcement.
Strephon Alkhalikoi said:
@admiralspeedy: No, @dahawthorne is right in that the changes in Android recently have been more evolutionary than revolutionary. The last really significant change in Android was switching from Dalvik to ART, which was experimental in Android 4.4.x and enabled in Android 5.x. and up.
Note that Material Design isn't a significant change, and neither is SEAndroid enforcement.
Click to expand...
Click to collapse
Everything can't be "revolutionary" and being evolutionary hardly means that there are very few big changes. KitKat is the last iteration of Android to use the Holo theme and now through Lollipop, Marshmallow and Nougat we've had several major improvements to the entire Android interface through material design. The interface changes alone are enough to consider KitKat and anything newer, vastly different. You also mentioned Dalvik to ART, which is a huge change, but you failed to mention proper 64-bit support (beginning with Lollipop), more customization (such as the notification tray toggles), native multi-window, the official fingerprint API, and when the next iteration is released, KitKat will probably be dropped from security patches unless a ton of people are still hanging on to it.
Really the list goes on but I think it's quite ridiculous to say that the evolutionary changes made from KitKat to Nougat are hardly substantial.
But @dahawthorne never said there were no significant changes. All he said is he couldn't see them. As for what you've listed, nothing there is truly significant, not even 64-bit computing. That's not to say they're not welcome or anything like that, but Dalvik to ART is significant because it fundamentally changed how Android worked under the hood.
P. S. Calling other posters blind because you can't see their point? Ironic.
admiralspeedy said:
Everything can't be "revolutionary" and being evolutionary hardly means that there are very few big changes. KitKat is the last iteration of Android to use the Holo theme and now through Lollipop, Marshmallow and Nougat we've had several major improvements to the entire Android interface through material design. The interface changes alone are enough to consider KitKat and anything newer, vastly different. You also mentioned Dalvik to ART, which is a huge change, but you failed to mention proper 64-bit support (beginning with Lollipop), more customization (such as the notification tray toggles), native multi-window, the official fingerprint API, and when the next iteration is released, KitKat will probably be dropped from security patches unless a ton of people are still hanging on to it.
Really the list goes on but I think it's quite ridiculous to say that the evolutionary changes made from KitKat to Nougat are hardly substantial.
Click to expand...
Click to collapse
I think that my point would be best-illustrated by handing two phones (Kitkat & Nougat) to a "normal" user (i.e. non-XDA person interested in using the phone and uninterested in the technology). I can easily imagine the scenario because I'm married to one. She might say that the new icons look nice, and the design is easy on the eye. Dalvik/ART? Couldn't care less. 64-bit? Even *I* couldn't care less. Multi-window? Impractical even on my N6's large screen, and effectively a tech showpiece, a solution looking for a problem. My N6 and my wife's N5 don't have a fingerprint reader, and in any case that's more of a hardware feature requiring software rather than a software feature in its own right. And persuading her to let me install new security versions is like pulling teeth.
I therefore stand full-square behind my original "little difference" statement, because to the "normal" user that's exactly the case.
this thread actually is about differences between 7.11 and 7.12
and, whether you think there are major differences between lollipop, kitkat and nougat, I think we ALL can agree that the differences between a 7.11 os and a 7.12 os will hardly be worth anyone's time to get excited about.
maybe when it moves to 8.0 it will be significant, but a one dot move in ANY OS generally means absolutely nothing
dahawthorne said:
I think that my point would be best-illustrated by handing two phones (Kitkat & Nougat) to a "normal" user (i.e. non-XDA person interested in using the phone and uninterested in the technology). I can easily imagine the scenario because I'm married to one. She might say that the new icons look nice, and the design is easy on the eye. Dalvik/ART? Couldn't care less. 64-bit? Even *I* couldn't care less. Multi-window? Impractical even on my N6's large screen, and effectively a tech showpiece, a solution looking for a problem. My N6 and my wife's N5 don't have a fingerprint reader, and in any case that's more of a hardware feature requiring software rather than a software feature in its own right. And persuading her to let me install new security versions is like pulling teeth.
I therefore stand full-square behind my original "little difference" statement, because to the "normal" user that's exactly the case.
Click to expand...
Click to collapse
Agreed. The average person couldn't care less or even really tell a difference. My gf is the same way. She doesn't even Ike doing the monthly security updates to the point she made disable it lol. As long as it makes calls, texts, Facebook and a few websites then she is happy.
wase4711 said:
this thread actually is about differences between 7.11 and 7.12
and, whether you think there are major differences between lollipop, kitkat and nougat, I think we ALL can agree that the differences between a 7.11 os and a 7.12 os will hardly be worth anyone's time to get excited about.
maybe when it moves to 8.0 it will be significant, but a one dot move in ANY OS generally means absolutely nothing
Click to expand...
Click to collapse
l2tp protocol should be fixed in 7.1..2 according to issue #196939. it is something i was waiting for almost two years.
never heard of that, never read about that, have no clue about that, and you wont find any discussion about it on XDA, so, its not an issue that is at the forefront in anyone I knows mind...
wase4711 said:
never heard of that, never read about that, have no clue about that, and you wont find any discussion about it on XDA, so, its not an issue that is at the forefront in anyone I knows mind...
Click to expand...
Click to collapse
This is true that you are not seeing talks about it but just because you dont see anything said about it on XDA doesnt mean it is not in the forfront of anyones mind.
Talks like that really arent dont in the threads anymore but in private chats. 99% of any real development talks are done away from users these days.
As for 7.1.2 this will start to get really hard as this is when 32bit support dies and all of Google code is for 64 bit chips. Developers are already starting to see the change over and soo it will be true death for 32 bit devices. As porting it backwards is almost not conceivable.
To be honest, 32-bit supports won't go away, in fact it's required. Why? ARM Cortex A35 and A7 CPUs which will be here to stay, even though it's obviously true that industry and ROM developers are moving to 64-bit support (ie. AARCH64 AKA ARM64 mode) - ie. Cortex A53 and up to A73, the 32-bit ARM processors will still be used for many years to come, obviously for embedded battery life reasons, like Android Wear.
Otherwise, Nexus 6 will be my last 32-bit device (I know Android Oreo will still come onto Nexus 6 via Lineage OS, obviously because it will still support 32-bit mode for some reasons - Android Wear is based on full-blown Android OS, so if you remove 32-bit mode support, you risk breaking the watch ecosystem). I am kind of torn between ASUS ZenFone AR or Pixel 2. Hard choice.
Dr. Mario said:
To be honest, 32-bit supports won't go away, in fact it's required. Why? ARM Cortex A35 and A7 CPUs which will be here to stay, even though it's obviously true that industry and ROM developers are moving to 64-bit support (ie. AARCH64 AKA ARM64 mode) - ie. Cortex A53 and up to A73, the 32-bit ARM processors will still be used for many years to come, obviously for embedded battery life reasons, like Android Wear.
Otherwise, Nexus 6 will be my last 32-bit device (I know Android Oreo will still come onto Nexus 6 via Lineage OS, obviously because it will still support 32-bit mode for some reasons - Android Wear is based on full-blown Android OS, so if you remove 32-bit mode support, you risk breaking the watch ecosystem). I am kind of torn between ASUS ZenFone AR or Pixel 2. Hard choice.
Click to expand...
Click to collapse
Just because those chips are here doesnt mean the OS has to support it. Plus with the adaption rate of devices, by the time that it would matter 99% of devices will already being running a 64 bit chip.
Look at it this way. Google only works on code for their base devices. All 64bit.
As of LOS. If they dont have a base to work from then it will be very hard indeed.
They will not risk that. It is already in the works if you think about it. Only the n6 is a 32bit device that google supports. So they already have it setup for 64bit to work with the watch.
If you watch google source code you will see the transition.
True, but who knows, as of now? Google occasionally pull the surprises (I don't trust commit notes from certain companies such as Google, they occasionally put too much eggs into a basket - recent Nexus and Pixel muck-ups proves that), so it's possible they would either continue with transition or just cancel it and stick with hybrid builds. It's now more of a wait and see thing.
When to expect Android o ROM
After Android O is actually released .....
dictionary said:
After Android O is actually released .....
Click to expand...
Click to collapse
The Beta has been out for 2 months, but I get what you're saying.
Right now it wouldn't be practical. There are too many bugs that could be there. Even Google says it's not ready for mainstream use yet.
liquidzoo said:
The Beta has been out for 2 months, but I get what you're saying.
Right now it wouldn't be practical. There are too many bugs that could be there. Even Google says it's not ready for mainstream use yet.
Click to expand...
Click to collapse
I thought the Nexus 6 was not slated to receive the Android O update. Am I wrong?
classic757 said:
I thought the Nexus 6 was not slated to receive the Android O update. Am I wrong?
Click to expand...
Click to collapse
No, you're not wrong. The Nexus 6 is not part of the beta program...that doesn't mean some enterprising ROM developer won't compile something for us to enjoy, though.
liquidzoo said:
No, you're not wrong. The Nexus 6 is not part of the beta program...that doesn't mean some enterprising ROM developer won't compile something for us to enjoy, though.
Click to expand...
Click to collapse
Can't wait! This is the first time the developer previews weren't made for the shamu, and it's killing me! Lol can't wait to have a fully ported ROM!
liquidzoo said:
No, you're not wrong. The Nexus 6 is not part of the beta program...that doesn't mean some enterprising ROM developer won't compile something for us to enjoy, though.
Click to expand...
Click to collapse
That would be great if we can have an Android O custom ROM. Looking forward to that.
As I've said before in other threads, there's no reason we shouldn't be able to have a custom Android O ROM. What we won't get are features that are specifically for 64-bit processors. So things like the Pixel/Pixel XL Settings app for example are out of the question and we'd have to "make do" with the standard Settings app found in AOSP.
Strephon Alkhalikoi said:
As I've said before in other threads, there's no reason we shouldn't be able to have a custom Android O ROM. What we won't get are features that are specifically for 64-bit processors. So things like the Pixel/Pixel XL Settings app for example are out of the question and we'd have to "make do" with the standard Settings app found in AOSP.
Click to expand...
Click to collapse
I actually thought about getting a Nexus 6p because it has a 64 bit processor and is an Android O candidate but from what I've read, that phone just has too many glitches so not sure I want to fool with that.
The 6P was never in the running for my next device. At the time, there was no compelling reason for me to pick that device over the N6. The fingerprint sensor was something I could do without both now and in the future, the camera I felt was a step backwards even with the larger pixels, the Snapdragon 810 was a horror show, and the phone was simply ugly. While I could have cured that last one with a case, the fact the 6P bootloops when you breathe on it only validates my decision.
Strephon Alkhalikoi said:
The 6P was never in the running for my next device. At the time, there was no compelling reason for me to pick that device over the N6. The fingerprint sensor was something I could do without both now and in the future, the camera I felt was a step backwards even with the larger pixels, the Snapdragon 810 was a horror show, and the phone was simply ugly. While I could have cured that last one with a case, the fact the 6P bootloops when you breathe on it only validates my decision.
Click to expand...
Click to collapse
I hear you.
The only reason I considered the 6p was for future OS updates but you are right, the phone is ugly (especially with that sun visor camera screen. Yuk!), the 810 overheats like an old car in the Sahara desert, and bootloops come standard with the phone.
So your points are well taken.
I'm with Verizon so my choices for unlocked, rootable phones with the specs of my Nexus 6 are very limited.
Looks like I'll be sticking with my Shamu for a while.
I am all for keeping my Nexus 6 Shamu and breathing extra life into it with Oreo (as for Oreo being 64-bit only, I will say it once again and for the final time, it's NOT 64-bit only as it will just kill the market for prepaid phones), replacement batteries are getting hard to find, and now I am unsure if I wanna gamble with NewPower99 aftermarket Lithium polymer cells (I may probably have to desolder the battery protection module and just solder new LG Lithium polymer cell on, which is about the only thing that's compatible with Nexus 6's battery management system) - battery fire is no laughing matter, as batteries don't really give you very much warning, even if it does, it's usually too late.
And I also am considering Google Pixel 2 (this time straight from Google Store as I HATE Verizon's stupid locked bootloader policy, that kind of thing pisses me off - the stock ROM can inevitably become bricked with no way to recover for no reasons at all, so TWRP have become a requirement when it comes to owning a smartphone).