Two builds, and they do
not say the same things.

The Android privacy policy in full

# Privacy policy — CreasePoint PDF for Android

ARHAS INDIA (OPC) PRIVATE LIMITED, Hyderabad, Telangana, India. Last updated 2026-09-25.

This policy is about the Android application and nothing else. The Windows application has its own, at creasepoint.com/privacy, and the two products are genuinely different: the Windows one makes one network request and only if you switch it on, and this one makes several without asking. Nothing here is inherited from that policy — every sentence is written from what this application does, because a sentence that is true of one product and carried onto the other is the easiest way for a privacy policy to become false.

There are two builds and they do not have the same privacy properties. §1 is the difference, and it is the first thing on the page because it decides which of the rest applies to you.

0. The uncomfortable things first

Five things are true that a privacy policy would normally bury.

1. One feature sends the text of your document to a third party. It is called Summarise, it is in the Google Play build only, it does nothing until you press it, and it asks you before the first time. §4 is the whole of it. Everything else this application does — opening, editing, merging, splitting, compressing, recognising text, redacting, signing, saving — happens on your phone.
2. Advertising is in the Play build, and the advertising SDK collects things we never see. Google's Mobile Ads SDK collects an IP-derived approximate location, interactions with the advertisements, diagnostics, and device identifiers — among them the app set ID, which it uses for frequency capping, reporting and fraud prevention. It does not get the advertising identifier — the Play build removes that permission and we checked the merged package to be sure. That is Google's collection, not ours, and it is still our declaration to make. §3.
3. A summary can be wrong, and being wrong is not rare. We measured it. §4.4 gives a real example from the model we ship, because a policy that describes a feature without describing how it fails is describing something else.
4. We are an Indian company and Indian obligations follow us, not you. Where you are decides which of your rights apply; where we are registered decides who you complain to. §8 names a person.
5. If you let the Play build see every PDF on your phone, Android gives that access to the whole application — Google's advertising library included, because it runs inside it. It is off unless you turn it on, it is on Android's own settings page, and it covers every file in your phone's shared storage, not only PDFs. §6.1.

1. Which build you have, and how to tell

The plain build, in the words its own Settings screen uses: "This build declares no internet permission. The one permission it holds that grants it anything is the camera, which Scan asks for the first time you scan." You can check that yourself without running it: an APK's permission list is a static property of the file, and aapt dump permissions prints it. The plain build prints two — the camera, and one the application defines for itself, which grants access to nothing.

Until 2026-09-24 this paragraph said the plain build printed one permission and nothing that granted it anything. That stopped being true when both builds took the camera for the scanner, and the sentence was changed in the same change as the permission.

What that means is narrower than it sounds, and here is the narrow version: it stops this application opening a network connection. It does not stop a document leaving your phone. When you save to Google Drive, this application hands the file to Google Drive's own app, and that app does the networking — which is exactly how saving to a cloud drive works here without a permission.

And if you open the package and read the native libraries' import tables, three of them import socket functions from the system's C library. An APK is a zip file and readelf reads the libraries inside it, so we would rather say this before you find it. libtesseract.so, the OCR engine, imports socket, connect, getaddrinfo, freeaddrinfo, select, sendto and recvfrom for ScrollView, Tesseract's own debugging viewer, which is compiled in and which no OCR feature switches on. libSystem.Native.so and libmonodroid.so are the .NET runtime's, and carry the socket code every .NET application on Android carries. Measured on 2026-09-24 in a plain build, arm64-v8a and x86_64, and in the x86_64 libraries of a Play build. An import is not a call, and the imports are not what decides what this application does with the network: the plain build declares no permission to use it, and the Play build uses it for what §3, §4 and §5 describe.

2. What the application collects about you

Nothing. There is no CreasePoint account, no sign-in, no profile, no sync, no licence check, no analytics, no usage counter and no crash reporting of our own. We do not know how many people use this application, which features they use, or that any particular installation exists.

What it stores on your phone, in its own private storage:

• the documents you recently opened (up to 30), the ones you starred as favourites (up to 60), and the ones this application wrote for you (up to 30) — a compressed copy, a scan — so they can be found again: names and locations, not contents;
• folders you connected, so it can save to them again and list the PDFs in them;
• which recognition languages you last used;
• whether night reading is on;
• whether you have a subscription, as Google Play last reported it;
• whether you agreed to Summarise;
• whether you refused the camera for Scan and Android said it would not ask again, so the Scan screen can say so, and whether Scan's automatic shutter is on;
• a random identifier with no meaning outside our own summarising service, used to count your daily free summaries. It is not a device identifier, not an advertising identifier, and it follows you nowhere;
• and two whole documents, not just their names. When you send a document out through Android's share sheet, the application writes a copy into its own cache for the receiving app to read; when another app hands a document to this one — opening a PDF from Gmail or Drive, say — the application copies it into its cache to open it. Each copy stays until the next one of the same kind replaces it, so at most one of each exists, and it can be the last payslip or statement you handled. They sit in the application's private storage, where no other app can read them — apart from the app you sent a document to, while it has that document open;
• and the photographs of a scan you have not saved yet, with the flattened pages made from them — §2.1.

This list said "names and locations, not contents" and stopped there until 2026-09-23, while those two copies sat in the cache. It was incomplete, and the incompleteness was about contents — the one thing a reader of this section is checking for. It also said, until 2026-09-24, that a photograph taken for Scan was read and deleted straight away; the scanner keeps them until the scan is saved or discarded, and §2.1 says where and for how long.

And, in the EEA, the UK and Switzerland only, your advertising consent choices. Google's consent form writes them into this application's own storage under keys beginning IABTCF_, which is the industry-standard format so that the advertising stack can read your answer. Measured on a device on 2026-09-21: seventeen values, including which purposes you allowed, which vendors were disclosed to you, and a record identifier. Google's own form says the choices expire after 390 days. You can change them at any time in Settings → Advertising, and outside those countries none of it is written at all.

Clearing the application's data erases all of it, the two document copies and any unsaved scan included. Uninstalling erases all of it. None of it is copied to a new phone: the application opts out of Android's backup to Google Drive and, on Android 12 and later, out of the device-to-device transfer a phone migration performs.

Your saved scans are not in that list, because they are not the application's to erase. They are documents in your phone's own storage (§2.1), and they stay when the application's data is cleared and when it is uninstalled.

2.1 The camera, and your scans

The camera. Both builds hold Android's camera permission, for Scan, and ask for it the first time you scan — never when the application opens. While the camera screen is open the application looks at the camera's live picture on the phone, to find the edges of the page; the photographs it keeps are the ones taken of your pages. You can refuse the camera and still make a PDF from photographs you already have.

A scan in progress. Until you save it, a scan's photographs and the flattened pages made from them are kept in the application's own private storage — the part Android excludes from backup and from transfer to a new phone — so that a scan interrupted by a call, or by Android closing the application in the background, is still there when you come back. Saving the scan deletes them, and so does discarding it. A scan left untouched for seven days is offered to you once, and deleted after that.

A saved scan goes into Documents/CreasePoint in your phone's shared storage, without asking for a storage permission: it is a file of yours, like a download, and it is visible to Android's Files app and to any application you have given access to all your files. It survives uninstalling CreasePoint. After a reinstall, Android no longer counts those files as this application's, so they are not listed again until you choose Show scans from before on the Scan screen, which connects that folder the way §6 describes — or, on a Play build, until you allow the access in §6.1.

3. Advertising (Play build, free tier)

The free Play build shows a banner, and Premium removes it.

Where it appears: the home screens: All Files, Recent, Scan, Favourites and Tools; and at the end of a document you have scrolled to the end of. Never over a page you are reading, and never in the position your first file should be in.

What Google's Mobile Ads SDK collects: approximate location derived from your IP address, interactions with the advertisements, diagnostics, and device identifiers other than the advertising identifier — the app set ID among them, which non-personalised advertising still uses for frequency capping, reporting and fraud prevention. We do not receive this, cannot query it, and cannot switch it off while showing advertisements at all. Google's own policies govern it.

What it does not get is the advertising identifier. This build removes the AD_ID permission outright, so the SDK cannot read the one Android holds for you — and because the SDK asks for that permission itself, we verified the removal survived on the merged package rather than trusting our own manifest. The advertisements are not personalised either: the application disables personalisation on every request, everywhere, for everyone, whether or not any privacy law applies to you. You can still reset or delete your advertising ID in Android's settings, under Privacy → Ads; it makes no difference to this application, which never sees it.

