Таким образом, поскольку в моем вопросе не было активности для моего вопроса, я приложил дополнительные усилия, чтобы выяснить это, я разложил проект Чака над обновлением всего до Androidx и обновил целевой и скомпилировал SDK до 28, а ТАДА ПОСЛЕДНЕЕ ПРОИЗОШЛО.(казалось, что это происходит при использовании Loaders?), поэтому, даже несмотря на то, что в результате аварии это выглядело как ошибка в jtifier, вполне очевидно, что это не ошибка в jtifier, потому что теперь новый Chuck aar полностью базировался на AndroidX (позже я пошел чуть дальшеи даже обновил язык, используемый библиотекой, с Java на Kotlin), поэтому я предположил, что виновником были библиотеки androidx, я посмотрел на мой appcompat libray, потому что сбой говорил о том, что действие Chuck не реализовывало LifeCycleOwner, что было неправильно, потому что AppCompatActivity былаLifeCycleOwner, поэтому я был на версии "androidx.appcompat: appcompat: 1.0.2" и изменил его на "androidx.appcompat: appcompat: 1.1.0-alpha02" и больше не вылетает !!(Даже в оригинальной библиотеке, которая должна быть уничтожена)
Так что же случилось?Я думаю, что некоторые зависимости, которые я мог бы включить, должны были использовать вариант 1.1.0.variant или что-то еще с ошибочной реализацией, и более новая библиотека должна была иметь приоритет над моей 1.0.2, поэтому другое решение должно быть принудительнымиспользование 1.0.2 для androidx.appcompat что-то вроде
configurations.all {
resolutionStrategy {
force 'androidx.appcompat:appcompat:1.0.2'
}
}
Я не проверял выше, но теоретически это должно работать, если вы хотите придерживаться стабильной версии, в противном случае вы можете просто перейти на альфавариант, который я упомянул выше, и он обязательно должен работать.