The keylayout is a confusing mix indeed. Although the best way around it is by using Tincore. L2 and R2 are recognized as analog inputs, but can be used as buttons in games that require them. So far, for the games I play, I haven't had an issue. Certain games have an analog that moves with the finger, so it's hard to emulate when adding the physical buttons, such as the game NOT ALONE.
I think in certain apps, such as the Snail Launcher, the buttons play a larger role in navigation. The biggest issue is that the Analogs and the face buttons are on a different driver, so when games detect one, they don't detect the other, such as with Implosion, or Eliot Quest.
Soul Calibur also had that issue, but I was able to fix it using Tincore by changing the names of the buttons. Like Nielo and I were speaking about before, Null Driver may be the best way, since the confusion with the way certain apps react to the presence of buttons can get confusing. One would have to map the buttons only once, then when the game opens, their mapping is intact. While I've had success with most games I've played, there are a few standouts in which the touch screen controls are so fully implemented, that not using the touch screen is impossible.
I've still been too busy to test out anything. I still have to download a few items honestly, so please keep them hosted. My plan is to first change the build prop to obtain 6.1.2. Then root and apply the SD Card bypass, then Carliv Touch to install G- Apps. From there I can play around and see if anything else may have changed in 6.1.2.
Since you've been using it, is battery life any better?
Regarding battery power... Not really... It appears the phone naturally draws a lot of power especially when gaming (just some of my games for a total of 10-20 minutes can consume up to 50%), though I, from the very beginning, do suspect the battery's percentage meter is somehow bugged as under some occasions the phone can still run for 20-30 minutes under load after it dropped to 1%. The phone's battery might be unstable in terms of voltage, I presume, as I noticed the higher the battery's percentage is, the faster it charges (that is, it takes far less time from 50% to 100% than from 1% to 50%), and the percentage readings also bear a +/-10% difference between reboots.
Leaving wi-fi on, or leaving a few large games background (which has been possible since 78P01 thanks to its 2GB RAM) can significantly increase battery consumption during standby (especially when leaving wi-fi on I notice the battery drops almost twice as fast). Still, I'm yet to know a good way to get a reading of the battery's actual capacity and wear level...
I usually had those "bloatware" (Snail Launcher and MUCH MIAN Store) disabled or removed since I don't really use them, so I'm not sure how much battery those things would consume.
From the look of the jadx-decompiled source code of KeyAdapter, it appears to be using some kind of hardcoded key values to map touches and analog sticks, which maps them accurately and won't be interfered by changes in the keylayout file, or other buttons containing the same events. I can still map and use the MOON button just fine even after I remapped it to use Xperia Play's BACK+ALT in the keylayout file, from the original BUTTON_B.
A notable example would be the analog sticks. Back in i5 the analog sticks appear to perform the same actions as mapped arrow buttons (which is an intended behavior as they both produce DPAD arrow key events) when not mapped, but since 78P01 (including W3D) this is no longer the case, implying a possibility that they used to map key events to touches then later on switched to directly mapping hardcoded key values of the given device.
The hardcoded values differ from those in the mtk-kpd.kl and I can only presume there has been some kind of "translation" taking place in the background. Also, while the KeyAdapter does not have any timing issues, it seems to introduce a good amount of CPU overhead that caused some problematic lags in certain games when a lot of key-to-touch conversions take place. However, the device's CPU or I/O configurations might be to blame as I never had any lags with 78P01, just it would occasionally fail to register a few touches.
By the way, had anyone tested the system performance without Xposed, or with Xposed but without removing the jex files from the framework (does the system work stable despite Xposed's warnings when the jex files are present)? In some games, when the game becomes sluggish, I also find it as sluggish to open the notification drawers or do anything else. I don't have a solid proof that Xposed or GravityBox might have something to do with this as I used them from the very beginning so as to migrate the tweaks that I used on 78P01 to the new device (excluding the incompatible ones).
Hello! Thinking about picking one of these up. Is there anything that I need to know or fix before I get one?
Depends really. There are some ups and downs to this device. To me, it's all I have so I deal with it, but some things may be hard to swallow. The device has some strong points on both areas, so it mostly depends on what you are looking to do.
To straightway answer your question, if you want Google Play, you may have to install the International firmware, which isn't hard, but is the first thing that will need fixing.
The second, is to brush up on the use of Tincore Mapper since it is much more versatile than the standard mapper, and some games, (SOUL CALIBUR), will require it to fully map out.
Third, currently there is no way to Move apps to SD (easily at least), and since some apps from the play store default to SD, you may receive an error. I've bypassed this by going to settings to unmount the sd card, redo the install, then remount. According to LSS932, that isn't a full proof way since updating may be an issue. While I haven't experienced an issue with the method, he knows light years more about it than I do, so if I do have an issue, at least would be able to safely put that workaround to rest.
I'll be glad to help if you have anymore questions. The device is my daily driver, so I use it as a phone, and a gaming device.
Updating an app that defaults to SD card will move it back to native App2SD (asec) regardless of where it used to be (including Link2SD), as the system determines the new install location only from what the app manifest reads, and is not aware of the existing app's location. This is a default system behavior. Since W3D couldn't create asec containers correctly, you won't be able to update such apps through normal means without the fix I've proposed, which overrides a flag so it'll always be explicitly installed to the internal storage.
Also, I'm having this weird issue of the Play Store not actively installing the app after the download has finished (100%), and have to force close the Play Store (by swiping it off the recent apps) and restart in order to get it installed. There were some threads about such problems online, but I haven't found a solid answer for it. Still, this is only a minor annoyance and not a very big deal.
EDIT: It should be noticed that while I used to get prompted whether to forbid an app from auto-starting so I can choose whenever an app gets installed or updated while I was still on 6.1.1 International, in 6.1.2 (and probably all Chinese versions), I'm no longer prompted and the newly installed or updated apps are automatically set forbidden from auto-starting (probably regardless of my previous settings). I dunno where I can change this behavior.