Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

redundancy: remove unspecial special cases #3755

Merged
merged 2 commits into from
Jan 15, 2025

Conversation

IgorEisberg
Copy link
Contributor

As we discussed before, some of the dirs in RAW_DIRNAMES are treated as standard dirs in an APK, despite not being such.

Instead of arbitrarily deciding what is known and what is unknown, we can make a concrete distinction: known dirs are dirs that are standard in APKs as generated by aapt: assets, lib and res. Everything else is app or library-specific and is unknown to aapt or smali/baksmali and should be treated as raw files that must be preserved as-is.

libs (not lib) is another example of a non-standard dir that might appear in specific APKs simply because the developers decided so, but it's not used for native libraries when calling loadLibrary.
https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=565

Thanks to refactoring done some months ago, everything in unknown is already being preserved when rebuilding an APK, no special considerations needed for kotlin.

As we discussed before, some of the dirs in RAW_DIRNAMES are treated
as standard dirs in an APK, despite not being such.

Instead of arbitrarily deciding what is known and what is unknown,
we can make a concrete distinction: known dirs are dirs that are
standard in APKs as generated by aapt: "assets", "lib" and "res".
Everything else is app or library-specific and is unknown to aapt or
smali/baksmali and should be treated as raw files that must be
preserved as-is.

"libs" (not "lib") is another example of a non-standard dir that might
appear in specific APKs simply because the developers decided so, but
it's not used for native libraries when calling loadLibrary.
https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=565

Thanks to refactoring done some months ago, everything in "unknown" is
already being preserved when rebuilding an APK, no special considerations
needed for kotlin.
Copy link
Owner

@iBotPeaches iBotPeaches left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, but I'll hold merging until next cut.

@iBotPeaches iBotPeaches enabled auto-merge (squash) January 15, 2025 02:21
@iBotPeaches iBotPeaches added this to the v2.12.0 milestone Jan 15, 2025
@iBotPeaches iBotPeaches merged commit 4d36ca8 into iBotPeaches:master Jan 15, 2025
25 checks passed
@IgorEisberg IgorEisberg deleted the rmkotlin branch January 15, 2025 03:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants