Thoughts on Oreo...

[EagerestWolf]

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.

 

[konradit]

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

 

[Davies_90]

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

Looking promising,fingers crossed

Sent from my Nexus 6 using Tapatalk

 

[Dopamin3]

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

 

[ctfrommn]

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

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.

 

[wrongway213]

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

 

[kkozma]

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.

 

[Arju]

So the development for Xiaomi Mi3/Mi4 has gone online: https://xdaforums.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.

 

[kkozma]

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

 

[wavedashdoc]

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

@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://xdaforums.com/nexus-7-2013/development/rom-t3569067/page60

the struggle continues.

 

[zelendel]

@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://xdaforums.com/nexus-7-2013/development/rom-t3569067/page60

the struggle continues.

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.

 

[Strephon Alkhalikoi]

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

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.

 

[zelendel]

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

People are not gonna do that. Microg is known for causing its own issues.

 

[wrongway213]

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.

People are not gonna do that. Microg is known for causing its own issues.

It's been confirmed that gapps for arm are working since I posted that, so it's a moot point now, thankfully.

 

[Lawstorant]

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.

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).

 

[luciusfox]

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).

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.

 

[luciusfox]

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

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

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.

 

[kkozma]

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!

 

[luciusfox]

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!

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

 

[kkozma]

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.