yashsingh1/xdaforums huggingface dataset:
[Nook HD, HD+ Android Development] sega dude:
That worked. Upon reboot, after flashing the Magisk zip I had to manually install the Magisk app (I uninstalled it before attempting to flash the zip). When I opened the Magisk app after that it said that I needed to reflash Magisk through the app. I was able to do that without issue and I now have working root. I never would have thought to rename the apk to a zip and flash it. Thanks.
[Nook HD, HD+ Android Development] ze7zez:
Installation

The Magic Mask for Android

topjohnwu.github.io
[Nook HD, HD+ Android Development] xecutionkrk:
cm_ovation-ota-MOB31K.161125.zip link is dead
[Nook HD, HD+ Android Development] bzz11g:
i save some builds here https://mega.nz/folder/wYUUTI6K#mUYavci1iDpoI1NlZkhdQg
[Nook HD, HD+ Android Development] IndyRoadie:
As did I. Everything seems to be working well so far
[Nook HD, HD+ Android Development] mirktamas:
Can someone help me?

Where from can I download CM13? Couldn't find the link.

I have CWM based Recovery. Should I just flash over TWRP recovery?

Thank you in advance
[Nook HD, HD+ Android Development] Shadowpain:
Link

Flash twrp first

Factory reset

Install cm13

Install opengapps (pico variant recommended)
[Nook HD, HD+ Android Development] mirktamas:
Thank you.

I've just installed it over CWM not over TWRP.

Am I going to face some issues later?

I don't use Gapps
[Nook HD, HD+ Android Development] neutronjeff:
Did anyone else notice on an ovation that it will actually power off if you do it in landscape orientation? I accidentally discovered it this morning.
[Nook HD, HD+ Android Development] Mac Hosehead:
This doesn't seem to make any difference in hummingbird. Actual power-off seems intermittent. I noticed home screen seems set at portrait but not lock screen. Both issues are not bothersome. Everything else I've tried runs pretty well. 60fps HD runs OK.
[Nook HD, HD+ Android Development] Shadowpain:
This happened on me 2 times only at the first 10 minutes after i installed cm13 , but everything is working perfectly after that for a week that i'm using it
[Nook HD, HD+ Android Development] RhinoNelson:
My only 'issue' is that while the lock screen and running apps auto-rotate my home screen and the screen with all my apps don't rotate. I looked in Settings and Auto -rotate is on. My sense is I am missing something rather than the ROM being an issue. Other than this, performance for what I use is terrific.
[Nook HD, HD+ Android Development] Shadowpain:
Maybe it's a launcher issue . Try nova launcher
[Nook HD, HD+ Android Development] Mac Hosehead:
Yes, it is the launcher.
[Nook HD, HD+ Android Development] belfastraven:
1st successful optimized build cm13+optim

[MENTION=4473900]amaces[/MENTION], [MENTION=3651088]Zippy Dufus[/MENTION]