Your documents are not given to it. No advertisement request carries anything from a file you opened.

4. Summarise (Play build, and only when you press it)

4.1 What is sent

The text of the document you have open. Not the file.

The application extracts the text with the same code that powers Find, and sends only that string over an encrypted connection to a small service we operate on Cloudflare, which passes it to a language model running on Cloudflare's own network. The model writes the summary and the summary comes back.

Not sent: the file itself, images, attachments, embedded files, digital signatures, document metadata, the filename, or where the document is stored.

One thing you cannot see for yourself, so we tell you. If a form was filled in and then flattened, what was typed becomes part of the page's text, and is therefore part of what is sent. Nothing distinguishes a flattened form from an ordinary paragraph — not for us and not for you. If a document has a live form in it, the consent sheet says so.

4.2 What is kept

Nothing, by us. There is no cache and no request log, deliberately and at a cost — caching would have cut our bill by about a third. The usual way to get both is Cloudflare's AI Gateway, and the reason we run none is that its cache and its logs work by keeping your text, so the feature we would be switching off is the one that stores the thing this page is about. Our service keeps counters and a random identifier; it never writes your text to storage or to a log.

Cloudflare processes it to produce the summary. Their terms govern what they do with it, and we link them rather than paraphrase them.

4.3 When it happens

Never, unless you press Summarise. The first time you press it you are shown exactly what is sent and asked. You are asked once in the life of the installation — whichever way you answer, you will not be asked again. You can change your answer at any time in Settings → Summarise, and turning it off is one tap with no confirmation.

Refusing costs you nothing but the feature. Every other part of the application is unchanged.

4.4 It can be wrong, and here is a real one

A model writes fluent prose and sometimes states something the document does not say. This is not a theoretical caution. On a logistics report we tested with, the model wrote that a fuel surcharge was "up 11.2% year-over-year" — but 11.2% was the surcharge's share of unit cost, not a rate of change, and the real change of +6.8% was in the same table. On another run it said "three structural risks" where the document's own heading said two.

We tightened the instructions we give the model, measured it again, and the same class of error still occurred. So we do not claim to have fixed it. Every summary carries a permanent note saying it can be wrong, and that note cannot be dismissed, because it is a description of the feature rather than a disclaimer about it.

Do not rely on a summary for anything that matters without reading the document.

5. Buying Premium (Play build)

The subscription is sold and processed by Google Play. We never see your payment details, your card, or your billing address. What we receive is Google's answer to one question — whether this Google account has an active subscription — and that answer is what removes the advertising and raises your daily summary allowance.

There is nothing to log into and nothing to restore manually. Play ties the subscription to the Google account your device is signed into, so reinstalling or changing phone restores it by itself. Settings has a Check my subscription row for when you want to make it ask again.

To cancel, use the Play Store's own subscription settings. We cannot cancel it for you and have no control over it.

6. Cloud folders you connect

If you connect a folder — somewhere on your phone, or in an app that offers folders in Android's own picker — Android grants this application access to that folder only, and you can take it back at any time with Disconnect on the folder's row in All Files. There is no account of ours involved, no OAuth token held by us, and no sign-in.

Until 2026-09-23 this section named cloud services nobody had connected this way, and sent you to Android's own settings to take the access back, where there is no control for a single folder.

When you save a document to a connected folder, it goes to your drive, not to us.

6.1 Every PDF on the phone (Play build, and only if you allow it)

A Play build can offer See every PDF on this phone in All Files. It appears only when the package installed on your phone asks for Android's all-files access — not every Play build does. It never appears on the plain build. On Android 10, which has no such access, All Files says instead that the list covers what CreasePoint can reach there.

What it does. If you turn it on, on Android's own settings page for it, All Files lists every PDF Android knows about on the phone, and CreasePoint can save over one in place. Android's all-files access is wider than PDFs: it lets the application read and change every file in your phone's shared storage — photos, downloads, documents.

Whose access it is. Android grants it to the application, not to a part of it. On the Play build that includes Google's Mobile Ads SDK, which runs inside the application. We give the SDK no file (§3), and we cannot make Android's grant narrower than the application it is given to, so we say so here and on the card that offers it.

