Skip to content
Snippets Groups Projects
  • Remi NGUYEN VAN's avatar
    e55a88d3
    Use jarjar rule generator for connectivity rules · e55a88d3
    Remi NGUYEN VAN authored
    (This rolls forward part of a previous change, now that jarjar was fixed
    to not get very slow when the number of rules increases).
    
    Autogenerate connectivity jarjar rules at build time, to avoid issues
    with forgotten jarjar rules or hard-to-diagnose errors introduced by
    incorrect rules.
    
    This change causes all classes in framework-connectivity(-t) and
    service-connectivity to be jarjared into android.net.connectivity, but
    still avoids jarjaring classes in com.android.server as before, to keep
    it small.
    For many classes this differs from the original jarjar rule.
    
    Notes on implementation:
    
     - connectivity-jarjar-rules now has a subset
       framework-connectivity-jarjar-rules containing only the rules
       necessary for framework-connectivity. This is necessary because
       framework-connectivity cannot depend on rules generated based on
       service-connectivity, as there would be a dependency cycle
       (service-connectivity depends on framework-connectivity); Soong even
       crashes with a stack overflow.
    
     - framework-wifi.stubs.module_lib is added to
       framework-connectivity-pre-jarjar as it is necessary to build it (it
       is already in impl_only_libs in the defaults).
       It is unclear why framework-connectivity-pre-jarjar could build
       before that (possibly because it was only used as "lib" ?)
    
     - Fix package-private visibility; for example NattSocketKeepalive,
       TcpSocketKeepalive are not API so should be jarjared, but are used
       by ConnectivityManager which is not jarjared, so they are not in the
       same package after the change. Package-private members in the
       former 2 need to be public to be accessible. Changes in this commit
       are all that is needed, as demonstrated by followup commits that move
       the classes to a different package without further changes, and that
       enforce that no class in an API package gets jarjared.
    
     - framework-connectivity-internal-test-defaults is separated from
       framework-connectivity-test-defaults, for unit tests that need to
       access internal jarjared classes. Such tests need to use the jarjar
       rules themselves too, so this is only appropriate for connectivity
       internal unit tests.
    
    Test: atest ConnectivityCoverageTests CtsNetTestCases
    Bug: 217129444
    Change-Id: Ib1bd939b71c0171d945fc01b96195d2f620ff13b
    e55a88d3
    History
    Use jarjar rule generator for connectivity rules
    Remi NGUYEN VAN authored
    (This rolls forward part of a previous change, now that jarjar was fixed
    to not get very slow when the number of rules increases).
    
    Autogenerate connectivity jarjar rules at build time, to avoid issues
    with forgotten jarjar rules or hard-to-diagnose errors introduced by
    incorrect rules.
    
    This change causes all classes in framework-connectivity(-t) and
    service-connectivity to be jarjared into android.net.connectivity, but
    still avoids jarjaring classes in com.android.server as before, to keep
    it small.
    For many classes this differs from the original jarjar rule.
    
    Notes on implementation:
    
     - connectivity-jarjar-rules now has a subset
       framework-connectivity-jarjar-rules containing only the rules
       necessary for framework-connectivity. This is necessary because
       framework-connectivity cannot depend on rules generated based on
       service-connectivity, as there would be a dependency cycle
       (service-connectivity depends on framework-connectivity); Soong even
       crashes with a stack overflow.
    
     - framework-wifi.stubs.module_lib is added to
       framework-connectivity-pre-jarjar as it is necessary to build it (it
       is already in impl_only_libs in the defaults).
       It is unclear why framework-connectivity-pre-jarjar could build
       before that (possibly because it was only used as "lib" ?)
    
     - Fix package-private visibility; for example NattSocketKeepalive,
       TcpSocketKeepalive are not API so should be jarjared, but are used
       by ConnectivityManager which is not jarjared, so they are not in the
       same package after the change. Package-private members in the
       former 2 need to be public to be accessible. Changes in this commit
       are all that is needed, as demonstrated by followup commits that move
       the classes to a different package without further changes, and that
       enforce that no class in an API package gets jarjared.
    
     - framework-connectivity-internal-test-defaults is separated from
       framework-connectivity-test-defaults, for unit tests that need to
       access internal jarjared classes. Such tests need to use the jarjar
       rules themselves too, so this is only appropriate for connectivity
       internal unit tests.
    
    Test: atest ConnectivityCoverageTests CtsNetTestCases
    Bug: 217129444
    Change-Id: Ib1bd939b71c0171d945fc01b96195d2f620ff13b
Code owners
Assign users and groups as approvers for specific file changes. Learn more.