With the release of ADT 22, many Android developers encountered a significant change in how libraries are handled in Android Application Package (APK) files. Prior to this update, including libraries into the APK was a relatively straightforward task. However, the upgrade has introduced complexities that can hinder the automatic inclusion of libraries. This article delves into these changes, providing a technical exploration and offering insights to navigate the new obstacles.

Understanding the ADT 22 Update

The Android Developer Tools (ADT) is an integral part of the development environment used for building Android applications. With version 22, a major overhaul was introduced, affecting several functionalities and workflows. One of the significant changes was in the ADT's library management approach, impacting how libraries get packaged into APK files.

Overview of Changes

• Build System Overhaul: ADT 22 introduced a new build system that altered how dependencies are resolved and included.
• Dependency Management: There was a shift from dependency resolution at compile-time to more runtime-oriented dependency management.
• Library Inclusion Mechanism: Libraries are no longer automatically added to the APK; developers must now explicitly include and configure them.

Technical Explanation

Previous Workflow (Pre-ADT 22)

Before ADT 22, when an external library was added to an Android project, it was automatically included in the APK during the build process. Developers would often add libraries via the `libs` directory or through project properties. The build system would recognize and incorporate these dependencies without additional configuration.

Current Workflow (Post-ADT 22)

With ADT 22, the process of including libraries in APKs requires more explicit configuration. The default behavior no longer automatically adds all dependencies to the APK. Instead, developers must ensure the correct configuration in the `build.gradle` file, using the Gradle build system.

Example Configuration

• Dependency Insight: Use Gradle's dependency insight to understand the dependency resolution graph (`./gradlew dependencyInsight --configuration compileClasspath`).
• Revisiting ProGuard Rules: As the build and packaging logic change, revisit and update ProGuard rules to prevent obfuscation or removal of critical library classes.