Recover projects after update: expose app dir, import legacy Gradle projects (compat mode)#1046
Closed
tyron12233 wants to merge 0 commit into
Closed
Recover projects after update: expose app dir, import legacy Gradle projects (compat mode)#1046tyron12233 wants to merge 0 commit into
tyron12233 wants to merge 0 commit into
Conversation
|
@tyron12233 Where is this roadmap you wrote about? |
edbbc2b to
85295b2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1003, #1024, #1041, #1042 — projects "disappearing" from the picker after a Play update.
Root cause
The app keeps the same
com.tyron.codeapplicationId across updates, so the external files dir survives — the data was never lost, just not surfaced. Two generations of project data exist on disk:getExternalFilesDir("Projects")→<external-files>/Projects/<name>— Gradle projects.<external-files>/codeassist/projects/<workspace>— native-model projects.What this does
1. Expose the whole external files dir. The
DocumentsProviderand the "Open in file manager" action now exposegetExternalFilesDir(null)(parent of bothProjects/andcodeassist/), with a full file view, so legacy sources are browsable. The storage card, reveal action, and provider all resolve the samestorageRoot.2. Recover into the picker.
ProjectManager.importLegacyProjects()(runs once, non-destructive) sweeps the legacy data dirs:GradleImportreader of the settings/build scripts — extracting modules, plugin/module type, theandroid {}SDK/namespace, anddependencies {}coordinates+scopes — which authors a native workspace from them.3. Set expectations. The Gradle import is best-effort: dependency versions aren't resolved and build-script logic is ignored, so a compatibility-mode project may show unresolved symbols and may not build until deps are re-added. This is surfaced as a per-project amber "Compatibility" chip and a dismissible first-run banner.
Backups now also sweep the legacy
Projects/dir.Limitations
Full Gradle sync (resolving the dependency graph, build-script evaluation) is roadmap step 9 and not attempted here. Compatibility-mode projects are for recovering/editing code, not guaranteed to build as-is.
Tests
GradleImportTest— parser (modules/types/SDK/deps/scopes) + end-to-end import that lists, flags compatibility, opens with the right modules, and has sources copied.ProjectManagerTest.importsLegacyProjectsFromAPreviousStorageLocation— current-format recovery.:ide-core:test,:ide-ui/:ide-desktopcompile, and:ide-android:compileDebugKotlin(clean aside from an unrelated untracked scratch file).