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.
Component: Metrics and Firefox Health Report → Client: Desktop
Product: Mozilla Services → Firefox Health Report
Forward-duping into correct component.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 858742
You need to log in before you can comment on or make changes to this bug.