In which file/private folder does DroidScript save the Cookies file?

108 views
Skip to first unread message

Acr Acro

unread,
Oct 3, 2025, 10:57:09 AMOct 3
to DroidScript
Good time of day. I would like to know how I can manipulate the saved cookies in my application, being able not only to call the functions app.SaveCookies() and app.ClearCookies() (or webview.ClearCookies()), but also to manage these files (probably DroidScript saves these cookies in some private to use them between sessions) - that is, copy them, rename them, delete them in the application folder, etc., and not just erase or save them.

Dave

unread,
Oct 8, 2025, 4:35:12 AM (11 days ago) Oct 8
to DroidScript
We just use the standard Android CookieManager object which takes no storage path.  The Android Webview decides where to keep them and they are kept in an SQLite database file.

However I've added two new methods to the webview for V3: web.SetCookie( url, value ) and web.GetCookies( url ), so you could use those methods to save and load cookies between webview sessions.

Below is what ChatGPT has to say about saving and restoring them using the database file -


======================================================

If i use the Android CookieManager, where does it save them?
ChatGPT said:

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

    /data/data/<your.app.package>/app_webview/Cookies

    or sometimes

    /data/data/<your.app.package>/app_webview/Cookies-journal

    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

    /data/data/<your.app.package>/databases/webviewCookiesChromium.db

    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:

CookieManager cm = CookieManager.getInstance() String cookies = cm.getCookie("https://example.com") cm.removeAllCookies(null) cm.flush()

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.

You said:
can i clear a specific cookie
ChatGPT said:

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:

CookieManager cm = CookieManager.getInstance() String cookies = cm.getCookie("https://example.com")

That returns a string like:

sessionid=abc123; theme=dark; loggedIn=true

If you want to clear just theme, you can re-set that cookie with an expired date — which tells the browser to delete it:

CookieManager cm = CookieManager.getInstance() cm.setCookie("https://example.com", "theme=; Expires=Thu, 01 Jan 1970 00:00:00 GMT") cm.flush()

That’s the official way to remove one cookie.

If you want to replace it instead:

cm.setCookie("https://example.com", "theme=light; Path=/;") cm.flush()

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.

You said:
could I make a copy of the database for backup and then restore it later
ChatGPT said:
Thought for 29s

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)

Rules of thumb
  • 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.

Backup (Java)
public static File backupWebViewCookies(Context ctx, File destDir) throws IOException { CookieManager.getInstance().flush() File srcDir = new File(ctx.getDataDir(), "app_webview") String[] names = new String[]{"Cookies", "Cookies-wal", "Cookies-shm"} if (!destDir.exists() && !destDir.mkdirs()) throw new IOException("mkdirs failed") File lastCopied = null for (String n : names) { File f = new File(srcDir, n) if (f.exists()) { java.nio.file.Files.copy( f.toPath(), new File(destDir, n).toPath(), java.nio.file.StandardCopyOption.REPLACE_EXISTING ) lastCopied = f } } return lastCopied }
Restore (Java)

Do this before any WebView is created in the process (e.g., at app cold start, prior to showing UI).

public static void restoreWebViewCookies(Context ctx, File backupDir) throws IOException { // Ensure no WebView has been instantiated yet in this process File dstDir = new File(ctx.getDataDir(), "app_webview") String[] names = new String[]{"Cookies", "Cookies-wal", "Cookies-shm"} for (String n : names) { File src = new File(backupDir, n) if (src.exists()) { java.nio.file.Files.copy( src.toPath(), new File(dstDir, n).toPath(), java.nio.file.StandardCopyOption.REPLACE_EXISTING ) } else { // If WAL files aren’t present, also remove any stale ones at destination new File(dstDir, n).delete() } } }
Extra safety hacks
  • 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.

Things to avoid
  • 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.


Acr Acro

unread,
Oct 10, 2025, 9:05:43 AM (8 days ago) Oct 10
to DroidScript

Thank you very much, but I have already created a DroidScript plugin on Java for full control of the CookieManager in Android. :)
среда, 8 октября 2025 г. в 19:35:12 UTC+11, Dave:
Reply all
Reply to author
Forward
0 new messages