Using UBERTC 5.3- toolchains.- (see image from trickster-mod.) optimized for cortex-a9, running with default archidroid, O2, (except initially used Os for audioflinger service and haven't tried without it yet).

There is some bad syntax in a makefile which stopped recovery from being built--

I commented it out--

#ifneq ($(ARCHIDROID_IGNORE_RECOVERY_SIZE),true)

# $(hide) $(call assert-max-image-size,$(1),$(BOARD_RECOVERYIMAGE_PARTITION_SIZE))

#endif in Makefile in build/core

Why are we compiling recovery anyway? Since we are using prebuilt TWRP...http://cdn2.xda-developers.com/images/smilies/eek.gif It took a few hours for me to find problem.

Anyway, will report back tomorrow after 24 hours of running. So far everything is good.

Should we be trying for O3?-My understanding is that that will made image bigger...
[Nook HD, HD+ Android Development] prsa01:
Battery drain during non use

For me this rom works great. I do 90% chrome w/5 - 8 tabs & occasional videos.

Certainly not the fastest thing, but very usable considering the hardware limitations.

An ongoing issue is that while in use I get reasonable battery time (most of a day browsing , etc). It often will sit for a day or more unused (nexus 7 2013 is primary tab) and is always completely drained. I'm just starting the process of tracking down the culprit(s). I've installed battery doctor & greenify and will see what they tell me.

?s - Is this what others are seeing with these roms so no reason to waste time trying to pinpoint app(s)?

Preferred apps for battery/app reporting?

Thanks for any insites and, as always, BIG thanks to OP
[Nook HD, HD+ Android Development] TeutonJon78:
How are people finding ext4 vs f2fs for the data partition? Benchmarks seem to put f2fs to be a little faster overall, but not blow your hair back faster. Thoughts?

Edit: also is anyone else getting phantom touches? I never had this problem before (I know others have), but on MM i'm getting a lot of them.

Edit2: reboot seems to help with the touches. Also had a problem of the power button not waking it up. Another question: Under Settings > Wifi > Advanced, should there be the option for "scan even when wifi is turned off"?
[Nook HD, HD+ Android Development] belfastraven:
I normally keep mine plugged in when I am not using it, so I don't know yet what would happen if left it for 24 hrs.

Have you looked at "battery" in settings? It will give you a list of apps that are using the battery, and how much they have used it since the last full charge. The trickster mod free app from the play store will tell you how much time the tablet has spent in various states. If you've not used it very much in any one day, it should be in "deep sleep" the majority of the time. (Mine noramlly sleeps about %79 of time, but I have apps that are updating via wifi even when I am not using the tablet and I leave WiFi on all of the time.
[Nook HD, HD+ Android Development] belfastraven:
Using Geekbench 3 on my {franken}Nook HD, (cm13 +Optim) 01/016 repo sync) I'm getting from 434-444 single core, 818-825 both. I get the same sorts of numbers running test on a nook hd running amaces AOSP build with UBERTC 4.94 optimized kernel. I don't know what the margin of error is on tese tests, but I'm pretty sure that so far, the changes are not making much of a difference. I'm going to play some more tonight. (Ijust downloaded the 212 page gnu manual for "make"--I need to do some catching up on this environment http://cdn2.xda-developers.com/images/smilies/confused.gif
[Nook HD, HD+ Android Development] dbrickg:
cm_ovation-ota-MMB29T.160110

I finally got around to installing the 160110 zip on my hd+. I just dirty flashed it over my old cm12.1 from way back in October. I haven't done much testing yet, but wanted to say it installed, booted up, and all the apps seem to be working. Thanks much to all of you for continuing to work on this!
[Nook HD, HD+ Android Development] amaces:
So, it feels like we're injecting more confusion in the thread… The kernel toolchain (ARM EABI) is totally separate from ROM's (Android EABI), and their compilation flags are also different. The +optim branch I set up will only change how the ROM gets built; the kernel Makefile has been optimized very aggressively many months ago, and newer toolchains will make little difference there.

What Trickster reports is the kernel toolchain; you're likely using the same arm-linux-androideabi-4.9 for ROM.

The Uber toolchains are not pre-optimized for a specific ARM or Cortex CPU.

Our tweaked kernel Makefile achieves much more now, and is optimized for our flavor of Cortex-A9.

GCC5 support was added last fall; can even build with the experimental GCC6

Given the above, little performance changes expected with up-to-date EABI 4.9, 5.[123], or even 6.0

Basically, what we're testing now is ROM optimization, which is much more finicky. Coding quality differs between the many components therein. The optimized build branch reflects the last successful CM12 tweaks, which may or may not improve Marshmallow.

Keep in mind that you need to reinitialize your environment (source envsetup.sh, plus device lunch/breakfast) after every change to the build system!

It must have been something else that stopped the build; this conditional recovery size assert looks right, and unless something went haywire with the recovery image content, no reason to trigger it.

The ROM incorporates code from recovery, plus the recovery image is a build task for otapackage or bacon. Also, it's a good idea to know when there are issues with TWRP, even if we never actually use these images.

The images will be larger, yes, but that's the point of testing. As of now, CC_OPTIMIZE_FOR_SIZE selects between the three optimization sets that I prepared in the top cm-13+optim commit. When unset/commented out, it's -O2 based; true, or false will switch between -Os, and -O3 (default), respectively. That's only part of the equation, since these base optimization levels are heavily tweaked with additional Graphite, vectorization flags, etc.

Things that you could test are:

Whether everything compiles properly with every set, and if the build breaks, where.

Compare the four possible builds (normal -O2, plus the three options described above)

More advanced changes inside the actual optimization sets (e.g., ARM, loop unroll, etc).
[Nook HD, HD+ Android Development] Zippy Dufus:
This issue broke my build too (01/16) and commenting those lines out worked around it. I couldn't see a problem in the code, but I'm no expert.

== //==

From my experience with hacking with different toolchains, different issues arise with each toolchain. Fascinating! The kernel is easy to compile with arm-eabi, but the rest of the ROM with arm-linux-androideabi is problematic. For example, I'm stuck again on linking in the proprietary blobs with ArchiDroid 5.2.0 but my 5.2.1 build completes with a couple of minor patches. But, this build refuses to install.

I see that CM13 nightlies are now available for my old Nook Tablet so I will hack on it for a while and circle back to the HD+ once I prove that I can get my 5.2.1 toolchain working on "some" device. :cowboy:
[Nook HD, HD+ Android Development] belfastraven:
from my envsetup.sh

export ANDROID_TOOLCHAIN=

export ANDROID_TOOLCHAIN_2ND_ARCH=

local ARCH=$(get_build_var TARGET_ARCH)

case $ARCH in

x86) toolchaindir=x86/x86_64-linux-android-$targetgccversion/bin

