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

Search This thread
By:
Advanced…
D

Diagon

Member
Nov 20, 2014
46
6
nmyshkin said:
I truly appreciate the work @amaces has done but I have to say I think those listings are somewhat possessed. My copy shows the date I listed. Whatever, it works. As to the ROM, it's in the "obsolete" folder. Many interesting things are.
Click to expand...
Click to collapse

Thanks nmyshkin. I got a bit frustrated by the date issue and finding the ROM's, so I went through all those folders and listed what we have for the acclaim (below). For a couple the "creation date" and the "modified date" are different, which explains some of the confusion.

I've been trying to install the newest LNOS, but was having the same trouble you were with root. Then I discovered amaces' Selected FAQ. In point 2 he describes that for LNOS, we have two ways of getting root. We can use the offical addon-on, and then turn on root by this method. Or, we can "install phh's SU and manager, like on AOSP." So it dawned on me that I should flash addonsu-phh-arm.zip (which I found in obsolete) and then on reboot, install phh's superuser manager from f-drod. That worked!

Earlier, I had tried getting the LNOS offical addon (dated 2017.06.21) and turning it on by the method described in that link (tapping Build Number 7 times ...) I couldn't get it to work. It then dawned on me that maybe amaces' addonsu-14.1-arm.zip (2018.02.11/2018.12.01) and addonsu-14.1-arm-new.zip (2017.06.14, in ~/obsolete) are earlier versions of LNOS's official addon - perhaps even modified, I don't know. So I tried the former, now armed with the Build Number trick (which I hadn't known the first time I tried). That also worked! I was able to get root without PHH's superuser manager, via Settings >> Developer Tools! And, you'll be happy to know, Kodi is also running fine. :)

By the way, I found the "Root Verifier" utility in F-Droid to be useful.

[I will add that I still have not figured out how to install open_gapps-arm-7.1-pico-20201209.zip. TWRP complains about there not being enough room. I don't really need it, but I'd still like to know ...]

---------------------
addonsu* in ~:
Created Feb 11, 2018, modified Dec. 1, 2018: addonsu-14.1-arm.zip

addonsu* in ~/obsolete:
June 14, 2017: addonsu-14.1-arm-new.zip
June 14, 2017: addonsu-phh-arm.zip

lnos_acclaim* in ~/acclaim:
Jul 13, 2018: lnos_acclaim-ota-NJH47F.180713.zip (@Diagon: not working with non-obsolete addonsu)

lnos_acclaim* in ~/obsolete:
June 24, 2018: lnos_acclaim-ota-NJH47F.180624.zip
Feb 11, 2018: lnos_acclaim-ota-NJH47F.180211.zip (@nmyshkin: works with non-obsolete addonsu )
Oct 21, 2017: lnos_acclaim-ota-NJH47F.171021.zip
Many more from 2017:
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/194284828538
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/183387854409
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/167015800286
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/160119425778

aosp_acclaim* in ~/acclaim:
Jul 12, 2018: aosp_acclaim-ota-N2G48H.180713.zip
Aug 20, 2016: aosp_acclaim-ota-MOB30Z.160820.zip

aosp_acclaim* in ~/obsolete:
Feb 11, 2018: aosp_acclaim-ota-N2G48H.180212.zip
Dec 6, 2017: aosp_acclaim-ota-N2G48H.171206.zip
Many more from 2017:
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/239786866386
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/181740463774
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/174211215128
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/166931447258
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/160110315881
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/155563266439
Many more from 2016:
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/99602620259
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/73494456549
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/69855406537
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/65739412537
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/63777554973
https://notredame.app.box.com/s/26a4bygh9vbaw7jjq08xr5evomvaw5ww/file/63636884797
 
Last edited:
  • Like
Reactions: mikeataol and nmyshkin
D

Diagon

Member
Nov 20, 2014
46
6
Just for anyone else who is coming this way ...

My version of TWRP after installing via amaces' root method and subsequently repeating the procedure from 3d to install the presently newest LNOS ROM, lnos_acclaim-ota-NJH47F.180713.zip, was 3.0.2-0. That had been installed as a zip. (I removed the recovery.img from that zip and confirmed it's the same as the official TWRP image.) The TWRP website's latest is 3.1.1-0, so I tried to install that official image according to one of the methods in these directions. Namely, flashing the new recovery image from the old. That failed on attempted reboot to the recovery. (Black screen, backlight on.) Perhaps it would have worked if I used a different method? I then tried another approach described there: downloading the most recent apk, and installing it. That downloaded the img file I selected (this time, 3.1.0-0), but then kept crashing when I tried to point the app to the location of that .img. So, I fell back on a third method described there. Namely, using a terminal to dd the image:

su - root; dd if=/sdcard/twrp.img of=/dev/block/mmcblk0p3

The image I finally used with dd was amaces' ~/experimental/twrp-3.2.2-0-acclaim.img. That appears to be working. I haven't backed up or restored with it, but I can go into recovery and all the menus are acting sensibly. If I have any trouble, I'll try going back to 3.1.1-0 and dd'ing that in.
 
Last edited:
  • Like
Reactions: nmyshkin
X

xdause

Senior Member
Jun 18, 2009
191
19
not sure where to post this but it seems amaces lnos_ovation-ota-NJH47F.181223.zip won't work with the latest gapps pico. says there is not enough room. Found the repartition thread and got it to work.
 
Last edited:
  • Like
Reactions: maninalift and Diagon
M

maninalift

New member
Jan 21, 2022
2
0
xdause said:
not sure where to post this but it seems amaces lnos_ovation-ota-NJH47F.181223.zip won't work with the latest gapps pico. says there is not enough room. Found the repartition thread and got it to work.
Click to expand...
Click to collapse

Is it this thread that you used?

forum.xda-developers.com

[Nook HD/HD+] REPIT: enlarge /system and /data partitions without wiping your data

you can now use REPIT to increase the size of the /system partition on the Nook HD/HD+ to 1 GiB to support the newest roms with gapps. while you do this, you can optionally also add 0.5 GiB of free space to /data. the extra space is repurposed...
forum.xda-developers.com forum.xda-developers.com

I'm experiencing the same problem and about to give REPIT a try
 
X

xdause

Senior Member
Jun 18, 2009
191
19
maninalift said:
Is it this thread that you used?

forum.xda-developers.com

[Nook HD/HD+] REPIT: enlarge /system and /data partitions without wiping your data

you can now use REPIT to increase the size of the /system partition on the Nook HD/HD+ to 1 GiB to support the newest roms with gapps. while you do this, you can optionally also add 0.5 GiB of free space to /data. the extra space is repurposed...
forum.xda-developers.com forum.xda-developers.com

I'm experiencing the same problem and about to give REPIT a try
Click to expand...
Click to collapse
I think so. it's been a while but many apps in ovation is no longer compatible like google voice in android 7.1.2 nougat play store seems to have corrupted had to clear cache/data of play store to get updates back. i'm basically just using this as an ereader as wifi still needs to be reenabled if it gets turned off (read known bugs https://forum.xda-developers.com/t/2021-how-to-install-android-7-1-2-on-a-nook-hd-or-nookhd.4259749/). I'm actually thinking of restoring to stock since the play store seems to be dead. not even sure how to repit back to stock.
 
Last edited:
F

flyingpreacher

Member
Mar 10, 2014
7
6
I know this thread is wayyy old now, but for anyone who is interested, I got Marshmallow installed on my Nook HD Plus with GApps and got ROOT!
Here is what I did:
I used cm_ovation-ota-MOB31K.161125.zip from Amaces folder here.
I uploaded the Open GApps zip to Mediafire here. The current ones won't fit because they are too big for the system partition and you will get an error. The SuperSU root zip is here.

I rebooted to TWRP recovery and wiped my system, data, and other partitions clean. Be careful not to wipe your SD card! I changed data and cache to F2FS, then I installed the ROM and GApps zips. I rebooted and then I waited... It takes 4-5 mins for the first boot. I mention that because I don't want anyone to think their Nook HD is stuck.

Once you setup your Nook after the first boot with GApps, reboot to TWRP and install SuperSU. Reboot back into your system. That should be it. You are now rooted!

I hope this helps someone. I was excited about it and I hope you can get excited too. :D
 
  • Like
Reactions: StableColonel and Sus_i
S

Sus_i

Senior Member
Apr 9, 2013
1,563
666
flyingpreacher said:
I used cm_ovation-ota-MOB31K.161125.zip from Amaces folder here.
I uploaded the Open GApps zip to Mediafire here. The current ones won't fit because they are too big for the system partition and you will get an error. The SuperSU root zip is here.
Click to expand...
Click to collapse
My nook hd+ works fine with aosp / lineageOS 14.1
I installed the aosp_ovation-ota-N2G48H.181223.zip and flashed open_gapps-arm-7.1-pico...
and for systemless root I use Magisk. :)
 
  • Like