Taking it back. Turn it off on the same Android page; All Files has a button to it. The next time the list is read it goes back to what CreasePoint can reach without it.

7. What we declare on Google Play

Play's Data safety section is generated from a form we complete. What we say there:

• Files and docs — collected, and shared with a third party, for app functionality. This is Summarise, and only Summarise. It is processed and not retained.
• Device or other IDs — collected, and shared with Google, for advertising, analytics and fraud prevention; and collected for app functionality. The first half is Google's Mobile Ads SDK and the app set ID it uses (§3); the second is the random per-install identifier in §2 that counts your free summaries. This line named only the second until 2026-09-23. Neither is Google's advertising identifier. The Play build removes the AD_ID permission outright, we checked the merged package rather than the source to be sure the removal survives the SDK asking for it back, and Play Console's separate advertising-ID declaration is therefore answered no.
• Approximate location — collected, for advertising. Google's Mobile Ads SDK may estimate it from your IP address. We declare it because the SDK can do it, not because we receive it; we derive no location ourselves and the application holds no location permission.
• App interactions and diagnostics — collected, for advertising and analytics by that SDK.
• Purchase history — collected by Google Play, to tell us whether you are a subscriber.

Not declared, and why: the camera's picture and the list of files on your phone are used on the phone and sent nowhere by us. Play's Data safety help says that data processed only on the device, and not sent off it, does not need to be declared; that is Play's definition, and it is why neither has a line above. What Google's advertising SDK collects is ours to declare — Play requires the developer to declare what an SDK inside the application collects — and the list above is what we declare for it, from the disclosure Google publishes for that SDK. We cannot see inside it, which is why §6.1 says plainly that all-files access is the whole application's.

If what we declare and what this page says ever differ, the difference is a mistake and we want to know. §8.

8. Your rights, and who to write to

Whoever you are, you can ask what we hold about you (the answer is: nothing tied to you), ask for it to be deleted (clearing app data does it immediately and without asking us), and withdraw consent for Summarise in Settings.

If India's Digital Personal Data Protection Act 2023 applies to you, you have rights of access, correction, erasure, grievance redressal and nomination, and the contact below is the grievance channel the Act requires.

If the GDPR applies to you, your legal bases are: consent for storing and reading the information on your device that advertising needs, asked through Google's consent form the first time you open the application; consent for Summarise, asked separately the first time you press it; contract for the subscription; and legitimate interests for the parts of advertising that Google relies on legitimate interests for, which the consent form lists and lets you object to.

The advertising is not personalised, whichever way you answer. The application tells Google's SDK to disable personalisation on every request, unconditionally and in every country, before any advertisement is asked for.

Two things about that form are worth saying plainly, because they are not what we would have written. It is Google's, its wording is fixed by the IAB Transparency and Consent Framework, and we cannot edit it. So it still offers you a choice about personalised advertising that this application will not use whatever you pick — and it still carries a sentence about precise geolocation, although this application holds no location permission of any kind and the form itself offers no precise-location control. What we could narrow, we did: on 2026-09-21 the advertising partner list was cut from 210 companies to one, Google, and a Do not consent button was added so that refusing is one tap rather than a menu.

This sentence used to read "there is no personalised advertising to consent to and we never ask you to." That was true when it was written and stopped being true when the consent form shipped.

Contact and grievances: privacy@arhas.in ARHAS INDIA (OPC) PRIVATE LIMITED, Hyderabad, Telangana, India. We answer within 30 days, and sooner if we can.

9. Children

This application is rated 3+ and is not directed at children. It collects nothing that identifies anyone. The free Play build shows advertising, and that advertising is non-personalised everywhere, by an explicit instruction to Google's SDK on every request.

What we do not yet do, said rather than implied: Google's SDK also accepts an age-restricted treatment, and this application does not set one. An earlier version of this page said the SDK "is configured for the rating the listing carries", which no code in the application established. It is an open item rather than a shipped one.

10. Changes

The version of this page on creasepoint.com is always the current one. A copy ships inside the application, and that copy is the text as at your version's release. Where they differ, the website is right and the difference is written at the top of the page rather than left for you to find.