GitLab

fix for a known security vulnerability. Vulnerability information is
stored in the library profiles.

  check whether and how the set of public library APIs change between
  versions.
- Added a convenience CLI option (-v) to create trace profiles
  (including any method signatures, but restricted to public methods).
  These trace profiles are required for the new lib-api-analysis
- some cleanup and documentation

- filter synthetic classes (added this functionality to WALA)
- normalize mismatch in number of arguments in constructors of anonymous
  inner classes

the library root package)

can not be resolved (e.g. android.support.v4.app.Fragment), the child classes
were not added to the class hierarchy. While this is okay for normal
analysis since these classes are dead code, this is problematic for LibScout that
fingerprints the exact package/class structure of a library and
therefore needs to be aware of all classes independent of their usage.
As workaround, unresolvable superclasses are changed to java.lang.Object
such that they can be added to the hierarchy. For the analysis this does
not have any side-effects.

[Lib-Merging] Formerly, there have been two distinct custom WALA libraries
(wala-dalvik.jar and joana.api.jar). These have been merged into a
single library. In this process, code filtering is applied to remove
unused code. Before this was done by the build.xml. This pre-filtering
reduces the library size from about 16MB to about 5MB.

- semver parsing is now used throughout the entire code (also for
  profile sorting)
- LibApiRobustnessStats are now per library instead of per lib version
  this reduces the memory footprint and simplifies some analyses
- general code rework/restructuring to improve
  readability/maintainability

code analysis, i.e. for each detected library, it is subsequently
checked which code of the library is used in terms of public API calls.
To this end, any code outside the library is scanned for call
invocations.

[added] LibraryApiRobustness analysis. For each distinct <lib,version>
pair, the set of public API is checked for robustness in successor
version, i.e. for each public API the highest version is determined
in which this API is existing.

[added] Library updatability analysis. Combining the results of the
two analyses (code usage + API robustness), this analysis determines
the highest version to which a detected library (version) could be
updated by simply replacing the library code (i.e. no code changes).

[added] java-semver library to parse library versions according to
semantic versioning. This allows us to reliably sort libraries by
version strings instead of relying on the optional (and sometimes
unreliable) library release dates.

directly instead of manually extracting the classes.jar first

detected

based on method access flags (public, private, protected, ..)

This can be enabled via a new -j CLI switch

- lib profiles now have a .lib extension
- app stats will now be written to subdirs of stat-dir according to
  their package name
- updated profile bundle

- removed some duplicate libs to shrink the jar file

- arguments are now parsed explicitly for passed mode of operation
- added some convenience (complete log disabling, stat dir
  configuration)
- improved usage helper message
- apps with existing stat files are automatically skipped during
  processing

profiles)