Update the API baseline

What These Changes Mean:

  Removed Methods: getDefaultImpl() and setDefaultImpl()
  These were part of an older AIDL pattern for handling default implementations when the service isn't available. This was a fallback mechanism that's been deprecated in favor of better error handling.

  Added: DESCRIPTOR Field
  This is the standard AIDL interface descriptor string - it's always been there internally, but now it's explicitly exposed in the public API.

  Added: LeakUiApp$_Parcel Class
  This is a newer AIDL tooling artifact - modern AIDL compilers generate additional helper classes for parcelization.

  Impact Analysis: ✅ Likely SAFE - No Breaking Changes for Clients

  Why this is probably fine:
  1. Internal APIs: These are in org.leakcanary.internal.* package - the internal namespace signals these aren't meant for public consumption
  2. AIDL Evolution: The Android AIDL compiler has been evolving to generate more modern, efficient code. The removed methods were legacy patterns.
  3. Backwards Compatible:
  - The core sendHeapAnalysis() method remains unchanged
    - The DESCRIPTOR field addition doesn't break existing clients
    - The new _Parcel class is just tooling infrastructure
  4. LeakCanary Context: This appears to be inter-process communication between LeakCanary components, not a public API for app developers
  ⚠️ Potential Concerns:
  1. If any external code was using the removed methods (unlikely since they're internal APIs)
  2. Binary compatibility for any code that was directly instantiating or reflection-accessing these classes

 What Could Have Caused This:
  1. Java 17 + newer Android Gradle Plugin - may use a newer AIDL compiler
  2. Updated compileOptions - could affect how AIDL generates code
  3. Build environment changes - newer toolchain versions
Recommendation:
  This is likely safe because:
  - It's internal LeakCanary APIs
  - The core functionality (sendHeapAnalysis) is preserved
  - This follows AIDL tooling evolution patterns

 However, you should consider:
  - Testing: Ensure LeakCanary still works properly between processes
  - Release notes: Document that internal AIDL APIs changed (if you publish these changes)
  - Monitoring: Watch for any reports of inter-process communication issues

 The changes appear to be tooling evolution rather than functional changes, but it's worth testing the actual LeakCanary functionality to be sure.