Pixel Camera for Nexus 6? - Nexus 6 Q&A, Help & Troubleshooting

Just wondering if anyone has successfully gotten the Pixel Camera apk working with the Nexus 6. I'm sure it's no easy task since the Nexus 6 isn't Armx64.
So far my Nexus 6 is pretty close to being the Pixel. Google Assistant, Dialer, and launcher/Icons (Nova launcher beta) are all working
Getting closer and closer. I should be switching over to the Pixel this month sometime.

ForeverZ3RO said:
Just wondering if anyone has successfully gotten the Pixel Camera apk working with the Nexus 6. I'm sure it's no easy task since the Nexus 6 isn't Armx64.
Click to expand...
Click to collapse
No easy task? Try impossible without source code. Since the camera app is 64-bit only, it won't run on our 32-bit version of Android, period. This is a hardware limitation as the Snapdragon 805 is a 32-bit processor and cannot understand 64-bit code. A 32-bit version would need to be compiled from the non-existent source code.

Strephon Alkhalikoi said:
No easy task? Try impossible without source code. Since the camera app is 64-bit only, it won't run on our 32-bit version of Android, period. This is a hardware limitation as the Snapdragon 805 is a 32-bit processor and cannot understand 64-bit code. A 32-bit version would need to be compiled from the non-existent source code.
Click to expand...
Click to collapse
Thanks for the heads up. I didn't know that, I'm not exactly a developer or anything.
Thanks again.

Strephon Alkhalikoi said:
No easy task? Try impossible without source code. Since the camera app is 64-bit only, it won't run on our 32-bit version of Android, period. This is a hardware limitation as the Snapdragon 805 is a 32-bit processor and cannot understand 64-bit code. A 32-bit version would need to be compiled from the non-existent source code.
Click to expand...
Click to collapse
Will it work on the 6P?
Sent from my Nexus 6P using Tapatalk

Yes. The Snapdragon 810 in the 6P is a 64-bit processor so porting the camera app is no trouble.

Pixel's Google Camera app, on paper just work on the 6P for architectural similarities yet it doesn't as of now.
All I get is an ANR message.

theGeekyLad said:
All I get is an ANR message.
Click to expand...
Click to collapse
Whether it works on the 6P isn't really relevant. It definitely won't work on the Nexus 6, which is all anyone here needs to know.

Related

Giving away android sticks for porting

I have some android sticks lying around for anyone that wants to use it to port omnirom to it. They currently have android 4.2 on them and I have all the source code from the manufacturer.
Its limited how many I have, but I imagine if you pm me I can help you.
A little bit about the hardware. Its a Chinese chipset and I doubt most people will probably be able to work with the source code as the company is in china and provides next to no documentation. Also, its based on the ns115 chipset which is a dual cpu/gpu. But if you want to mess with it, then I guess the universe is giving you a real good riddle.
adamdmcbride said:
I have some android sticks lying around for anyone that wants to use it to port omnirom to it. They currently have android 4.2 on them and I have all the source code from the manufacturer.
Its limited how many I have, but I imagine if you pm me I can help you.
A little bit about the hardware. Its a Chinese chipset and I doubt most people will probably be able to work with the source code as the company is in china and provides next to no documentation. Also, its based on the ns115 chipset which is a dual cpu/gpu. But if you want to mess with it, then I guess the universe is giving you a real good riddle.
Click to expand...
Click to collapse
Give me info about the stick HW please and I'll tell you what can be done.
InterfaceNode said:
Give me info about the stick HW please and I'll tell you what can be done.
Click to expand...
Click to collapse
It's a chinese chipset Nufront ns115, dualcore arm cortex a9 with 8gb memory and 1gb ram. It has all source code and is currently using uboot as bootloader.
Sent from my iPhone using Tapatalk
adamdmcbride said:
It's a chinese chipset Nufront ns115, dualcore arm cortex a9 with 8gb memory and 1gb ram. It has all source code and is currently using uboot as bootloader.
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
I'll see what I can do about it; owning the hardware is not required but if I boot
Please link me to the source and I'll begin as soon as possible

Vulkan clarification

