PdfViewPager Android Setup, Sources, and API Limits

PdfViewPager's PDF Sources and Android Platform Boundary

PdfViewPager solves a narrow Android UI problem: putting a PDF document inside an Activity or Fragment and presenting it through a pager rather than sending the user to a separate application. The README documents three sources: a PDF in the application's assets, a file on external storage, and a PDF downloaded from a remote URL. That makes the library relevant to document previews, locally bundled manuals, and screens that depend on a file fetched after launch.

The primary implementation boundary is more important than the source list. The README states that PdfViewPager uses Android's `PdfRenderer` class, which works only on API 21 or higher. The repository's TODO also records support for API levels below 21 by downloading a PDF and invoking a system native intent, but the main usage examples are written for the in-app widget. An application with a broad device range should therefore distinguish between embedded rendering on supported Android versions and the legacy, external-intent approach.

The library is primarily Java. The README says it can also be used from Kotlin, but it points to a separate example instead of documenting Kotlin-specific APIs. The repository includes a `sample/` directory and a `library/` module, so integration is based on an Android Gradle dependency rather than a standalone command-line tool.

How PdfViewPager Loads and Releases a Document

The normal asset and local-file path is centered on `PDFViewPager` and `PDFPagerAdapter`. For an asset, the README first requires copying the file into the cache directory with `CopyAssetThreadImpl`. The pager is then constructed with the asset name. For a file already stored outside the app, the constructor receives its absolute path. The adapter is the resource-owning object that must be closed.

The XML route uses the same widget class and an `assetFileName` attribute. Once the document is attached, the README states that zooming and panning are available automatically. The TODO list says that initial PDF scale can be set in code and that zoom uses either `ImageViewZoom` or `photoview` approaches, but the usage excerpt does not show the exact setter or XML configuration for those options. Consumers should not infer a configuration key beyond the documented `assetFileName` attribute.

Remote documents follow a different data flow. `RemotePDFViewPager` receives a URL and a `DownloadFile.Listener`. The listener receives success, failure, and progress callbacks. On success, the example creates a `PDFPagerAdapter` using `AdobeXMLFormsSamples.pdf`, attaches it to the remote pager, and calls `setContentView`. In every documented lifecycle path, cleanup is explicit: cast the adapter where necessary and call `close()` from `onDestroy()`.

@Override
protected void onDestroy() {
    super.onDestroy();

    ((PDFPagerAdapter) pdfViewPager.getAdapter()).close();
}

Skipping this call leaves the documented cleanup responsibility unresolved. The README does not present a replacement lifecycle manager.

Adding PdfViewPager and Opening an Asset

The current dependency shown in the README uses the AndroidX-style coordinate. Add it to `app/build.gradle`. The README also documents an older `android.support` coordinate for projects that have not migrated, but it does not explain compatibility beyond that distinction. The repository lists no GitHub releases, so the README's `1.1.2` and `1.0.6` coordinates are the concrete versions available there.

After adding the dependency, an asset PDF must be copied to the cache directory before the pager is created. The sample filename in the README is `sample.pdf`. The XML example shows the fully qualified widget class, which is useful when a layout file does not import the Java package.

implementation 'es.voghdev.pdfviewpager:library:1.1.2'

This adds the library module to the Android application. For older support-library applications, the README gives this separate line instead:

implementation 'es.voghdev.pdfviewpager:library:1.0.6'

Copy an asset into the app cache and construct the pager using the documented helper:

CopyAsset copyAsset = new CopyAssetThreadImpl(context, new Handler());
copyAsset.copy(asset, new File(getCacheDir(), "sample.pdf").getAbsolutePath());

pdfViewPager = new PDFViewPager(this, "sample.pdf");

The asset name is `sample.pdf` in the example, while the copied destination is an absolute path under `getCacheDir()`. The README does not specify a custom cache directory, download timeout, or filename collision policy.

External Files and Remote Downloads in an Activity

For an external file, the README passes `getExternalFilesDir("pdf")` and the filename `adobe.pdf` to obtain the path. This is app-specific external storage rather than a general document picker flow. The example does not describe handling a user-selected URI, so applications needing arbitrary document-provider files would need to provide a different path and verify the widget's adapter contract.

PDFViewPager pdfViewPager = new PDFViewPager(context, getPdfPathOnSDCard());

protected String getPdfPathOnSDCard() {
    File f = new File(getExternalFilesDir("pdf"), "adobe.pdf");
    return f.getAbsolutePath();
}

Remote use requires three permissions in the README's manifest example: `INTERNET`, `WRITE_EXTERNAL_STORAGE`, and `READ_EXTERNAL_STORAGE`. The Activity or Fragment implements `DownloadFile.Listener`, and `RemotePDFViewPager` is constructed with the context, URL, and listener. The success callback creates an adapter, while the progress callback is documented as running on the UI thread.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

public class RemotePDFActivity extends AppCompatActivity implements DownloadFile.Listener {

The README does not document retry behavior, authentication, cancellation, content disposition handling, or local file cleanup after a failed download. Those omissions matter for remote documents that require more than a public URL.

API 21, Storage Permissions, and the Legacy Alternative

The clearest limitation is the `PdfRenderer` dependency. On Android versions below API 21, the primary widget path is not supported according to the README. The repository's completed TODO item says that lower API levels are handled by downloading the PDF and invoking a system native intent, which is a different user experience from an embedded pager. It can depend on an installed PDF application and may leave navigation, presentation, and lifecycle behavior to that external application.

This is an actual design trade-off rather than a missing installation instruction. PdfViewPager offers an in-app Activity or Fragment widget for API 21 and higher, but the documented fallback changes the execution model. An application that requires one consistent embedded experience across older Android versions should not treat the fallback as equivalent to the widget.

The remote example also lists `READ_EXTERNAL_STORAGE` and `WRITE_EXTERNAL_STORAGE`, although permission behavior varies by target SDK and Android version. The README does not state a `minSdk`, target SDK, scoped-storage strategy, or migration path. Those details must be checked in the sample module and the consuming application before release.

A practical alternative is a dedicated PDF viewer library that uses a different rendering backend or supports older Android versions. The repository names no competing library. The comparison supported by the README is narrower: PdfViewPager uses the platform `PdfRenderer` for the documented widget path, while its pre-21 behavior invokes a system native intent.

Maintenance, Verification, and Apache-2.0 Use

The repository is not archived, and its last push was on 2026-09-21. However, it has no GitHub releases, and the README points to a Bintray download badge and versioned Gradle coordinates. That combination leaves several integration questions for an adopter: artifact availability, whether the documented coordinates are still served by the intended repository, and whether a current Android Gradle Plugin will accept the older build configuration.

The repository includes `.travis.yml`, a Gradle wrapper, a `config/` directory, and `sample/src/`. The README says contributions should pass checkstyle and UI tests, and it gives these commands:

./gradlew checkstyle

./gradlew test

Those commands are the documented project checks, not a claim that they were executed here. The README also says UI tests exist, but it does not describe their coverage or the devices used.

The license is Apache License, Version 2.0. The repository includes a `LICENSE` file, and the README repeats the Apache 2.0 notice. An organization should review the license and its notice requirements as part of its own compliance process. This review should focus on the actual `LICENSE` file and dependencies, because the README does not describe third-party licensing for every rendering or testing component.

Editorial conclusion

Adopt PdfViewPager for an Android application that needs an embedded PDF pager on API 21 or higher and can manage its resources and source permissions explicitly. Do not select it for pre-Lollipop rendering through the documented PdfRenderer path, or for applications that need a maintained release process beyond the repository's documented dependency. Verify your Android support policy, selected Gradle coordinate, file access model, and adapter lifecycle before integration; the last push was on 2026-09-21 and the repository has no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. voghDev/PdfViewPager on GitHub