;;

x86_64) toolchaindir=x86/x86_64-linux-android-$targetgccversion/bin

;;

arm) toolchaindir=arm/arm-linux-androideabi-5.3-cortex-a9/bin ==============here

;;

arm64) toolchaindir=aarch64/aarch64-linux-android-$targetgccversion/bin;

toolchaindir2=arm/arm-linux-androideabi-$targetgccversion2/bin

;;

mips|mips64) toolchaindir=mips/mips64el-linux-android-$targetgccversion/bin

;;

*)

echo "Can't find toolchain for unknown architecture: $ARCH"

toolchaindir=xxxxxxxxx

;;

esac

UBER provides scripts to build the optimized tool chains: see here:https://github.com/UBERTC/uber-scripts If you use their repository, they end up in the scripts directory.

Yes--I understand.

Nope that is for sure what triggered it. The only reason I eventually figured it out is that the error message would be different (The comparison of true, to the unknown value) depending on whether I changed the value on the assertion in the Archidroid.mk or commented it out. If I uncomment those three lines--I stop always at the same place, commenting, I would successfully build. I did this several times.,

I think I have actually been using -O3, but have always had to use Os for the services/audioflinger android.mk

LOCAL_CFLAGS += -Os

The only place I found the flags being set was in the archidroid.mk. I don't quite understand your comment re their being in your first commit. (sorry, I'm really a newby re makefiles). Could you clarify, where to I need to choose one of the four builds? I will check out the ARM-Options.html web site.
[Nook HD, HD+ Android Development] amaces:
His acclaim CM13 repositories have been alive for a couple of months now. Anyway, good luck with GCC5; at least on Lollipop, you couldn't even compile the whole of Android without many patches, and all that work had limited benefits. You may get additional mileage by looking through the UBERmallow repositories.

Modifying build system files is not needed, and generally not recommended for things like changing toolchains. I for one don't know all the ramifications of implementing changes there, or how well they play with the other core Makefiles. The easy (albeit brute force) approach is to simply move whatever toolchain into prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9. The more elegant solution is to use the proper flags inside the device trees.

Right, I'm only talking about the prebuilt toolchains that people normally use. For kernel, those optimizations should make zero difference since they're fully included in the optimization set honed a while back. ROM-wise, using a Cortex A9 tweaked Android EABI would introduce a different baseline, making it harder to discern between our flags versus hardcoded stuff.

If you haven't changed anything, -O3 is default on the +optim branch.

The top commit means the last change in the respective Git log. Regular cm-13 branch is vanilla -O2; the three other options discussed are available when you switch to the +optim branch and turn on/off, or unset my CC_OPTIMIZE_FOR_SIZE flag.

What I meant with my previous replies, and may have gotten lost between the lines, is this: there's a natural progression to making your way through all the moving parts that Android entails. With my current understanding, which is far from complete, I can say that rushing into advanced changes, before having a good handle on the basics, will only create problems later on. And by basics, I primarily mean Git, repo, the location of major things, and generally what the best practices are.

What happens when you pull/repo sync next? Are you local changes committed somewhere? Are branches set up to track changes upstream? If changes are made, were they tested sufficiently, to yield meaningful results? Etc, etc… There was this energy already geared for custom toolchains, so I made my suggestion about ROM optimization as a way to collect useful results. Dumping reams of benchmarks or build system guts does not achieve that, especially when consistency becomes an issue.

