On Android, the location and mechanism depend on which process and WebView implementation you’re using — but here’s the gist:
When you use android.webkit.CookieManager, the cookies are stored by the WebView’s internal Chromium engine, not by your app directly. They’re not saved as a normal file you can easily access; instead, they live in a private SQLite database or cache inside the app’s sandboxed data directory.
Specifically:
For Android Lollipop (5.0) and later, cookies are stored in
or sometimes
That’s a SQLite database managed by Chromium’s network stack.
On older Android versions (<5.0), WebView used the legacy WebKit backend, and cookies were stored in
or similar paths under /app_webview/.
If your app uses multiple WebViews or different processes, cookies are shared (since Android 5.0) across all WebViews within the same app via a common CookieManager singleton — the storage remains the same but is process-synchronized.
You can’t directly browse that database unless the device is rooted, but you can clear or inspect cookies via the API:
The flush() call ensures pending writes are committed to the underlying SQLite database.
If you’re curious for debugging, you can also look at your app’s data folder via adb shell run-as <your.package> and check the app_webview directory — you’ll see the Cookies file there.
So in short: it’s a Chromium SQLite store under your app’s private app_webview directory, invisible to the outside world but persistent across sessions until you or the system clear it.
Not directly by cookie name, no — the Android CookieManager API doesn’t expose fine-grained control like a browser’s developer console would. You can only:
Get all cookies for a domain
Overwrite them manually (which effectively deletes them)
Or clear all cookies
But there’s a simple workaround.
Let’s say you have:
That returns a string like:
If you want to clear just theme, you can re-set that cookie with an expired date — which tells the browser to delete it:
That’s the official way to remove one cookie.
If you want to replace it instead:
Just remember:
The domain and path must match the original cookie’s scope.
You can only manipulate cookies for domains you’ve already set (or loaded via WebView).
You can’t list individual cookies with metadata like expiry, domain, or path; getCookie() gives you only a flat string.
If you need more control (enumerating or filtering cookies), you’d have to manage your own cookie jar — a custom store layered over CookieHandler or OkHttp rather than relying on android.webkit.CookieManager.
Short answer: yes, but it’s fragile. There’s no official API to export/import WebView cookies, so your only lever is copying the on-disk SQLite DB (Cookies) inside your app’s sandbox. Do it carefully or you’ll corrupt the jar of biscuits.
Where it lives/data/data/<your.package>/app_webview/
Cookies (SQLite DB)
Cookies-journal / Cookies-wal / Cookies-shm (journals, depending on SQLite mode)
Do it when no WebView is active. Create no WebView instances, and ensure nothing else in your app touched WebView yet.
Flush first. CookieManager.getInstance().flush() to push pending writes.
Copy all related files. If WAL is enabled you must back up Cookies, Cookies-wal, and Cookies-shm together.
Version risk. Restoring across different WebView/Chromium versions may fail silently or cause odd behavior.
Permissions. Keep owner/permissions intact (app-private). Only your app can access these files.
Do this before any WebView is created in the process (e.g., at app cold start, prior to showing UI).
After flush(), wait a beat or run the copy on a background thread then post back.
If you ever did create a WebView in this process, call webView.destroy() and avoid touching WebView again before copying.
To be extra robust with WAL: copy Cookies, then Cookies-wal, then Cookies-shm quickly; on restore, copy all three before launching any WebView code.
Don’t try to cherry-pick rows inside the DB; Chromium may change schema.
Don’t restore a backup made on a different app ID or device expecting cross-app reuse—sandbox rules block that.
Don’t rely on this for long-term migration; it’s a pragmatic app-local backup, not a contract.
If your real goal is “portable session state,” consider storing your own app token (server-issued) and rebuilding cookies via normal login/API calls. That’s boring but future-proof.