Quick answer
A widget can display information that is easier for someone else to see than the same information inside a locked app. Before using calendar, media, health or custom web data, check which app receives the permission and whether that information will appear on an unlocked home screen. Prefer only the access needed for the chosen feature. Review third-party links, data-source endpoints and screenshots before sharing anything sensitive.
A widget is part of an app, not a separate permission sandbox
An Android widget belongs to an installed app. The app may need permission to show calendar information, media information or health data. A simple local clock can need much less access. Do not decide whether an app is private by whether its widget looks minimal or transparent.
The important question is what that installed app reads, stores and sends. The widget may show a value on screen, while the app uses networking for templates, advertising or connected data. A promise of “no account required” does not by itself mean there are no network requests.
Six checks before granting access
- Read the feature's explanation. A calendar widget should explain why it wants calendar access; a photo widget should explain which images it can select.
- Inspect Android permissions. Open Settings, Apps, choose the app, then Permissions. Exact menu names vary. Compare requested access with the widget you want to use.
- Find the actual data source. A weather panel may contact a provider; a task widget may use locally saved notes. A custom HTTPS widget will send information to the chosen endpoint.
- Read the app's privacy policy. Check whether it describes ads, analytics, provider requests, credential handling and how to contact the developer. A broad claim such as “100% private” is not a substitute for details.
- Look for optional features. If a source requires more data than you want to share, use a simpler local design instead.
- Test permission denial. A careful app should explain an unavailable feature when permission is denied, rather than silently implying that real data is connected.
Be especially careful with screenshots of calendar or health widgets. They can reveal private details even if the app never uploads the original design.
What custom connections may send
When you configure a widget to request an external HTTPS service, the request typically includes the address you chose, any query parameters and authentication configured for that service. The remote provider may also see normal connection information such as your IP address. HTTPS protects data in transit but does not make the destination provider unable to read the request.
If a token is exposed in a shared widget template, a screenshot or a public URL, treat it as sensitive. Do not paste personal API keys into publicly published examples. Revoke an exposed key using the provider's own account controls.
WidgetCraft-specific facts
WidgetCraft stores authored photos and designs locally rather than uploading them to a developer cloud backup. Saved custom service credentials are encrypted on-device using Android Keystore. Online templates and optional advanced sources still require network requests; the free app uses AdMob. These facts do not justify claiming that the entire app collects no data or never goes online.
Restoring a Google Play Pro purchase is not the same thing as restoring saved designs. If you are switching phones, confirm an available export method before wiping the old one. See local storage and backups.
Read permissions by feature, custom HTTPS sources and example versus live data. For platform-level permissions, use Android Developers' permissions overview.