Reactions: flyingpreacher
F

flyingpreacher

Member
Mar 10, 2014
7
6
Sus_i said:
My nook hd+ works fine with aosp / lineageOS 14.1
I installed the aosp_ovation-ota-N2G48H.181223.zip and flashed open_gapps-arm-7.1-pico...
and for systemless root I use Magisk. :)
Click to expand...
Click to collapse
I could not ever get mine to work as well with LineageOS. I always had wifi problems or graphical glitches. Maybe I will try it again some time. Thanks for the info!
 
  • Like
Reactions: Sus_i
You must log in or register to reply here.

Similar threads

V
[Nook HD/HD+] EMMC CM11 install - updated 11/29
Replies
2K
Views
662K
Ninja515
Ninja515
leapinlar
[CWM/ROOT/UNKNOWN SOURCES] HD/HDplus Stock Root/other Mods - via CWM flashable zips
Replies
1K
Views
664K
E
ekoms420
amaces
UNOFFICIAL CM12.1 for Nook HD/HD+ [2015-12-18]
Replies
1K
Views
417K
digixmax
digixmax
V
[NookHD/HD+] CM10.2 updated 01/18
Replies
2K
Views
355K
J
jpisini
V
Nook HD+ CM10 development (sdcard) updated 5/11
Replies
741
Views
287K
Monfro
Monfro

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 98
    amaces
    amaces
    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
    View
    20
    amaces
    amaces
    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.
    View
    16
    amaces
    amaces
    KRACK, Oreo Plans, etc.

    dbrickg said:
    any development -- or even thoughts about development -- of oreo for our everlovely nooks?
    Click to expand...
    Click to collapse

    Definitely my goal, and these were the devices I first started porting to Oreo, but this release really strains the limits of our current kernel and vendor blobs. Fortunately, updated blobs have recently become available, yet legally it's not possible to incorporate them into public builds. I don't know when this will change, and given that it took years to get here, I need to continue working on the old DDK for Oreo. The second issue is about current Wi-Fi stack, which fails on Oreo; the new drivers that I prepared before summer do work, but then about a third of people here didn't like them.

    If we're lucky and these two issues can be solved with current drivers, Oreo builds can happen sooner. Otherwise, it all depends on the ability to distribute the new DDK blobs.

    digixmax said:
    The freeze issue I am having with my HD+ running build 08/13 is getting worse in frequency and length.
    Click to expand...
    Click to collapse

    These devices are severely RAM-limited at this point. All sorts of races happen between LMK, zRAM, and other memory management with increased memory pressure, which is a constant state after adding GApps... Oreo might slightly improve this management, but really we need better kernel, graphics DDK, and many other things where progress is slow.

    MossyTC said:
    Official LineageOS has applied patches for the Krack Wifi vulnerability. Are there plans to include these patches?
    Click to expand...
    Click to collapse

    xMandy said:
    Do you know when you'll find time to create/cook a new "nightly" for the hd+ with latest security patches and so on?
    Click to expand...
    Click to collapse

    New builds are uploaded in experimental. Unfortunately, Google has stopped updating 7.1.2 since August, but at least KRACK and possibly BlueBorne should be addressed in the latest AOSP builds. Lineage also includes these fixes, and more. At some point, I need to update the thread to highlight the Unlegacy-Android builds, which happen weekly, and tend to incorporate all security patches on AOSP.
    View
    15
    amaces
    amaces
    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.
    View
    14
    amaces
    amaces
    secretwolf98 said:
    LineageOS 15.1 is released. https://www.lineageos.org/Changelog-16/
    will our Nooks be getting Oreo?
    Click to expand...
    Click to collapse

    Did I not emphasize that the roadblock so far is not Lineage, or even AOSP? We cannot use current DDK UM blobs, and new blobs are not legally available. After quite a bit of work, I've ported all the required parts (e.g., Binder, alarmtimer, timerfd, etc) to our 3.0 kernel (as well as to the unreleased K3.4); as soon as I'm able to use the new UM blobs (or somehow fix the current 1.9 DDK), Oreo builds can happen fairly quickly.
    View

New posts