Table of Contents
What Blueprint is, and what it is not
Blueprint is an open source Android library, published on Maven Central as dev.jahir:Blueprint and developed in the Blueprint repository. A developer adds it to their project and gets a working dashboard for an icon pack: an icons browser, an apply screen for the launchers installed on the device, an icon request screen, a help screen, the widgets and wallpapers sections, and a settings screen. I write and publish the library.
Blueprint is built on top of Kuper, which is built on top of Frames, so the Kuper SDK privacy policy and the Frames SDK privacy policy apply here as well. This page covers what Blueprint adds to them.
I do not publish the apps built with Blueprint, and the library is open source, so an app built on a modified copy can behave differently from what this page describes. The icons, the server anything is served from, the address an icon request is sent to, and every optional feature belong to the developer of each app, and so does any change they made to the library. I do not run, choose or vet the request manager an app sends requests to. If you use one of those apps and want to know what it does with your data, that app’s developer is the one who can answer, and their privacy policy is the one that covers you.
The short version
Blueprint sends me nothing, and it has no analytics, no crash reporting, no advertising, no accounts and no telemetry.
It does send data off the device in one place, the icon request, and that request goes to the developer of the app you are using. Not to me. What it contains is written out below, because it is the one thing in any of these three libraries worth reading in full.
What Blueprint adds
Reading which apps are on the device
Required for the icon request screen and the apply screen.
Blueprint asks Android for the apps that have a launcher entry, and for the apps that can act as a home screen. It uses the first list to show which of your apps have no icon in the pack yet, and the second to offer the launchers it can apply the pack to. This is declared with <queries> in the manifest, using intent filters rather than QUERY_ALL_PACKAGES, so what it sees is the apps that appear in your app drawer, not everything installed.
Both lists are built on the device, each time the screen opens, and are not stored. Nothing is sent anywhere until you select apps and send a request.
Icon requests
Optional, user-initiated, and behind a consent dialog that has to be accepted once before the first request.
You pick the apps you want icons for, and Blueprint builds a zip containing the icon of each app you picked, extracted from the app itself, plus the XML files an icon pack designer needs: appfilter.xml, appmap.xml and theme_resources.xml. The files are written under Documents, or in the app’s own folder when that is not available, and are deleted once the request is sent.
Where the request goes depends on how the app’s developer set it up, and the two paths carry different data.
To a request manager, if the developer configured a backend address and an API key. Blueprint posts the zip to it, along with a JSON list of the apps you selected, holding the name, package name and component name of each one, with the developer’s API key in a header. The backend belongs to the developer, or to a service they chose, and it is their policy that covers what happens next. Nothing about your device is included in this path.
By email, when there is no backend configured. Blueprint hands your email app a message addressed to the developer, with the zip attached and a body listing the name, component and Play Store link of each app you selected, and then this about your device:
- The Android version, its build number and its API level
- The device and manufacturer, the model and product name
- The screen size in pixels
- The version of Blueprint, the version of the app, and which store installed it
You send that message yourself from your own email app, so the developer also sees the address you sent it from. If you would rather not send any of it, closing the message without sending it is enough. Nothing has left the device at that point.
The help screen
Its contact button opens the same kind of email, addressed to the app’s developer, with the device details listed above and no attachment.
What Blueprint keeps on the device
Whether the consent dialog was accepted, how many icons you have left in the request limit and when the limit last reset, and the icon shape picked for the previews. All in the app’s own preferences, all removed when the app is uninstalled.
Permissions
Blueprint declares no permissions of its own. It uses WRITE_EXTERNAL_STORAGE, which Frames declares capped at Android 9, to write the request files on older versions, and INTERNET for the upload path and for the sections Frames and Kuper provide.
Optional modules
The same ones Frames has, off unless the app’s developer turns them on: the Play licensing check and donations through Play billing. Push notifications are not part of the library.
If you are building an app with Blueprint
You are the one responsible for your users’ data, not me. An icon request arrives with you, and it carries the names of the apps on someone’s phone, their icons, and in the email path their device details and the address they wrote from.
Your Data safety form has to cover it. Installed apps and the device details go in it, the request manager you chose goes in it, and so does any optional module you switched on.
Your app needs its own privacy policy, and the consent dialog points users at it. This page describes the library.
Children
The library carries no icons and no content of its own, so it is suitable for all ages. What any given app ships comes from its developer, and the content rating is theirs to get right.
Your rights
I hold no personal data from the library. An icon request you sent went to the developer of the app you sent it from, so they are the ones who can show you what they have, correct it or delete it.
Under the GDPR, the UK GDPR and Colombia’s Ley 1581 de 2012 you can ask for access to your data, for it to be corrected or deleted, and you can object to its use. For any question about this policy, write to hola@jahir.dev and I will answer.
Third parties
- The request manager backend each app’s developer picks, when they configure one. Blueprint speaks the icon request protocol, so the service is usually one that implements it.
- Your own email app, in the email path, and the mail provider behind it.
- Google Play, for the optional licensing check and the optional donations, under Google’s privacy policy.
Changes
When this policy changes, the date at the top changes with it.