summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorLi Li <dualli@google.com>2020-11-03 18:02:56 -0800
committerLi Li <dualli@google.com>2020-11-05 14:32:48 -0800
commitbe5bebafabd509df9a1abcbf4c54a60c24504c5c (patch)
treec06ebbffc98822e039344041a38ee476f4941d24 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent6cac0b0fb209cd2cc6894f7f816cb03a1bdf4172 (diff)
Use CloseGuard for cursor leak detection
Protect Cursors with CloseGuard and report implicit cleanup. By default, the leak detection code will print a one-line warning message about failing to call the cleanup function. To report more details like the original stacktrace and SQLite query statement, enable the correspoinding VmPolicy flags as the example below, please. /* * public void onCreate() { * if (DEVELOPER_MODE) { * StrictMode.setVmPolicy(new VmPolicy.Builder() * .detectLeakedSqlLiteObjects() // for SqlLiteCursor * .detectLeakedClosableObjects() // for any Cursor * .penaltyLog() * .build()); * } * super.onCreate(); * } */ By enabling detectLeakedSqlLiteObjecs, the original SQLiteCursor query statement is reported when close() or its equivalent cleanup function is not called before finalize(). By enabling detectLeakedClosableObjects, the new CloseGuard report will be provided, along with the original stack trace captured in open() or its equivalent. The former has better performance as it doesn't capture an original stack trace during open() stage. Only enable the latter if performance impact is not an issue. Both of them can be enabled at the same time. Bug: 168639120 Test: manually test with an example SQLite Android application, with and without calling cursor.close() after a db.rawQuery(). Change-Id: Ibe9fcdc8119c2e4651df1983e7ccd793f29e8e9d Signed-off-by: Li Li <dualli@google.com>
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions