[G2 Android Development] MidnightHarvester:
You can't get back into recovery after seeing the "security error"? You should be able to just hold the power down log enough to turn the phone off, then press volume down and power button to power up and release, then press both again once the LG logo appears as you'd normally do to get into recovery.

I've gotten many security errors while rebooting after making custom modifications that I screwed up on quite a bit (example,...I usually deodex LGSystemUI.apk for modification purposes but occassinally the system decides to throw a security error at me) and I've always been able to boot back into recovery and use TWRP's file manager to fix whatever I messed up (or the terminal). I rarely make any full system backups up due to the huge size and because I know which files I'm modding when making a change so I just backup those affected files.

Also keep a copy of the original ROM so I can pull anything else I might need from the archive to fix the issue, but I'm just pointing this out to those who are comfortable going with backups as they do eat up a lot of space (or can).

Next issue. ART. I'm also going to talk about a subject developers hate, benchmarks. I'm a developer myself and don't rely on benchmarks in choosing a kernel or ROM.. BUT they are helpful for when say, making kernel modifications. You can run compare your own system before and after and get an impression of whether or not performance increased, decreased, or not at all. They are useless when comparing against other devices (even same model devices) or even other ROMs though.

Most benchmark applications rely on the NDK so are optimized for systems running dalvik runtimes. 3DMark for example - if run Icestorm using the ART runtime then you're going on end up seeing results either in par with or less than you'd see with DALVIK.

Other benchmark apps such as Linpack that don't rely heavily on the NDK should be seeing dramatic increases over DALVIK. Yet..

My setup with CloudG3 1.3 and dorimanx kernel in DALVIK set to a performance setting is hitting 900s-1000s in Linpack multi-threaded. With the ART runtime enabled the first test i ran under the identical kernel profile gave me a adore of 13...Yes 13. But that was right at boot. After settling in the scores became stable and settled at 330s-460s. Don't use these numbers to compare against your device because it won't do any good ... Again always compare scores according to your own device before and after changes.

This is not a significant increase at all in fact it's a significant decrease and you can say "it depends only on how your device feels..is it snappy?" The answer is no. If my device hit 1000s under DALVIK then it should be seeing significant gains. The device can feel as snappy as it wants but something isn't right here.

I've seen the question asked several times and even searched through the thread a little but didn't are a definitive answer, so from these findings the ART runtime appears to be the bugged initial or early release.

Can somebody else who wishes to help out download Linpack and first in DALVIK runtime get an average score under the multi-threaded test, then switch to ART and do the same. After switching to ART it'll take few minutes (maybe less) for things to stabilize. Once it does, do the same and get an average score again using the same settings as you used in DALVIK.

The actual score doesn't matter. If you only get 600-700 in DALVIK it doesn't matter. What matters is the difference between the two averages. We aren't trying to judge the ROMs performance but instead get an impression on ART.

We could also use the CPU test in Quadrant as well, and if the average ART score is less than the average DALVIK

score then something is afoot. Tests have indicated that NDK bases apps won't see much if any performance gains which makes perfect sense from a dev's point of view, but these other apps should be seeing an increase.

I'll keep playing around but having another set of numbers would help in determining something faulty with my device or a faulty ART in general on the ROM. Still though ART has seemed smooth fast so I haven't seen a reason not to use it yet, but am more interested as to why non NDK benchmarks aren't benching higher with ART.

Many Thanks! Hey, the new Doctor Who comes on in about 40 minutes!