Thoughts on Oreo... - Nexus 6 Developer Discussion [Developers Only]

So, since the Pixel and newer Nexus devices are now getting their Oreo updates, I think it's time that we, the developers who still own Nexus 6's, to look into porting Oreo to this device. I am looking into the source code as we speak for feasibility. If anything, I will probably do like I have done with most of my devices in the past, forge the path and create a guide, and let everyone else do the creative stuff. I just happen to like stock Android.

---

There is already one dev who got Oreo to boot on the Xiaomi Mi 3, runs on SD800 (32bit)

---

konradit said:
There is already one dev who got Oreo to boot on the Xiaomi Mi 3, runs on SD800 (32bit)
Click to expand...
Click to collapse
Looking promising,fingers crossed
Sent from my Nexus 6 using Tapatalk

---

There ARE people working on Android O port, even back when it was still in developer preview status. You'll see releases whenever they are ready, I'd give it a few weeks or months.
I won't argue if you're a developer or not, I'm sure you are. But you are not a "recognized developer". Your title is member

---

Dopamin3 said:
There ARE people working on Android O port, even back when it was still in developer preview status. You'll see releases whenever they are ready, I'd give it a few weeks or months.
I won't argue if you're a developer or not, I'm sure you are. But you are not a "recognized developer". Your title is member
Click to expand...
Click to collapse
Getting it to build is easy. Ive already done as much but without updated binaries (which I havent seen for any device) it wont boot. There are likely some kernel changes needed as well though I havent dug to much into that yet. Then there is the whole GApps for Oreo issue. I would say we are definitely a week or so away from anything working.

---

Things are in the works and if gapps don't work for 32 bit.. I suggest you gentlemen familiarize yourself with microG

---

I built it from developer preview 2 a couple months ago. Booted and everything, but nothing as far as any of the radios worked. I had to modify franco kernel to get it there, but it did work..
I tried re-building it after the stable source dropped and can't seem to get passed this error:
frameworks/native/include/gui/IGraphicBufferProducer.h:35:10: fatal error: 'hidl/HybridInterface.h' file not found
The file is there and where it should be... So I'm kinda scratching my head as to where the switch is that causes it not to pick up that location.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

---

So the development for Xiaomi Mi3/Mi4 has gone online: https://forum.xda-developers.com/xiaomi-mi-3/development/8-0-aosp-t3662028
The source code is not available yet but is on it's way. Maybe there might be hints on what's needed for us to make stuff work on the shamu once the source is online(?). I'm aware they are completely different devices but the architecture are closer as they both are 32bit rather than the newer devices running 64bit.

---

I was able to get a build to complete but it doesn't boot. I don't have the time today to go over it, but if anyone has some free time, feel free to take a look at the logcat and see if anything jumps out immediately.
boot.log

---

kkozma said:
I was able to get a build to complete but it doesn't boot. I don't have the time today to go over it, but if anyone has some free time, feel free to take a look at the logcat and see if anything jumps out immediately.
boot.log
Click to expand...
Click to collapse
@followmsi build had a similar issue yesterday on the Nexus 7 2013 forums. I tested the build and it would not get to the boot animation and would restart to the bootloader after about a minute. After returning to TWRP the data partition was either corrupted or unreadable. OP said that it was probably the fact of missing SDcardFS support in the recovery/kernel.
https://forum.xda-developers.com/nexus-7-2013/development/rom-t3569067/page60
the struggle continues.

---

wavedashdoc said:
@followmsi build had a similar issue yesterday on the Nexus 7 2013 forums. I tested the build and it would not get to the boot animation and would restart to the bootloader after about a minute. After returning to TWRP the data partition was either corrupted or unreadable. OP said that it was probably the fact of missing SDcardFS support in the recovery/kernel.
https://forum.xda-developers.com/nexus-7-2013/development/rom-t3569067/page60
the struggle continues.
Click to expand...
Click to collapse
He is wrong. The sdcardfs is a file system for sdcard enabled devices. Nothing to do with the nexus 6. It was even removed in most other builds for the device. The only people that added it were people that didn't understand what they were doing.

