As part of enhancing the FHR payload for non-Gecko data points -- bookmark counts, versions, sessions, searches, etc. -- we'll at some point need longitudinal storage in Java. This bug will track the design and implementation of such. My outline proposal is to use a ContentProvider backed by an Android SQLiteDatabase, which allows Android to control the lifecycle to balance memory against startup cost, makes it trivial for both Fennec and our raft of background services to record data, and offers some robustness guarantees. Counter-proposals welcome! In doing so, please bear in mind Android lifecycle/termination concerns, heap usage and classloaders, and the distinction/linkage between the CP interface and backing storage.

Forward-duping into correct component.