Well, that's the thing : Kotlin emits bytecode. It is entirely interoperable with Java. All the Java APIs of the platform are accessible in Kotlin.
Swift on the other end can only target the NDK, which limits it to a very specific niche on Android.
What helps a lot is that the kotlin team has written many helper methods allowing a better flow between the android API and kotlin code : while you don't need it in order to get interop, it allows to more easily write idiomatic kotlin code while interacting with Android.
Can't a native library call just anything from the Android/Java world?
I mean, NDK library has JNIEnv* pointer and it can call FindClass/GetMethodID/Call*Method. And it can create objects/functions if it needs to be called back. Of course this isn't fun in the raw form, but don't see any reason it can't be well sugared.
That said, there is always a cost to using a non-standard language to develop for a platform. Things like having to translate documentation as you read it, friction between system libraries and your languages standard library, etc.
I've not looked at Kotlin in detail, but I wonder how much that friction is reduced because it's java-based, or if you'll experience just as much friction using Swift on Android as you would using Kotlin on Android. Worth evaluating if you're starting a project 6 months to a year from now as the Swift tooling for Android starts to mature.
As it stands now, I would have a look at Kotlin, but almost definitely write any projects started today in Java. Swift is nowhere near ready, and the advantage of writing in the platform's "native" language usually outweighs any benefits there are to using a "better" language.