[Xposed Framework Modules] Roughy:
[MENTION=6953284]bkkzak[/MENTION]

I got your PM with the logs, thanks.

The last report I had didn't include the full log, only the native dump. Your log raises more questions.

// Hook entry
I/EdXposed-Bridge(6719): Exi/LoadPackageHook, Module loaded in com.touchtype.swiftkey
I/Exi/LoadPackageHook(6719): Module loaded in com.touchtype.swiftkey, CRC: b907334, Module version: 2.0.4

// Happily hooking stuff
I/Exi/Hooks(6719): Elapsed for keyboard priority: 1.748 seconds
I/Exi/Hooks(6719): Elapsed for emoji priorty: 0.687 seconds

// VM runs garbage collection and **** hits the fan
F/libc (6719): Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x12dc12e8 in tid 6740 (HeapTaskDaemon), pid 6719 (re-initialized>)
F/libc (6719): Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x12dc12e8 in tid 6740 (HeapTaskDaemon), pid 6719 (re-initialized>)
F/libc (6719): Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x12dc12e8 in tid 6740 (HeapTaskDaemon), pid 6719 (re-initialized>)

// Process continues doing its thing
I/Exi/Hooks(6719): Elapsed for hardware priority: 0.368 seconds

// Process dump cut for brevity
I//system/bin/tombstoned(943): received crash request for pid 6740
I/crash_dump32(7006): performing dump of process 6719 (target tid = 6740)

// Process keeps on running like nothing happened
I/Exi/Hooks(6719): Elapsed for prediction priorty: 0.523 seconds
I/Exi/Hooks(6719): Beginning secondary setup
I/Exi/Hooks(6719): Elapsed for Basehooks: 0.804 seconds
I/Exi/Hooks(6719): Elapsed for Hardware keys: 0.007 seconds
I/Exi/Hooks(6719): Elapsed for Stylehooks: 0.068 seconds
I/Exi/Hooks(6719): Elapsed for Prevent period: 0.001 seconds
I/Exi/Hooks(6719): Elapsed for Sounds: 0.054 seconds
I/Exi/Hooks(6719): Elapsed for Emoji: 0.0 seconds
I/Exi/Hooks(6719): Elapsed for Keys: 0.271 seconds
I/Exi/Hooks(6719): Elapsed for Predictions: 0.146 seconds

// Process is finally killed
I/ActivityManager(1040): Killing 6719:com.touchtype.swiftkey/u0a402 (adj 0): crash

As expected, it is the same problem. We're doing stuff, VM runs a GC, something goes horribly wrong and it terminates the process after a bit.

The reason it only happens sometimes, is because GC is not a deterministic thing; when it happens is relatively random.

We also don't know exactly what object is it garbage-collecting, or why that is causing problems. Since everything is fine ( as far as we've observed ) as long as it makes it through the hooking process, it is possible we'll be fine if we can prevent it from doing a GC in the middle of the hooking process.

We cannot prevent it from happening, and we cannot cause it to run, but we can request one and hope the VM takes the opportunity to do so.

So, if we request a GC before getting started on the main hooks, and sleep for a few seconds to let it hopefully actually do it, we... might be okay?

That's assuming the problem is objects related to hooking, and not some of the other ... normal ones. Not that the rest should be any problem anyway.

That's a big maybe, this is isn't really a problem an xposed module should have to deal with, or have any hope of fixing.

2.0.5-NO-GC download: https://www.mayulive.com/swiftkeyexi/swiftkeyexi-2.0.5-NO-GC.apk

It will add a permanent 5-sec delay to the initialization. I don't think that'll be enough to trigger APN for the keyboard service, but you might want to enable "Show background ANRs" under developer settings, as otherwise android will just silently murder it.

As the name implies, resource hooks replace ... resources.

Xposed provides an abstraction for doing this easily, but there's nothing stopping you from hooking the framework methods responsible for looking up these resources and inserting your own.

For most resources you can simply hook the various methods of android.content.res.Resources ( getString() etc ) and return whatever you want for any given ID.

For fancy things like layouts and stuff things would get a bit more complicated, but the general idea still applies.

This is in general though; there are bound to be a lot of exceptions depending on how the resource is used.

I sorta do this in this hook because the emoji panel I insert uses AppCompat resources, but those are not present in Swiftkey, so I just hook the resource lookup and pipe the lookup to my module's resources instead.

All the layout manipulation I do is implemented by hooking something that returns the inflated viewgroup and making changes to that, instead of the layout xml.