Specify consumer Proguard files

[fractalwrench]

Goal

Adds ProGuard keep rules to the AAR artefact. This means that the library will work correctly when minification is enabled, without relying on the bugsnag gradle plugin to edit the library's proguard files.

Design

This allows users to avoid using the bugsnag gradle plugin if they so wish, without any additional configuration of ProGuard on their part.

Changeset

Added a proguard file with keep rules for the relevant classes.

Tests

Used Android Studio's APK analyzer to verify that an example project without the gradle plugin applied retained the correct classes in its Dex file.

Discussion

• We may want to consider the task in our gradle plugin which adds these rules automatically. The risk of this is that it could break builds for anyone who doesn't
  read the release notes.
• Do we need to update the Docs? They seemed ok to me.

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language

[coveralls]

Coverage remained the same at 74.791% when pulling 79a8461 on proguard-consumer-files into 944da8d on next.

[kattrali]

We may want to consider the task in our gradle plugin which adds these rules automatically. The risk of this is that it could break builds for anyone who doesn't
read the release notes.

What can we do to make this transition smoother? Can the Gradle plugin be changed to conditionally add the Bugsnag rules (based on the version of bugsnag-android in use or something)?

Do we need to update the Docs? They seemed ok to me.

Seems ok here too.

[fractalwrench]

What can we do to make this transition smoother? Can the Gradle plugin be changed to conditionally add the Bugsnag rules (based on the version of bugsnag-android in use or something)?

It should be possible to check the dependency at runtime within the gradle plugin, using something along the following lines:

    project.configurations.forEach { conf ->
        conf.allDependencies.forEach { dep ->
            if (dep.group == "com.bugsnag" && dep.name == "bugsnag-android") {
                println("Dep: " + dep)
            }
        }
    }

If it makes sense we could grab the lowest version from the dependencySet (after de-duping etc), and only write to the ProGuard file if the version is less than 4.X.X.

[kattrali]

Sounds good to me 🤔

[fractalwrench]

Added in: bugsnag/bugsnag-android-gradle-plugin#116