So, Nexus 6 doesn't have Vulkan right? That's not fair by google because Adreno 420 is supposedly supported by Qualcomm on this.
It will. We are waiting on a driver from Qualcomm. They say on their website it is comming.
Maybe Android 7.1 will have it. Fingers crossed!
Lawstorant said:
So, Nexus 6 doesn't have Vulkan right? That's not fair by google because Adreno 420 is supposedly supported by Qualcomm on this.
Click to expand...
Click to collapse
The clarification is this; Vulkan is an API. That means APPLICATION PROGRAMMING INTERFACE. I.e., it defines the language used by APPLICATIONS to talk to the DRIVER.
Until there are actually APPLICATIONS that YOU require, that themselves *REQUIRE* Vulkan, then it doesn't matter if your driver implements that API.
Translation: Who cares? It won't do you any good. This is a long term far far off kind of preparing for the future API.
Yeah, I know all that. It's just that Vainglory is rushing with Vulkan support and Vulkan might prolong N6 gaming lifespan. I'm just interested if it would be at all possible to add Vulkan drivers even if Google refuses to do so.
Unless Qualcomm releases binaries for the N6, there will be no Vulkan. Dropping in binaries from a device with Vulkan won't help, at least from what little I've read on the topic.
That needs to be tried out. I flashed marshmallow graphics drivers intended for nexus on my Samsung tablet and zuk phone without problems.
Any update on vulkan?
santi1993 said:
Any update on vulkan?
Click to expand...
Click to collapse
The Nexus 6 will not get it due to the chip not supporting it. This info has been around for a while. Too be honest it really wont even be worth having for a few years yet.
zelendel said:
The Nexus 6 will not get it due to the chip not supporting it. This info has been around for a while. Too be honest it really wont even be worth having for a few years yet.
Click to expand...
Click to collapse
But they said they were going to support it? https://www.xda-developers.com/vulkan-api-means-more-control-but-not-outright-replacement-of-opengl/
Sorry if i'm being a little stupid here, but the nexus 6 has the 805 and the 805 is said to be supported since it has a 4xx GPU right?
What were you going to do if it was available? As stated above, Vulkan isn't really widely used yet so having it enabled wouldn't really make any difference.
clonetrooper67 said:
Sorry if i'm being a little stupid here, but the nexus 6 has the 805 and the 805 is said to be supported since it has a 4xx GPU right?
Click to expand...
Click to collapse
The Nexus 6 is capable of supporting Vulkan, but Qualcomm has to provide the APIs and apparently have no desire to do so.
Strephon Alkhalikoi said:
The Nexus 6 is capable of supporting Vulkan, but Qualcomm has to provide the APIs and apparently have no desire to do so.
Click to expand...
Click to collapse
Here is an article from a google engineer
https://www.androidheadlines.com/2016/07/google-engineer-says-no-vulkan-support-for-the-nexus-9.html
" Aside from the Nexus 9, the Nexus 6 is also left out of the list of supported devices."
What an engineer says is beside the point here. The fact of the matter is Qualcomm themselves noted the 805 as being compatible. Therefore it is up to Qualcomm to provide or not provide the support, NOT Google. Qualcomm chose not to, and I really don't have a problem with that. It's not a huge deal since there really isn't anything requiring Vulkan in the first place.
Strephon Alkhalikoi said:
What an engineer says is beside the point here. The fact of the matter is Qualcomm themselves noted the 805 as being compatible. Therefore it is up to Qualcomm to provide or not provide the support, NOT Google. Qualcomm chose not to, and I really don't have a problem with that. It's not a huge deal since there really isn't anything requiring Vulkan in the first place.
Click to expand...
Click to collapse
It's not just one side. It has to be both. Qualcomm could support it but Google decides not to. Or the reverse. Google has the final say
zelendel said:
It's not just one side. It has to be both.
Click to expand...
Click to collapse
Says who? If Qualcomm desired they could release Vulkan for the 805 and there isn't a thing Google could do about it. This is solely Qualcomm not wishing to provide further support for the 805, which is totally understandable given they have switched over to 64-bit processors. At the end of the day, all that really matters is the N6 isn't getting Vulkan, and by the time games become available which require Vulkan, the N6 will be sitting in some forgotten corner of a dresser drawer or storage box. Thus, who makes the decision isn't nearly as important as the decision itself.

How hard is it to port apps?