Otherwise, it's a free country; people will work on whatever is most attractive to them.
[Nook HD, HD+ Android Development] TheHamPimp:
Yeah, I'm seeing the same thing. On one of the earlier CM12 builds, i could easily go a week+ without charging (I use mine for about 30-45 minutes/day). Now, I get about 2-3 days of use before it's dead. I don't even have Play store installed, so no apps....I just use it for web surfing with the built-in browser. No changes to system settings. I'll look at my battery use tonight to see what might be siphoning off my precious carbon.
[Nook HD, HD+ Android Development] ieatabiscuit:
I had the well known random battery readings come back after flashing to try out a few ROMs. Once it returned, it persists after flashing more ROMs. I believe I may have fond a possible fix for it. I remembered that on my phone there's a known issue with 4G after repeated flashes, and tried the fix for that on my ovation as a last ditch effort as I had already eliminated any hardware issues as a possibility. I had to revert back to full stock ROM AND recovery. Reboot to the rtecovery wth the hardware buttons method, and from there do a full factory reset. After that, reflash twrp, and the aosp build from here with open gapps, and it's been running flawlessly for me. Even got me some xposed more going on. I have found no faults in any uses I have, and the battery is reading properly. Also I never turn mine off, it will stay on a single charge for a weak easy if I use it less frequently than I do currently.
[Nook HD, HD+ Android Development] asakurato:
When I connect tab to computer, default connection is always charging and I have to change to file transfer all the time. Can I change default option?
[Nook HD, HD+ Android Development] LBurdick43:
I've been running the Ovation MM 1-10 build with OpenGApps for about a week, no issues at all. Then yesterday, it crashed out of nowhere, and I wasn't even using the tablet at the time. It got stuck in a boot loop when I tried to boot Cyanogenmod, and the same happened with the recovery. I whipped up a bootable SD, and that works fine for both the recovery and ROM. SD card TWRP says it can't mount /eMMC nor /bootdata, so I can't wipe them. I can't flash anything to internal. Any ideas?
[Nook HD, HD+ Android Development] belfastraven:
Check on the setting of

Set USB configuration

In the networking section of developer options
[Nook HD, HD+ Android Development] KyJelly69:
I am definitely having this as well. Any chance you have a guide for the most efficient method to do this?
[Nook HD, HD+ Android Development] neutronjeff:
Do you mean the old bootable SD with CWM, or a new version?
[Nook HD, HD+ Android Development] LBurdick43:
I used the SD recovery from this post: http://xdaforums.com/showthread.php?t=2583952

It's an old TWRP version.

---------- Post added at 02:10 AM ---------- Previous post was at 01:29 AM ----------

