FORUMS

Marshmallow & Nougat (AOSP/CM/Lineage) for Nook HD/HD+ (& Tablet)

478 posts
Thanks Meter: 2,756
 
Post Reply Email Thread
This thread, and Marshmallow/Nougat porting in general, are a continuation of the previous KitKat and Lollipop development; the general installation steps are more or less the same. If you need a very detailed guide, PeteInSequim's is a good resource, especially if moving from stock. Read/search through the previous threads for any missing information (CM12.1 OP). That being said, I'm uploading personal builds of AOSP 6.0/7.1, CM 13.0/14.1, TWRP, etc, here.

Some of the important device-specific changes from KitKat/CM11 are described in Hashcode's thread. The goal is to remain fairly close to CM or AOSP upstream, and integrate whatever fixes and enhancements in unified device trees. More progress information will be added here gradually, as I have time. A lot of useful discussion happened on the previous CM11, CM12.[01] threads, and the status of things is available to anyone willing to search. I am not a developer, mostly a hobbyist, and the usual disclaimers apply.

AOSP vs CM

Initially, AOSP builds happened out of curiosity, but also necessity, since CM13 needs some time to stabilize. As expected, an AOSP ROM is a lot more barebones than CM, and there are pros and cons for each flavor. Now that initial porting is done following the previous philosophy of reusing and common-izing the device trees, it seems feasible to maintain both AOSP and CM ROMs (whenever 13 is usable), although nothing is promised.

In truth, the current builds are more accurately described as AOSP-ish; at the very least, a few core components need to be modified for our HALs, proprietary blobs, etc. On top of that, I've been adding features and fixes that seemed essential to me. Still, major differences remain compared to CM, and before people deem them as bugs, here are a few:
  • Wake with Home button: not an AOSP feature; I took the CM code to make it work in these builds.
  • The Advanced reboot menu: also a custom feature; may be ported at some point.
  • Mounting exFAT or NTFS media: not AOSP-supported filesystems, but a priority for me.
  • BusyBox was a CM extra, but I'm including it starting with the November 8th builds.
  • Etc, etc.
Because we have a reasonably flexible build system, other ROM flavors could happen in the future. A custom ROM like CM is actually easier to maintain than AOSP given all the fixes and enhancements that need separate maintenance with the latter.

The major difference with the first November builds is having SELinux enabled (albeit Permissive). It had to be kept completely disabled during the initial porting, due to a kernel bug/missing feature that took more than a week to track down. Thus, logs contain lots of AVC denials now, as sepolicy has not been fully updated for MM; no need to report or worry about these yet.

