[G2 Q&A, Help & Troubleshooting] MidnightHarvester:
YouTube is just slow no matter what device I've ever used (slow in loading that is). Older versions were much better. Even with

ART enabled, it takes it's sweet time while opening which leads me to believe that it relies on the NDK pretty heavily, otherwise startup time would be drastically improved over DALVIK.

Using the highly scientific method of counting "one thousand one, one thousand two, etc", after initially clicking the icon to launch it I can get to "one thousand two (sometimes one thoudand and a half) before I even see the app pop up. It then takes another "one thousand two" before the loading animation stop while it finishes downloading everything and displays the interface. Now my "one thousand one" counts may be faster than an actual second by a little bit but you get the idea.

Also running the kernel near stock levels but geared SLIGHTLY towards performance. Even when I'm overclocked to 2.57GHz running performance mode with performance governor with sampling down to 25000 sampling rate with all cores fired up and running it takes the edqxt same amount of time as if I open it while underclocked by the same degree.

Heavily NDK reliant.

---------- Post added at 09:19 PM ---------- Previous post was at 08:20 PM ----------

When using Xposed it's best to install one module at a time (unless you've already tested and trust a certain module... such as the YouTube ad blocker module which never have me issues) and run the system through it's paces for a while. Especially in the areas that the said module is is geared to modify and any apps or services that also rely on the modified portion of code

I've encountered odd errors in the past from when I first loaded Xposed a long time ago and begin loading up on as many "compatible" modules as I could while testing stability. I've since then given up on using Xposed as the developer is intent on not releasing the version that is supppsedly ART compatible until ART is stable. I understood that a while back and agreed but Google has basically given all app developers as much of a warning as they can when they made the commits removing the libdvm libraries from AOSP.

Now in theory no cose should have to be modified to be compatible with ART. This is the real world though and not a forgiving world especially when we make mistakes, much as ART is. DALVIK runtime is much like a relaxed atmosphere 8th grade classroom where intelligent students can learn, and be forgiven for not knowing about Quantum Entanglement. ART runtime is like throwing these gifted 8th freshmen into a top notch College or University.

These kids are gifted so many will handle things just fine. There's gonna be a few children though unable to cope who were only in the gifted programs to begin with by slipping through cracks in the system, cheating off of others, hacking around the school system. They aren't going to be able to keep up.

Many Android apps take advantage of DALVIK runtime hacks, etc in order to accomplish certain things. These apps ARE going to have to be rewritten and these devs need to stop complaining when their customers now begin to wonder when the apps will become compatible. Out of all 231 apps I had installed, only Xposed would not work with ART.

If there is a version that works I wish it'd be release already but not for me as I could care less as I can manually mod X or Y if I need to but for the plethora of XDA members who don't wish to or can't do the modifications themselves. Well, I do understand the hesitation actually, because Xposed relies solely on third party modules which may or may bir cause boot loops or break things in ART. He's not profiting off of Xposed. Instead others are by hooking into the Zygote procedure that begins every app and also hooking into wallets with modules advertised here on an open source community where functionality is crippled unless IAPs are made. Don't ask for donations as well as IAPs to unlock stuff.. Doesn't look good.

But before I get too far off topic, as I was saying, a class called XposedBridge is used by module writers. After initializing an instance of the class, they can then call on hookMethodNative which can hook into other app methods and then everytime the targeted app's is ran, this generic method is also called which is where we as the module writers can inject whatever code we please in without the targeted app even knowing. It's an extremely creative and powerful way to modify apks.

When executed correctly, it modifying apps this way can be extremely effifcient (depending on that overhead of the injected code that is), and also remember these modules are running basically in the Zygote process (think of the Zygote as the Mother application of them all...the one that pumps out baby apks when needed. There's a lot that can go wrong if perhaps an unexpected exception occurs that isn't handled (force close) which isn't uncommon, especially if using experimental or beta versions. I can think of much worse things to happen but this post is long enough.

This post is mostly for helping understand how an Xposed module basically works, and to point out that having Xposed installed is as likely to cause any errors as having "su" installed, as Xposed only installs the installer apk and basically also a jar file in it's /data/data path...none. It's just like 'su' in a sense it's what you with it after it's installed (in the form of modules) that do any actual work and that do the harm.

As far as the issue is concerned, since you've disabled the module and the issue occurs on reboot without it installed seems like an InCallUI error or something on those lines. Since there are quite a few areas where telephony issues could arise, it'd be best to go into recovery and wipe system + data (backing up any apps you need with Titanium but not backing up and restoring anything in red there) and see if the issue continues. If it does the next course of acrion would be to download a logcat app (Catlog is good) and in settings makes sure that only errors or worse are shown (and make sure logging is enabled if disabled by your kernel), then recreate the error and then immediately use the recents menu to switch to your logcat app and hit the pause button asap. This helps you to only gather logcat entries that are relevant so you don't end up posting a logcat thats 1000s of entries long.

Then you could attempt to solve the issue from there if you know how, if not then posting the logcat here would help. You could even do this before doing a full wipe as it could be fixed without wiling your entire system. Finally if nobody here can hell with it, PM Cloudy with a formal bug report (only do this though if you take your logcat after doing a full wipe, submitting bug reports without wiping system and data prior to installation is usually bad form) including your device variant, kernel used, steps to recreate the error along with the logcat.

This basically applies to any weird problem that can't be solved by first using the search button to only search within the thread for possible fixes to said problem....

Wish I could help more :(