[Xposed Framework Modules] Roughy:
Exi for Swiftkey 1.6.0 release

1.6.0 [ 21.07.2018 ] - Compatibility, hide predictions, bug fixes ( Stable: ?, Beta: 7.1.2.20 )

THIS UPDATE TARGETS SWIFTKEY BETA 7.1.2.20

MODULE IS NOT COMPATIBLE WITH OLDER VERSIONS SUCH AS CURRENT SWIFTKEY STABLE

Changes in 1.6.0 ( Stable: ?, Beta: 7.1.2.20 ):

Fixed

- Compatibility targeting 7.1.2.20 ( breaks backwards compatibility )

- Recent emoji being cleared at random

- No punctuation auto-space sometimes not being applied until toggled again

Added

- Option to hide predictions bar

- Option to display shortcut to Exi config app in toolbar

The Xposed Installer app does not appear to be refreshing properly and may not list the latest version.

Please download it directly from the Xposed Repository below using a browser.

Download:

Exi for Swiftkey on Xposed module repository

Notes:

Translations

I... I forgot to merge the translations.

Uhh... hotfix once any other issues have had a chance to surface I guess?

Sorry, translators.

Compatibility [MENTION=7774486]pratyush28[/MENTION]

tl;dr Update only supports beta branch for now, stable should catch up with the next update.

Swiftkey made some major changes. A lot of there were normal code changes that ruin my day, be worst is a new obfuscated step.

In Java, classes exists in packages. So you'll have com.touchtype.keyboard.candidates.view.ViewCandidate for instance. Obfuscated, this is reduced to com.touchtype.keyboard.a.b.c, with the single-letter portions being random. The contents are renamed like this too meaning it is very difficult to figure out what does what, but being in the same package probably means they are somewhat related.

Since the names change all the time we use ClassHunter to generate profiles we can use to recognize them. This process is helped greatly by the fact that we can limit ourself to classes in in certain packages ( com.touchtype.keyboard.*.*.* in the case of the above example ) instead of comparing to every single class. This also helps when generating the profiles, as we can specify that the class must contain a reference to a class in a specific package, even though we don't know exactly what class that is.

In the latest update Swiftkey added another obfuscation step: repackageClass.

RepackageClass basically places all of these classes in the same package, so instead of com.touchtype.keyboard.a.b.c we have get abc.

That means we have to scan of a lot more classes, and the comparisons have a lot more wildcards.

Our current approach to generating profiles is still good enough to match them, but they will not be quite as resilient to change. Next Swiftkey upday will tell us how well that'll go.

The greater problem is performance; 6000 obfuscated classes is nothing to scoff at.

While the results are cached after the first run, the initial run still took 144 seconds on my device.

Luckily ClassHunter had always been "fast enough", meaning I never attempted to optimize it at all.

With a few modifications we've got that down to only 16 seconds, which is actually twice as fast as before.

Behind the scenes there have been many, many changes. About half of all the hooks had to be redone from scratch, meaning there may be new quirks I have yet to discover. Don't be super duper surprised if weird things happen.

Recent emoji being cleared at random [MENTION=4303016]rolear8[/MENTION]

So I'm still not sure how this happens, but the prime candidate is the recent emoji not being loaded correctly for some reason, followed by the saving mechanism firing as usual, resulting in it saving... a blank state.

This has been modified to immediately add the clicked emoji to the database, instead of keeping it in morning and saving it later. This should resolve this issue.

No punctuation auto-space sometimes not being applied until toggled again [MENTION=1296044]Kucher[/MENTION]

Everytime you open the keyboard we communicate with the Exi config app and check if any settings have been modified. This usually only takes a few milliseconds, but 30ms or so is not unheard of.

It's not much, but an extra 30ms when waiting for the keyboard to open feels like an eternity, so instead we perform this task on a separate thread (in parallel ), and enact any changes afterwards.

No punctuation auto-space relies on a piece of code having been executed before it can be effected. This happens the first time you open the keyboard, but sometimes we finish loading the settings before this happens. We load the settings, attempted to effect the change and... code we rely on hasn't run yet and we do nothing. My error was assuming that it was successful, resulting in nothing happening until you turn it off and on again. Fixed.

Hide predictions bar [MENTION=9353038]larov123[/MENTION] [MENTION=5152761]AlMaghraby[/MENTION]

Apparently this is something a lot of people are into. Removing it is simple, you can toggle it under settings somewhere (disabled by default).

The problem is the toolbar, or more accurate the button to open the toolbar, which normally looks like this:

It needs to go somewhere. The solution is to leave a bit of space for it to reside in. It's super duper difficult to hit, but presumably you're either going to leave it open or leave it closed.

If the open-toolbar plus icon is visible when you toggle this setting, you will probably have to click it once or twice for it to pop into place.

Note that Swiftkey will still automatically insert predictions if you have auto-correct enabled; all we do is hide the bar. Maybe go disable auto-correct in Swiftkey's settings.

Option to display shortcut to Exi config app in toolbar [MENTION=5044560]oroboros74[/MENTION]

See above, it's on the right side there in the toolbar. Enabled somewhere in the settings.