Seeing all these Pixel exclusive features is making me antsy (since I crave bleeding-edge software), to the point where I am considering learning how to port the APKs found on the Pixel system image. For instance, what exactly must be done to get the Pixel systemui.apk to work on the shamu? What about the live wallpapers? Is it even possible due to missing libraries?
Anyway, food for thought. If it's not incredibly difficult and my school workload remains light, I could see myself consider this undertaking.
snowrelyt said:
Seeing all these Pixel exclusive features is making me antsy (since I crave bleeding-edge software), to the point where I am considering learning how to port the APKs found on the Pixel system image. For instance, what exactly must be done to get the Pixel systemui.apk to work on the shamu? What about the live wallpapers? Is it even possible due to missing libraries?
Anyway, food for thought. If it's not incredibly difficult and my school workload remains light, I could see myself consider this undertaking.
Click to expand...
Click to collapse
just so you know, a pixel is 64 bit phone where a nexus 6 is a 32 bit phone. you cant run 64 bit apps on a 32 bit phone.
simms22 said:
just so you know, a pixel is 64 bit phone where a nexus 6 is a 32 bit phone. you cant run 64 bit apps on a 32 bit phone.
Click to expand...
Click to collapse
I'm well aware, but is there no way to compile it for a different architecture? At all?
The "exclusives" in regards to the Pixel/Pixel XL are the launcher, Google Assistant, and possibly the camera app. The Pixel launcher is a 32-bit app and has been available for some time. Google Assistant has already been ported over via a build.prop edit. The only thing that hasn't been touched is the camera app, and honestly, it's not that big an upgrade.
The underlying system files are all going to come our way in December, as the Nexus 6 is slated to get Android 7.1. Building a ROM right now isn't going to be feasible without Android 7.1 vendor blobs, as I don't think the Android 7.0 blobs will work.
Strephon Alkhalikoi said:
The "exclusives" in regards to the Pixel/Pixel XL are the launcher, Google Assistant, and possibly the camera app. The Pixel launcher is a 32-bit app and has been available for some time. Google Assistant has already been ported over via a build.prop edit. The only thing that hasn't been touched is the camera app, and honestly, it's not that big an upgrade.
The underlying system files are all going to come our way in December, as the Nexus 6 is slated to get Android 7.1. Building a ROM right now isn't going to be feasible without Android 7.1 vendor blobs, as I don't think the Android 7.0 blobs will work.
Click to expand...
Click to collapse
The Pixel has a few other apks we can't install; Live wallpapers, SystemUI (with new nav buttons and color burst), and a themed settings menu. Those are mainly what I'm interested in, so are you saying it's not possible to bring those to the shamu?
Not unless they're included in the source code Google provided.

Android O and Nexus 6

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:

Nexus 6 change for something new

