Understanding and Removing Java Access Methods in Android Applications

Background: What are access methods – Java’s encapsulation forbids direct access to private members, yet inner classes and their outer classes need to access each other's private members. To preserve encapsulation, the Java compiler generates package‑visible static access$xxx methods that replace direct private accesses.

In addition to inner‑class interactions, other cases (e.g., an inner class accessing a protected method of a non‑same‑package superclass) also generate access methods, but the inner‑class scenario accounts for about 93% of generated methods in the Xigua Video app, motivating the need for safe removal.

Impact of access methods

Each additional method counts toward the 65,535‑method limit of a DEX file, potentially forcing multidex splitting; Xigua Video originally had over 10,000 access methods.

Access methods increase code size, adding several hundred kilobytes to the APK.

Calling an access method incurs extra overhead (stack‑frame allocation), affecting runtime performance.

Ways to avoid generating access methods

Manually adjust visibility during development (e.g., replace private with package‑visible), which reduces encapsulation and requires extensive documentation.

Use ASM to delete generated access methods at compile time.

The manual approach, while recommended by Google’s Android developer guide, has drawbacks: it relies on developers to constantly analyze code, breaks encapsulation, and does not work for third‑party libraries.

To address these issues, Xigua Video applied two optimizations:

Automated scripts that strip the private keyword (which cannot solve all problems and may trigger a Dalvik bug).

A custom javac plugin that introduces an @Private annotation to retain encapsulation while allowing the compiler to replace private with package‑visible members; IDE warnings remain but compilation enforces the rule.

Despite these steps, the fourth problem (inter‑package method overriding) persisted, leading to the decision to use ASM for automatic removal of access methods. The ASM‑based workflow is:

Scan all bytecode files and identify access methods generated for inner‑class private member access (≈93% of total access methods in Xigua Video).

Analyze each access method to determine the actual target field or method, and whether the operation is a read or write.

Elevate the visibility of the real target from private to package‑visible.

Rewrite all call sites to directly access the target field or method, adjusting invocation instructions for methods as needed.

Ensure that visibility elevation does not introduce incorrect overriding behavior (implementation details are described later).

After this process, the synthetic access methods disappear, while developers can continue to write private members, preserving encapsulation without the performance and size penalties.

Dalvik bug impact

During testing, a bug was observed on Android 4.x devices where a pull‑to‑refresh action cleared a list. The root cause was that after ProGuard, a private‑to‑package method in a superclass was incorrectly overridden by a method in a subclass from a different package—a behavior that violates Java’s visibility rules but occurs due to a Dalvik bug (fixed in ART). The workaround involves building a class‑inheritance tree at compile time and skipping optimization for methods that could be overridden across packages, with different rules for minSdkVersion ≥ 21 and < 21.

Benefits and stability

Since enabling access‑method removal in June 2018, Xigua Video has not encountered any regressions. Approximately 93% of access methods (~12,000) were eliminated, reducing APK size by about 400 KB and confirming the approach’s safety and effectiveness.

Follow the Xigua Technology Team for more insights.