Environment: AIR SDK 51.3.3, Android packaging (-target apk-captive-runtime).
Summary:
AIR-packaged Android apps inherit Android's default android:allowBackup="true". As a result, data written via SharedObject.getLocal() — AIR's own primary persistence API — is automatically backed up and restored after a full uninstall + reinstall. From the developer's side this looks like a "fresh install" still carrying old state, which is the opposite of what almost every AIR developer expects from SharedObject.
Impact:
This cost our team roughly 8 hours of debugging. We were testing a clean-install code path, repeatedly deleting and reinstalling the app, and could not understand why persisted values kept returning. There is no setting in the application descriptor or in the AIR tooling that exposes this, and nothing in the SharedObject documentation warns that its data survives uninstall on Android. The only fix is to hand-write android:allowBackup="false" into the block — which you cannot find unless you already know the cause.
Request:
Document it. Add an explicit note to the SharedObject / Android packaging docs that allowBackup defaults to true and that SharedObject data is restored across reinstall.
Surface it. Consider a descriptor-level option (or at least a build-time note) for allowBackup, since the current default contradicts AIR's own persistence semantics.
This is a small flag with a large, invisible footprint. Making it discoverable would save other developers the same lost day.
Environment: AIR SDK 51.3.3, Android packaging (-target apk-captive-runtime).
Summary:
AIR-packaged Android apps inherit Android's default android:allowBackup="true". As a result, data written via SharedObject.getLocal() — AIR's own primary persistence API — is automatically backed up and restored after a full uninstall + reinstall. From the developer's side this looks like a "fresh install" still carrying old state, which is the opposite of what almost every AIR developer expects from SharedObject.
Impact:
This cost our team roughly 8 hours of debugging. We were testing a clean-install code path, repeatedly deleting and reinstalling the app, and could not understand why persisted values kept returning. There is no setting in the application descriptor or in the AIR tooling that exposes this, and nothing in the SharedObject documentation warns that its data survives uninstall on Android. The only fix is to hand-write android:allowBackup="false" into the block — which you cannot find unless you already know the cause.
Request:
Document it. Add an explicit note to the SharedObject / Android packaging docs that allowBackup defaults to true and that SharedObject data is restored across reinstall.
Surface it. Consider a descriptor-level option (or at least a build-time note) for allowBackup, since the current default contradicts AIR's own persistence semantics.
This is a small flag with a large, invisible footprint. Making it discoverable would save other developers the same lost day.