Hysen LabsPdfiumAndroidKt
Pdfium Android binding with Bitmap rendering ( >= API 21 )
PdfiumAndroidKt: three APIs over one PDF engine
A Kotlin binding to Pdfium for Android that renders bitmaps and offers three API styles: suspend functions, arrow, or plain Java-friendly calls.
What it wraps
PdfiumAndroidKt is a Kotlin library that binds Android to Pdfium, using the latest stable Pdfium release per the README, with bitmap rendering aimed at API 21 and above. Coroutines handle the native code so work stays off the main thread. The project metadata records Kotlin as the primary language and NOASSERTION for the license.
The three API flavors
One library, three API styles. The suspend variant uses suspend functions and runs on a dispatcher passed in when the core is created. The arrow variant layers arrow, and suspend functions, in a separate module that you add through the app build configuration. Then there is a plain API with nothing fancy, which the README says should work from Java. All of them share an object-oriented shape: a core opens the PDF, a document type carries the methods, and page and text page types come from it.
Performance notes
The README is practical about cost. Opening documents, pages, and text pages is relatively expensive, so avoid opening a page on demand and keep it open until you are done. Bitmap rendering in RGB 565 works but is slow, because the library has to allocate an ARGB 888 buffer, convert the data, and release it, while ARGB 888 writes directly with no buffer or conversion. Rendering straight to a Surface is fast and skips the memory overhead of bitmaps entirely.
Scope and version 2
The project does not do user interfaces, and the README says the team is open to helping integrate with your UI on a contract basis. Pull requests are welcome only when they stay within providing an Android binding for Pdfium, and PRs that customize the Pdfium libraries themselves are not accepted. Version 2 removed some deprecated APIs, on the argument that they had become cumbersome to implement and were deprecated anyway.
Editorial conclusion
The docs stay tightly scoped: a binding, three API styles, clear performance trade-offs, and a firm line about what contributions the project will take.
Community notes