I'm wondering what should I pick , Galaxy S8 or oneplus 5, one of these will be for about 2 years of usage. Good camera, very fast and responsive system, and these are for exactly the same price in my country.
Personally, I'd never buy a Samsung...
I'm very happy with my OP3T though, that replaced my Shamu.
I am waiting for Essential PH-1 or Pixel XL 2
Sent from my Nexus 9 using Tapatalk
siorek11 said:
I'm wondering what should I pick , Galaxy S8 or oneplus 5, one of these will be for about 2 years of usage. Good camera, very fast and responsive system, and these are for exactly the same price in my country.
Click to expand...
Click to collapse
Honestly, if you're on XDA and you own a Nexus chances are you want the freedom reliability and customization of a Nexus device, I own the Nexus 6 OP3/T and I'm getting my Op5 in the mail soon. It was an easy choice for me. So I hope this helps:
siorek11 said:
these are for exactly the same price in my country.
Click to expand...
Click to collapse
You're saying they are the same price, but are they? OnePlus 5 has 8gb of RAM/128GB of storage and Dual Cameras with Optical Zoom and timely updates and Open Source OxygenOs.
I know Samsung has this ridiculously long feature list but they lack all crucial Android things in my opinion. I'm not gonna list every one but the main one for me is the spirit of Android: "Open Source"
In conclusion: if you do decide to get the OnePlus 5 the entire community is with you and please use my referral link :highfive:
https://oneplus.net/invite#I2FTNN6M7DKAP13
@BoiBundy, I'm waiting to see if anyone gets the OP5 working on Sprint. I think Verizon is also questionable. Of course, that might be the push I need to move to T-Mobile [emoji3]
ktmom said:
@BoiBundy, I'm waiting to see if anyone gets the OP5 working on Sprint. I think Verizon is also questionable. Of course, that might be the push I need to move to T-Mobile [emoji3]
Click to expand...
Click to collapse
You have Sprint? Not too sure if it'll work, they say that they have 34 different antennae so maybe bcuz the phone is unlocked. I have At&t and apparently Some people are already reporting to be getting blazingly fast LTE+ speeds. I live in Urban NY so hoping this is true.
BoiBundy said:
You have Sprint? Not too sure if it'll work, they say that they have 34 different antennae so maybe bcuz the phone is unlocked. I have At&t and apparently Some people are already reporting to be getting blazingly fast LTE+ speeds. I live in Urban NY so hoping this is true.
Click to expand...
Click to collapse
It's more complex with Sprint (and maybe Verizon) than just having the correct frequencies. At least with Sprint, the trick includes getting activated on the network. Someone in the OP5 forum is actually working through the process this week.
ktmom said:
It's more complex with Sprint (and maybe Verizon) than just having the correct frequencies. At least with Sprint, the trick includes getting activated on the network. Someone in the OP5 forum is actually working through the process this week.
Click to expand...
Click to collapse
I know exactly what you're talking about. Back when Google was selling the Nexus 6/p I read a topic on this extensively (for no apparent reason but just to be aware on the topic). People with Iphones, and Nexuses bought from Google had to call up Sprint and add their MEID/IMEI's to the database. I'm thinking, in theory it shouldn't be a problem especially since they have BYOD(Bring Your Own Device) plans. Idk how they operate with dualSIM devices though.
ktmom said:
It's more complex with Sprint
Click to expand...
Click to collapse
This looks promising: https://community.sprint.com/t5/iPh...a-IMEI-to-the-Sprint-database/m-p/951240#M464
BoiBundy said:
Honestly, if you're on XDA and you own a Nexus chances are you want the freedom reliability and customization of a Nexus device, I own the Nexus 6 OP3/T and I'm getting my Op5 in the mail soon. It was an easy choice for me. So I hope this helps:
You're saying they are the same price, but are they? OnePlus 5 has 8gb of RAM/128GB of storage and Dual Cameras with Optical Zoom and timely updates and Open Source OxygenOs.
I know Samsung has this ridiculously long feature list but they lack all crucial Android things in my opinion. I'm not gonna list every one but the main one for me is the spirit of Android: "Open Source"
In conclusion: if you do decide to get the OnePlus 5 the entire community is with you and please use my referral link :highfive:
https://oneplus.net/invite#I2FTNN6M7DKAP13
Click to expand...
Click to collapse
You do know that android is not open source right? Only AOSP is open source. What google ships with devices is not. Just like Oxygen is not open source.
This is a common misconception.
zelendel said:
You do know that android is not open source right? Only AOSP is open source. What google ships with devices is not. Just like Oxygen is not open source.
This is a common misconception.
Click to expand...
Click to collapse
I did say the spirit of Android if I remember correctly. And I didn't mention one thing about what Google ships with their devices(although they are based off of AOSP). And I believe you are incorrect in your statement that OxygenOS isn't open source because they released the kernel source days before the launch and I've attached a screenshot of their website for your viewing. Thanks for the clarity though there are no misconceptions here.
BoiBundy said:
I did say the spirit of Android if I remember correctly. And I didn't mention one thing about what Google ships with their devices(although they are based off of AOSP). And I believe you are incorrect in your statement that OxygenOS isn't open source because they released the kernel source days before the launch and I've attached a screenshot of their website for your viewing. Thanks for the clarity though there are no misconceptions here.
Click to expand...
Click to collapse
I just mentioned those as an example.
https://forums.oneplus.net/threads/oxygen-os-open-source.557212/
Just because the kernel is is released (licensed under the gpl So source is required) Android is licensed under the apache license (which allows for it to be closed sourced)
BoiBundy said:
I did say the spirit of Android if I remember correctly. And I didn't mention one thing about what Google ships with their devices(although they are based off of AOSP). And I believe you are incorrect in your statement that OxygenOS isn't open source because they released the kernel source days before the launch and I've attached a screenshot of their website for your viewing. Thanks for the clarity though there are no misconceptions here.
Click to expand...
Click to collapse
OOS is not open source. I cannot go to github, or whever the source is stored, and read and compile it myself. Android Core is released under Apache, but not Google's goodies(hence why AOSP is so bare nowadays; Google has closed the vast majority of your basic apps) The only reason why the kernel source gets pushed is because OnePlus has a legal obligation to do so since they used the Linux kernel which is licensed under GPL
ktmom said:
@BoiBundy, I'm waiting to see if anyone gets the OP5 working on Sprint. I think Verizon is also questionable. Of course, that might be the push I need to move to T-Mobile [emoji3]
Click to expand...
Click to collapse
Any word on getting the OP5 working on Verizon?
enginuity2 said:
Any word on getting the OP5 working on Verizon?
Click to expand...
Click to collapse
Dunno, not following. There a thread in the OP5 forum saying it didn't work on Sprint.

Categories

Resources