---

wrongway213 said:
Things are in the works and if gapps don't work for 32 bit.. I suggest you gentlemen familiarize yourself with microG
Click to expand...
Click to collapse
Late reply here.
I have tried MicroG before - on a custom Galaxy S4 ROM - and I like MicroG about as much as I like Xposed. If MicroG is required I won't be upgrading.

---

wrongway213 said:
Things are in the works and if gapps don't work for 32 bit.. I suggest you gentlemen familiarize yourself with microG
Click to expand...
Click to collapse
People are not gonna do that. Microg is known for causing its own issues.

---

Strephon Alkhalikoi said:
Late reply here.
I have tried MicroG before - on a custom Galaxy S4 ROM - and I like MicroG about as much as I like Xposed. If MicroG is required I won't be upgrading.
Click to expand...
Click to collapse
zelendel said:
People are not gonna do that. Microg is known for causing its own issues.
Click to expand...
Click to collapse
It's been confirmed that gapps for arm are working since I posted that, so it's a moot point now, thankfully.

---

zelendel said:
He is wrong. The sdcardfs is a file system for sdcard enabled devices. Nothing to do with the nexus 6. It was even removed in most other builds for the device. The only people that added it were people that didn't understand what they were doing.
Click to expand...
Click to collapse
Oh mate, you're so wrong. SDcardFS is a virtual FS for emulating /sdcard/ (/storage/emulated/0) and EVERY android device has it. It's just a replacement for vFAT (virtual FAT). One of the most important fixes is that the file timestaps won't get corrupted anymore (this bug existed in android for years).

---

Lawstorant said:
Oh mate, you're so wrong. SDcardFS is a virtual FS for emulating /sdcard/ (/storage/emulated/0) and EVERY android device has it. It's just a replacement for vFAT (virtual FAT). One of the most important fixes is that the file timestaps won't get corrupted anymore (this bug existed in android for years).
Click to expand...
Click to collapse
vfat is a real filesystem for block devices. Think of it as being in between FAT and FAT32. What it adds over FAT is a virtual file NAMING convention in order to exceed the standard "8.3" filename format that FAT was stuck with. vfat is also the NAME of the linux implementation of FAT (FAT12, FAT16), VFAT, and FAT32.
What you are thinking of as being present on "EVERY" android device, is this; https://android.googlesource.com/pl...197870433386fb809d34b58b30fc0/sdcard/sdcard.c
You should pay attention to the README section of it starting at line 32.
When Android devices used to have an actual sdcard, it was formatted using vfat (the linux implementation of FAT32), with a mount point of /sdcard.
When they stopped including real sdcards, they started emulating sdcards using that FUSE simulated vfat I linked to above.
Now what sdcardfs is, is (a) a replacement for the FUSE filesystem I linked to above, and (b) a replacement for FUSE itself. Think of it as a scaled back and simplified FUSE+sdcard.c. The problem with FUSE is that it is too complex and with too high of an overhead. It causes performance degradation. And I'm not talking about the general userspace degradation that you would get with, for example, NTFS-3g compared to a native implementation, but rather the sdcard.c adds some problems because it is actually *abusing* FUSE. FUSE isn't designed or intended to wrap one filesystem with a simulation of a different one. FUSE is intended to actually implement a filesystem proper. What that means is that the kernel performs certain filesystem operations on the FUSE filesystem, which calls back to essentially perform the same operations on the base filesystem (ext4). Double the operations. Also double the caching, which is horrendous because it means that you are storing the same cached file in RAM twice. That is the kind of thing that sdcardfs is intended to solve.
Now personally, I completely disagree with this approach. Sdcardfs (as with FUSE+sdcard.c) is a backwards compatibility layer that really should be removed altogether. Instead, access controls to the data really should be by way of ACLs. Yes, this will break some very old software, but its the right way to move forward.

---

