You can always flash back to stock (unlocked bootloader is irrelevant) and start over from a clean start. That'd be a bit more thorough than a factory reset. Then just use superboot to root again (your bootloader will still be unlocked), or if you have a custom recovery installed you can root by flashing a zip of e.g. SuperSU.
EDIT: Here's a guide to flashing back to stock: http://forum.xda-developers.com/showthread.php?t=2542219
Obviously you do this at your own risk, but it should be fairly safe. Worst case scenario, just boot into bootloader and flash again.
As far as I can see, those are the same links as in my post. I'm fairly sure I made sure to find the original source websites for each tool for the links, but I could be wrong (maybe an admin edited them in or something...)
Anyway, I apologise for letting this thread kinda die, I didn't get a Hudl in the end and therefore lost interest.
I installed this on my Asus Memo Pad HD 7 in the hopes of bypassing the BBC iPlayer device checks to allow me to download videos, but after enabling the module and enabling the iPlayer option within the app, I still couldn't download videos. Is that tweak broken or did I do something wrong? Do I need to reboot it anything after enabling that tweak with the MoDaCo Toolkit? I did force close iPlayer and restart it.
On a side note, if a similar tweak could be made for flixster, I would appreciate it...
Handbrake can't (by itself) handle encrypted DVDs. I have seen guides which claim placing a particular DLL file (libdvdcss.dll I think it's called) in some folder within Handbrake's installation will make it capable of decrypting DVDs, but I was never successful in attempting that (I believe there may have been an issue with 32bit/64bit, I tried a bunch of different versions of the DLL I found online and could never make it work though). You can also use tools like the ones I mentioned above (e.g. DVD43, DVDFab Passkey etc.), albeit with the same caveats I mentioned above (DVD43 32-bit only, DVDFab Passkey not working properly for me).
As a side note, I should probably say I never tried particularly hard with either DVDFab or libdvdcss.dll, seeing as I was happy enough with my existing solutions (MakeMKV, DVD Decrypter or DVD Shrink to rip [used each for a period of time, MakeMKV is my current go-to tool], Freemake to convert) so didn't bother "wasting" loads of time trying to get something else working.
Note that Freemake cannot by itself rip commercial DVDs. Personally, I generally use MakeMKV to rip DVDs, and then convert the resultant MKV files with Freemake if I want to get better file sizes etc. Often I leave them as MKVs to save time.
There are solutions out there for decrypting commercial DVDs "on-the-fly" so that Freemake can rip them directly, but the only one I have ever gotten to work reliably was DVD43, which is discontinued and only works on 32-bit systems (I have 64-bit Windows 7). I tried an alternative called DVDFab Passkey (Lite), but it never seemed to work properly when I tried it. I decided to just rip using MakeMKV instead.
"complete root" simply means su binary in /system/bin and a superuser access management app installed (i.e. Superuser (ChainsDD's version [closed source]), Superuser (Koush's version [open source] or SuperSU (Chainfire's version [closed source])). AFAIK, both methods install SuperSU (seems to be most popular these days, although Koush's Superuser is the one included in many source built custom ROMs e.g. CyanogenMod).
Now, as to "ro.secure=1"; this property only affects adbd, the ADB daemon that runs within Android. In other words, this property affects the permissions of ADB. If it is enabled (i.e. =1), adbd runs in "secure" mode, and any commands sent over ADB are run as a "user". If it is disabled (i.e. =0), adbd runs in "insecure" mode and commands sent over ADB are run as "root". This means you can pull system files, push files to protected locations (e.g. /system) etc.
So if you find some way to make it =0 before you've rooted, you can then use ADB to push your su binary to /system/bin and then you're rooted. However, once you're already rooted, there is little benefit to making adbd insecure unless you have an actual use for doing so. It should be 100% unnecessary for all applications (which can identify as root via the su binary), so unless you need to issue root commands over ADB, you should be fine as is.
In summary, don't worry about those properties, they are fine as they are for using root-enabled apps.
Custom kernel should be easier than custom ROM, seeing as full kernel sources are available. Should (theoretically) be very straight forward to build it once you have the build environment set up, and then once you've got it building, adding new features (e.g. new governors, modules etc.) is rather simple, I believe. For reference here's how to compile a kernel from source and here's how to add features to a kernel. Beyond this, I believe it is typically a case of finding the github for another kernel which implements a feature you want, figuring out which revision of the source added that feature, and making the same changes to your own source tree.
By contrast, building a custom ROM for a device with no available AOSP device tree (i.e. a device which hasn't had a source built custom ROM before, such as the Hudl) is considerably more complicated. The link posted above to the CM wiki seems to be the best resource I have come across for porting an AOSP ROM to such a device (XDA University only seems to cover porting different AOSP ROMs to devices which already have a device tree from another AOSP ROM e.g. porting ParanoidAndroid to a device which already has CyanogenMod). You need to pull various files from the device, edit a bunch of files in the AOSP source etc.
As the wiki says, it is advisable to try building a ROM or two for another device first if possible to familiarise yourself with the process etc., before attempting to build for a brand new device.
The are multiple GUIs out there for apktool, I'm not going to include them all or try them all and select the best. The only way I can be sure of having every feature of apktool is use the standard, command line version. Command line tools should not be an issue to the people who are doing this sort of thing, most of the other tools featured in this thread are command line tools. Thank you for your suggestion, but it shall not be included in my post.
Updated first post with rkflashtool (64-bit version from Paul's rooting thread, mirrored without the system.img [11KB download vs 485MB], 32-bit version linked to glossywhite's thread; both untested by me personally) and also apktool, which can come in handy when messing with Android things.
Root is not required in any way to install APKs. Only reason I can see for root is to access the USB drive, and that is kinda silly when you could just download it directly from the browser on the Hudl and install, instead of downloading on PC and transferring in that convoluted manner. You could even just connect the Hudl via USB cable and transfer the APK to it's internal storage, without any need for root.
If getting BBM onto your Hudl was the sole purpose of you rooting it, it was a wasted effort, I am afraid. There are countless methods of getting an APK onto your device without using root. ;)
Screen powering on when the charger is plugged in or unplugged is the default behaviour in Android. I'm not sure that you can actually change this, although I think I've seen an Xposed module capable of doing it. Not sure which one though.
Sounds like an issue with the custom recovery contained in the ROM. If charging while powered off is very important to you, my advice would be re-flash the stock recovery IMG until there is an updated recovery with fixed charging while powered off.
Nice :D Theoretically nothing to stop devs getting their hands dirty now. I'll just leave a little link here: http://xda-university.com/as-a-developer - has some guides about compiling kernels, adding features, porting ROMs etc. Get stuck in ;)
The only way I think this is possible is if someone installs the update, then dumps their system partition (should be possible via rkflashtool) post-update. They will then have an updated system.img. Assuming they've already got root and any other mods deemed useful for a custom ROM, they could then package this up into a ROM IMG and distribute.
[As I have said before, I'm not fond of stock-based custom ROMs, I find anything short of source-built custom ROMs pointless. However, some people obviously do see merit in them, hence I am posting this information to assist someone if they wish to do it]