When an SDK is abandoned, set a deadline and pick one of four paths: replace it, remove the feature, freeze it with compensating controls for a short time, or fork it if you can maintain it. Do not leave it unowned. An SDK nobody updates will eventually block a store submission or ship a known flaw.
How to tell an SDK is abandoned
Look for signals rather than a single event:
- No release for a long period compared with its peers, and open security issues with no reply.
- A repository archived, or a vendor notice of end of life or sunset.
- Build warnings. Android's dependency documentation says Android Studio shows warnings for SDKs that are outdated, violate Play policies, have known security vulnerabilities or are deprecated, and that outdated versions could stop you publishing to the Play Console in future.
- Platform changes the SDK does not support, such as a new privacy manifest or signature requirement on Apple platforms.
Record the signal and the date in the register, then start the clock.
The four paths
| Path | Choose when | Cost | Risk |
|---|---|---|---|
| Replace | A maintained alternative exists | Integration and testing | Low once done |
| Remove | The feature is no longer worth it | Product decision | Low |
| Freeze | You need months to migrate and the SDK has no open flaws | Low now | Rising each month |
| Fork | The code is small, licensed to allow it, and you have owners | Ongoing maintenance | Medium, you now own security fixes |
Forking is the choice teams underestimate. You inherit every future vulnerability in that code and its dependencies. Do it only with a named owner and a plan.
A timeline
- Week 0: confirm status with the vendor or maintainers. Ask directly in writing.
- Week 1: choose a path and record the decision and owner.
- Weeks 2 to 6: start the replacement or removal. If you froze, add compensating controls such as a wrapper, reduced permissions and traffic filtering.
- Before the next major OS release: have the migration shipped or a tested plan.
- After: remove it fully and close the register entry.
Compensating controls for a frozen SDK
- Pin the exact version and verify artifacts, see Gradle verification.
- Restrict what the SDK can receive and send through your wrapper.
- Watch advisories for it and its dependencies on every build.
- Set an expiry date on the exception, and review it.
A frozen SDK is a time limited exception. Without an end date it is just a quiet default.
Tell the people who need to know
Product needs to know the migration date because feature work may be affected. Privacy needs to know if data flows change. Support needs a note if users will see a change. Keep the message short and put the deadline first.
Safeguard's dependency scanning and policies can alert on known advisories in a frozen component, which helps with the watching step. A free scan is at gold.safeguard.sh/scan.
Quick check
How long can we keep an abandoned SDK?
Only as long as the exception says. Set a date, name an owner and tie it to a migration plan.
Is forking a good way out?
Only with a named owner and the capacity to track and fix vulnerabilities. Otherwise you have just renamed the problem.
Sources
Last reviewed: 19 October 2026.