kkozma said:
I was able to get a build to complete but it doesn't boot. I don't have the time today to go over it, but if anyone has some free time, feel free to take a look at the logcat and see if anything jumps out immediately.
boot.log
Click to expand...
Click to collapse
Well, the first thing that stands out is this;
03-13 02:38:08.029 0 263 W VendorServiceManager: failed to open binder driver /dev/vndbinder
Indeed, the factory kernel does not have any such driver. This is probably something related to "Project Treble", which is supposed to make it simpler to update the android platform while leaving the *vendor* platform unchanged. Sounds like this driver will have to be added to the kernel.
https://android-developers.googleblog.com/2017/07/shut-hal-up.html
There is also this, which happens immediately before the SIGABRT for surfaceflinger:
03-13 02:38:09.975 298 298 F Gralloc2: gralloc-mapper must be in passthrough mode
Code:
Mapper::Mapper()
{
mMapper = IMapper::getService();
if (mMapper == nullptr || mMapper->isRemote()) {
LOG_ALWAYS_FATAL("gralloc-mapper must be in passthrough mode");
}
}
That gralloc issue could be a consequence of the vndbinder issue.
Hmm... https://github.com/SiXROM/platform_device_moto_shamu/commit/86ebb7db1b0a23c4d0a09568a6414d3b9f140596
Note that their changes to the BoardConfig.mk are bogus, none actually apply to this hardware. But the additional PRODUCT_PACKAGES are possibly meaningful.
Might try a build using these three projects;
<project path="device/moto/shamu" name="platform_device_moto_shamu" groups="device,shamu,broadcom_pdk,generic_fs,pdk" remote="sixoreo" revision="oreo" />
<project path="kernel/moto/shamu" name="platform_kernel_moto_shamu" groups="device,shamu,broadcom_pdk,generic_fs,pdk" remote="sixoreo" revision="oreo" />
<project path="vendor/moto" name="platform_proprietary_vendor_moto" remote="sixoreo" revision="oreo" />
sixrom has also made a whole lot of other changes, but I suspect that they are more related to customizations rather than actual device functionality.

---

I had seen the vndbinder thing the other day and added it to the kernel I'm using. I actually had it booting yesterday, but managed to hose it up trying to fix bluetooth and then ended up losing my boardconfig.mk and device.mk so I have to start over on those two.
I actually tried building with that sixrom repo and it wouldn't boot at all. I suspect it's because it's based on Lineage whereas mine is straight from AOSP.
Getting ready to play around with it some more, hopefully I can get back to a booting rom again!

---

kkozma said:
I had seen the vndbinder thing the other day and added it to the kernel I'm using. I actually had it booting yesterday, but managed to hose it up trying to fix bluetooth and then ended up losing my boardconfig.mk and device.mk so I have to start over on those two.
I actually tried building with that sixrom repo and it wouldn't boot at all. I suspect it's because it's based on Lineage whereas mine is straight from AOSP.
Getting ready to play around with it some more, hopefully I can get back to a booting rom again!
Click to expand...
Click to collapse
How do you lose your make files? Did you forget to commit them to your git?
Commit often, ESPECIALLY when you have things (anything) working.
Then if you bugger it up, just roll it back, of git diff it to see what you changed.
I don't see any evidence of sixrom being based on anything besides aosp (certainly not lineage/cm)
Take a peek at their manifest, there's a few frameworks that they've messed with, a bunch of applications, but its mostly AOSP;
https://github.com/SiXROM/manifest/blob/oreo/default.xml

---

Yeah, that was a real derpasaurus moment for me there, but I'm back to a bootable situation.
- Bluetooth is still broken
- No Cellular Radio
- WiFi connects but causes a reboot immediately
- Not able to view anything on the SD Card & Camera asks for an SD card to be inserted. Oddly enough I am able to play the music that's on my sdcard.
I'll get everything pushed up to my github later so if anyone else wants to tinker with it...
They probably haven't pushed the working updates to device to get to where they. As I said, I built directly from their repo and it didn't work at all.
Edit: my github is https://github.com/vwmofo
if you want to put together a local manifest and pull it down, feel free.