It seems I can mount /eMMC now, but I still can't mount /bootdata, which still means no flashing things. I'm not sure how this happened, Marshmallow was running smoothly. Is there something I can do from ADB to fix this?
[Nook HD, HD+ Android Development] jck_w:
It seems the latest Jan 17th build still has the same rotation problem: no auto landscape on the main screen.
[Nook HD, HD+ Android Development] ieatabiscuit:
I had to get a full stick flashable .zip (check leapinlar's signature that), made a bootable SD card, put amaces tarp, AND the stock image on the bootable card. Flash stock, remove card, reboot, force shutdown and reboot into stock recovery, pick only option available (factory reset) wait for a while as it is the slowness. Once it's all over, reboot to the SD card again, now flash tarp. Remove card and reboot into twrp, flash room of preference, ???, profit. Sadly, there is no way to do this with our it being tedious, but I have the flashing of the ROMs almost down to an art form with all the tinkering I do. Next project is to create a heat spreader for my ovation, I notice that gsam shows that expected voltage drop when the processor gives extra heart to the battery. Another nail in the wonky battery behavior coffin.
[Nook HD, HD+ Android Development] martynas888:
Use another launcher. Nova works. Rotation in other apps is working too.

Also WiFi is not connecting to network after boot. Turning off-on doesn't connect too. But once I open wifi settings it is connecting.
[Nook HD, HD+ Android Development] Shadowpain:
Yeah , that happens to me too.
[Nook HD, HD+ Android Development] belfastraven:
I suugest that you follow [MENTION=4473900]amaces[/MENTION] instructions from here:

http://xdaforums.com/nook-hd/development/unofficial-cm12-1-nook-hd-hd-2015-04-08-t3078260 He includes the ADB commands you might need.

According to the link in your post, theSD recovery you are using seems to be CWM, by the way.
[Nook HD, HD+ Android Development] dbrickg:
In the Nexus 7 forum, there was a suggestion for fixing the rotation problem in Trebuchet: "Press long in homescreen and swipe up to open menu. Then select settings and somewhere there is allow rotate option":

http://xdaforums.com/showpost.php?p=64859657&postcount=157

---------- Post added at 08:17 AM ---------- Previous post was at 07:31 AM ----------

Well, crap... it was working fine, but this morning I flashed the 20160117 zip, and it looked good. But when I'd press the power button to wake it up from sleep, nothing would happen. Had to long press power button to force it to turn off, and then press it again to boot. And the backup of the 20160110 nightly on my sdcard has disappeared... at least twrp couldn't find it. So, I'm making a backup of the current, problematic system, and will try clean flashing the 20160117 nightly.....
[Nook HD, HD+ Android Development] Shadowpain:
That might be a launcher issue cause it happened to me twice in stock launcher but never in nova
[Nook HD, HD+ Android Development] dbrickg:
I'm guessing you mean the rotation issue? And, yeah, I don't have it, either. I use nova, too. But I saw that post in the nexus 7 thread and thought I'd mention it here for anybody's who's using Trebuchet

---------- Post added at 09:09 AM ---------- Previous post was at 09:02 AM ----------

So, rather than go all the way back to a clean flash, I tried simply backing up what I had, and then reflashing the 20160117 nightly. So far it looks good. The only difference in my flashing procedure was to also flash opengapps on top of the nightly (which I was told not to do on my nexus 6). And, curiously, once I got back into the phone, both ROM Manager and Root Explorer could see the backups I'd made. They were invisible to TWRP (the new 2.8.7.5 one that was posted here).

Ooops... looks like I spoke too soon. Power button isn't waking the tablet now :( I'll see if I can somehow I can get TWRP to see the old backups I made and try restoring them
[Nook HD, HD+ Android Development] bruce7890:
I've got a copy of 20160110.zip if you need it?
[Nook HD, HD+ Android Development] dbrickg:
Thanks. That might be helpful. But what I meant was I lost the nandroid backup of the whole system. They're still there, but for some reason TWRP doesn't see them in the Restore section. And TWRP's built-in file manager doesn't launch. As soon as I get home and have my HD+ usb cable, I'll try copying the backups to my computer and see if I can put them someplace where TWRP will see them.
[Nook HD, HD+ Android Development] amaces:
So, dirty flashing over CM12 was probably not a good idea. It's surprising that it worked, and although convenient, you're bound to run into weird issues. Otherwise, previous builds are kept in the obsolete folder for a while, so generally you only need to backup /data in TWRP (to save space, and time).
[Nook HD, HD+ Android Development] dbrickg:
Yeah, I imagine I'll end up doing a clean flash soon. I was just curious to see if I can figure out what's going on with the current situation.

Also, it just occurred to me that when I originally flashed the 01/10 zip, the os came up and said there was some problem with my sdcard, and asked if i wanted to fix it, and when I, eventually, gave in and said yes, it asked if I wanted to make it usable in other devices or make it so it could only be used in the nook. I'm wondering it that has something to do with TWRP's inability to see the backup.... Except it *can* see the latest backup. It just can't see the two earlier backups whose names I changed.
[Nook HD, HD+ Android Development] asakurato:
Can't change it, reverts back to charging no matter what.

Edit: Something strange here, if I select anything there, it reverts to charging, but if I go to main menu, it shows whatever I have selected, but everytime I connected, charging was there (I only connect to transfer new builds).
[Nook HD, HD+ Android Development] dbrickg:
Yes, I think they changed it in cm13. I can't get the USB mount option to stick on any of the 3 devices I'm running cm13 on. I think it's supposed to be a security thing. It may even have changed in the upstream, android 6.0 stuff. I'm not sure about that. Anyway, you just have to open the USB dropdown and change from charging only, to file transfer every time you plug in your usb cable :(
[Nook HD, HD+ Android Development] amaces:
Whether you selected portable (normal/legacy) or adopted storage, it sounds like you formatted the card, and lost whatever was there… If you made another TWRP backup afterwards, then all makes sense.