On a personal note, posting on my threads is pretty tricky business... My builds were never intended for general consumption, but rather a way to move porting and development forward, and I often debate only keeping the GitHub repositories for people to build themselves. Obviously, that would upset hundreds of people at this point, so I make an effort to upload reasonably bug-free builds, as well as help even with trivial non-problems whenever I can. Nevertheless, low quality, or badly written posts (and I don't mean bad English) are a sure way to get ignored, and my memory is pretty long term Basically, I won't police content here, but I also don't want to deal with the the kind of stupidity and entitlement so prevalent in real life.

In conclusion, no need to thank (unless you really want to), or ask about donating, etc, but do reassess the limits of your current understanding before making bold claims, as I do too. Nothing worse than having to fix a trail of misinformation... Also, comparisons to other people's work (unless constructive), complains about the state of things, or simply starting with "no offense" and such, will make your problem much less likely to be solved by me.

XDA:DevDB Information
AOSP 6.0/7.1; CM 13.0/14.1, ROM for the Barnes & Noble Nook HD, HD

Contributors
amaces, Hashcode, verygreen
Source Code: https://github.com/airend/android

ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.0.x

Version Information
Status: Nightly

Created 2015-11-02
Last Updated 2018-07-29
The Following 99 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
2nd November 2015, 03:50 PM |#2  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,756
 
Donate to Me
More
GApps & Partitioning Info

With unusual issues, especially if connected to Play Services, I recommend testing the ROMs without GApps before reporting bugs.

Currently, pico Open GApps should work on all AOSP, CM, or Lineage builds (M & N), although initial flashing should to be done before first boot (wiped data). With CM/Lineage 14, system space is barely enough, yet I still think we're fine with the current partitioning scheme. Changing it can introduce other complications, and haven't found an absolute reason for doing so. Nevertheless, it is possible to alter the partition sizes after installation, and thus increase available system space; @Lanchon prepared a pretty nice guide specifically for the Nook HDs.

About including GApps directly into the ROMs, I had tested this approach using the Open GApps manifests. While things can work better that way, legally, it wouldn't be a good idea to distribute these builds (for the same reasons CM had to stop including them). Also, I think there are a few people who wan't nothing to do with Google's proprietary services, so a likely deal breaker for them. We'll have to wait for the established packagers to decide how to deal with the MM changes, although my manifests are available, and one can include anything in personal builds.

Manifests & GitHub Branches

For people making their own builds, the customized manifests including my forked branches, and other changes, are kept more or less up to date at github.com/airend/android. There are currently three main branch pairs: cm-12/lolli, cm-13/marsh, and cm-14/nougat, the latter two being most updated. As the name implies, these manifests are based (and actually constantly rebased) on the corresponding upstream branch, either AOSP or CM/Lineage. Theoretically, once these manifests are stable, there is no need for local additions, but corrections might be needed nonetheless.
  • No need to repo init more than once, unless you're switching manifest branches (e.g., LP to MM, CM to AOSP, etc); repo sync will pull all manifest changes.
About naming conventions for my branches, I try to reuse as much as possible between CM/Lineage and AOSP, and when that's possible, branches are named lp-12, mm-13, etc. Otherwise, branches are named lolli, marsh, nougat, or cm-1*, depending on their base and specificity.
  • Upstream Lineage branch names haven't changed from old CM, and no current branch will be renamed here either (despite rebase).
The kernel repo contains additional feature branches named base/[subsystem], on top of Hashcode's last CM12.0 kernel. The main stable kernel is roughly equivalent to merging all these feature branches, although the history is different.

Recovery Information

We do have official TWRP images (https://twrp.me/Devices). While they don't work with CM12.1 anymore (for reasons described in that thread), they should be usable with all current Marshmallow builds.

More up to date eMMC TWRP images are included in the respective device folders. Personally, I've had a good experience with TWRP, and do not plan on looking at other recovery distributions. Now, there have been (very) sporadic reports of broken partition tables, soft-bricked devices, etc, blamed on recovery. Although recovery is usually not the actual culprit, here are some ways you can rescue a completely unresponsive device:

The instructions below are generic, and were meant for CWM. TWRP has all these image flashing features in the GUI, so CLI/shell is not strictly needed.
  1. It's a good idea to keep a microSD card around, with my external recovery image, or verygreen's.
  2. Once booted off the external recovery, you can easily fix whatever is broken (ADB is your friend here). There's no need to re-install CM11, as re-flashing recovery and/or boot will most likely fix your issue.
    • Recovery partition: dd if=<path to recovery image> of=/dev/block/platform/omap/omap_hsmmc.1/by-name/recovery
    • Boot partition: dd if=<path to boot/kernel image> of=/dev/block/platform/omap/omap_hsmmc.1/by-name/boot
  3. Afterwards, you should at the very least have a working internal recovery. I don't recall any instance where /system and/or /data became corrupted because of recovery, but you can certainly fix them now.
  4. I've never tested this part, but I believe that you may be able to install an eMMC CM12 ZIP with verygreen's external CWM, even if /data and /cache are F2FS (assuming you copied all ZIPs onto the external card). My understanding is that only /dev/block/platform/omap/omap_hsmmc.1/by-name/system (always ext4, mountable by any recovery) is touched during installation, so you may even bypass TWRP completely.
P.S. If you broke you bootloader by flashing the wrong recovery flavor, despite all images being clearly labeled as hummingbird or ovation, well, no sympathy for you… Still, you can bring your device back to life within minutes as described above.
The Following 15 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
2nd November 2015, 03:50 PM |#3  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,756
 
Donate to Me
More
Selected FAQs
  1. Should I use AOSP or CM/Lineage?
    Depends entirely upon personal preference, which requires testing, and some amount of research into what makes a ROM different. There are substantial core differences between the two flavors, which are not obvious immediately. If installing for the first time, flip a coin (and avoid builds in experimental, of course).
  2. How do I get root back?
    Until recently, some type of SU binary was included with all ROMs (WITH_SU=true on CM/Lineage, or using this repo on AOSP). This was needed because third-party system-less solutions don't work with our quirky bootimages, and system-mode installers have other issues on N. As builds mature, I'm separating the SU backend from main OTAs, roughly like CM/Lineage did. On my Nougat builds, there are currently two system-mode options:
    • On AOSP, I adapted phh's OSS backend for system-mode install (addonsu-phh-arm.zip). You need the matching manager to control access. Later on, I ported CM/Lineage's AppOps-based SU to AOSP, so that addon works here as well (see next item). These binaries need to be flashed after every ROM update, same as GApps.
    • On CM/Lineage, you can install their official add-on (addonsu-arm-signed.zip); it will use the baked-in manager, so no extra APK required. Or, you can install phh's SU and manager, like on AOSP. Neither needs to be flashed more than once here given the existing addon.d support.
  3. Why no official CM/Lineage builds since 12.0?
    The answer involves both technical complications, and some amount of politics. Getting changes accepted for non-mainstream/deprecated platforms like ours has been an uphill battle. Over time, many OMAP4 improvements have been developed outside CM, formerly by OMAP4-AOSP, now the Unlegacy-Android project. Those common hardware improvements have made it into 13.0/14.1 only recently, due to other people's perseverance. Although we're much closer to upstream Lineage compatibility, the hundreds of device tree, and more than a thousand kernel changes would still need to go through review. Given how long that takes for each item, and occasional opposition from non-OMAP4 reviewers, I decided to allocate my resources towards bettering these devices rather than official status. The downside is that people may feel dependent on my builds, which shouldn't be the case; I constantly rebase and maintain complete manifests, optimized for these devices. All the relevant changes are open and available in public GitHub repositories, which means anyone can submit them/try to work with upstream Lineage. However, for the above reasons, it's unlikely that I will make that effort.
  4. What's the current status of full screen casting, Miracast, HDMI, etc?
    Full screen casting to a Chromecast sink (either real, or emulated) works on all current Nougat builds. CM13 builds may have issues there, but AOSP M was fixes. Chrome casting from apps (the preferred way, if available) was never broken. Miracast in AOSP is pretty much legacy tech now. It also requires more hardware support compared to Chromecast-ing, and it probably doesn't work on any recent builds. Fixing HDMI is still a goal; it got broken on our devices after some Marshmallow revision. Until HDMI can be fixed, I disabled it completely to recover its unused VRAM allocation.
The Following 20 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
2nd November 2015, 07:39 PM |#4  
Senior Member
Thanks Meter: 86
 
More
Will this (continue to) be based off AOSP, or CM?
2nd November 2015, 10:42 PM |#5  
Monfro's Avatar
Senior Member
Flag Mantova (Italy)
Thanks Meter: 1,100
 
More
Quote:
Originally Posted by belfastraven

@amaces, I am currently running with the 11/01 hummingbird build from experimental, which I installed yesterday. It doesn't work as well for me as the 10/29. It is laggier, and for some reason right now, I can't log into from the kindle app. I also note that on rebooting, it will go through the boot cycle more than once, optimizing various apps each time. Of course, since it just numbers the apps, you can't actually tell what it is doing. . I think there are olicy/permission issues since trickster mod can't install busybox into the system partition and, as stated before, system won't boot into to revery, soft boot, or shutdown, without use of power,home keys. Do you wan't logs?

thanks again.

On Ovation it is the same: 10/29 is far better than 11/01.
Graphics problems on 11/01: the screen shows some green lines sometimes and it feels laggier.

---------- Post added at 11:42 PM ---------- Previous post was at 11:40 PM ----------

Quote:
Originally Posted by twiztid_

Will this (continue to) be based off AOSP, or CM?

I would prefer AOSP: less customization means less resources needed.
...and for Ovation every MB of ram free can be fundamental.

Or maybe both versions
The Following User Says Thank You to Monfro For This Useful Post: [ View ] Gift Monfro Ad-Free
3rd November 2015, 12:26 AM |#6  
Senior Member
Thanks Meter: 215
 
More
For some happy news, multi-window mode (enable in developer options) seems to work pretty well (on my HD) It's probably even more useful on the HD+ where you have more real estate.
The Following 2 Users Say Thank You to belfastraven For This Useful Post: [ View ] Gift belfastraven Ad-Free
3rd November 2015, 01:30 AM |#7  
Senior Member
Thanks Meter: 177
 
More
Thank you @amaces for M!

Questions:
  1. Are your repos in a state that I can start trying to build it?
  2. Is this your (local) manifest https://github.com/airend/android/bl...sh/default.xml
  3. I saw the above manifest and tried to build a couple of days ago and got many errors just updating my local repo. I'm reckoning that the manifest has such a mishmash of projects that I should probably delete my entire repo and download it all again. Is this likely the case?
Again, thanks. I'm so excited!
3rd November 2015, 02:44 AM |#8  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,756
 
Donate to Me
More
Things are still busy till probably tomorrow afternoon, but I will add proper replies here, and on the CM12 thread soon. As of now, there must be a few dozen posts I need to go through, plus lots of other updates.
The Following 8 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
3rd November 2015, 06:26 AM |#9  
Senior Member
Thanks Meter: 29
 
More
Quote:
Originally Posted by amaces

Things are still busy till probably tomorrow afternoon, but I will add proper replies here, and on the CM12 thread soon. As of now, there must be a few dozen posts I need to go through, plus lots of other updates.

Is gapps for 6.0 available? If so, which one do you recommend?
3rd November 2015, 12:26 PM |#10  
Senior Member
Thanks Meter: 472
 
More
Quote:
Originally Posted by js290

Is gapps for 6.0 available? If so, which one do you recommend?

OP has only two paragraphs. Try reading it again.
The Following 4 Users Say Thank You to extrem0 For This Useful Post: [ View ] Gift extrem0 Ad-Free
4th November 2015, 02:47 AM |#11  
Senior Member
Thanks Meter: 397
 
More
I have 2 HD+ and wanted to dedicate one to Marshmallow. I spent time with this build and it just became too frustrating.

I did find a gapps benzo-gapps-M-20151011-signed-chroma-r3.zip that did get rid of the nag messages with settings in settings-apps. I'll get links if others are interested. AdaWay 2.2 did give some strange messages about BusyBox scripts but it turns out there is a Mars working version of AdaWay, AdAway-release_Build-Oct.09.2015.apk that I haven't tried yet.

Very frustrating not really being able to use the ExtSdcard. Installation of apps is not that simple without using a third party browser.

First efforst here are great. If you look at first efforts on phones, disaster and pre=alpha is what is going on.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes