The documentation has this to say on the issue:
If you aren’t using an item-keyed network API, you may be using
page-keyed, or page-indexed. If this is the case, the paging library
doesn’t know about the page key or index used in the BoundaryCallback,
so you need to track it yourself. You can do this in one of two ways:Local storage Page key
If you want to perfectly resume your query,
even if the app is killed and resumed, you can store the key on disk.
Note that with a positional/page index network API, there’s a simple
way to do this, by using the listSize as an input to the next load (or
listSize / NETWORK_PAGE_SIZE, for page indexing). The current list
size isn’t passed to the BoundaryCallback though. This is because the
PagedList doesn’t necessarily know the number of items in local
storage. Placeholders may be disabled, or the DataSource may not count
total number of items.Instead, for these positional cases, you can query the database for
the number of items, and pass that to the network.In-Memory Page key
Often it doesn’t make sense to query the next page
from network if the last page you fetched was loaded many hours or
days before. If you keep the key in memory, you can refresh any time
you start paging from a network source. Store the next key in memory,
inside your BoundaryCallback. When you create a new BoundaryCallback
when creating a new LiveData/Observable of PagedList, refresh data.
For example, in the Paging Codelab, the GitHub network page index is
stored in memory.
And links to an example Codelab: https://codelabs.developers.google.com/codelabs/android-paging/index.html#8