IpSecManager and IpSecTransform API Cleanup
-Remove Int-based SPI usage from the IpSecTransform.Builder
This is essentially a less-safe method overload, and it is both
unnecessary and difficult to implement: the cross-validation
between SPI and Transform is actually useful, and the kernel
requires two different mechanisms to use an unreserved vs a
reserved (alloc'd) SPI: CREATESA vs UPDATESA, which makes this
hard to support. API Council has questioned the value of this,
and they are right: everything points to "remove this". In the
future, if we find that SPI reservation is overhead, we can
always add it back.
-Hiding the TunnelMode builder method and application/remove
methods. These will not land by the time the next API
stabilizes, so better to hide them now that this is a
near-certainty. Expectation is to un-hide them in the subsequent
API bump.
Bug: 36073210
Test: Compilation, verified nobody is calling these stubs
Change-Id: Ic1a3f2cf7128633318ac175d6b56b45eb8d21cab
(cherry picked from commit 48b566557d5a66d4476008b3c59b815eb78cb373)
diff --git a/core/java/android/net/IpSecManager.java b/core/java/android/net/IpSecManager.java
index 83f4cc9..3fcdb7e 100644
--- a/core/java/android/net/IpSecManager.java
+++ b/core/java/android/net/IpSecManager.java
@@ -197,7 +197,6 @@
* @param transform an {@link IpSecTransform}, which must be an active Tunnel Mode transform.
* @hide
*/
- @SystemApi
public void applyTunnelModeTransform(Network net, IpSecTransform transform) {}
/**
@@ -242,7 +241,6 @@
* network
* @hide
*/
- @SystemApi
public void removeTunnelModeTransform(Network net, IpSecTransform transform) {}
/**
diff --git a/core/java/android/net/IpSecTransform.java b/core/java/android/net/IpSecTransform.java
index 5c0bbe6..74d6010 100644
--- a/core/java/android/net/IpSecTransform.java
+++ b/core/java/android/net/IpSecTransform.java
@@ -305,32 +305,9 @@
* given destination address.
*
* <p>Care should be chosen when selecting an SPI to ensure that is is as unique as
- * possible. Random number generation is a reasonable approach to selecting an SPI. For
- * outbound SPIs, they must be reserved by calling {@link
- * IpSecManager#reserveSecurityParameterIndex(int, InetAddress, int)}. Otherwise, Transforms will
- * fail to build.
- *
- * <p>Unless an SPI is set for a given direction, traffic in that direction will be
- * sent/received without any IPsec applied.
- *
- * @param direction either {@link #DIRECTION_IN or #DIRECTION_OUT}
- * @param spi a unique 32-bit integer to identify transformed traffic
- */
- public IpSecTransform.Builder setSpi(@TransformDirection int direction, int spi) {
- mConfig.flow[direction].spi = spi;
- return this;
- }
-
- /**
- * Set the SPI, which uniquely identifies a particular IPsec session from others. Because
- * IPsec operates at the IP layer, this 32-bit identifier uniquely identifies packets to a
- * given destination address.
- *
- * <p>Care should be chosen when selecting an SPI to ensure that is is as unique as
- * possible. Random number generation is a reasonable approach to selecting an SPI. For
- * outbound SPIs, they must be reserved by calling {@link
- * IpSecManager#reserveSecurityParameterIndex(int, InetAddress, int)}. Otherwise, Transforms will
- * fail to activate.
+ * possible. To reserve a value call {@link IpSecManager#reserveSecurityParameterIndex(int,
+ * InetAddress, int)}. Otherwise, SPI collisions would prevent a transform from being
+ * activated. IpSecManager#reserveSecurityParameterIndex(int, InetAddres$s, int)}.
*
* <p>Unless an SPI is set for a given direction, traffic in that direction will be
* sent/received without any IPsec applied.
@@ -447,7 +424,6 @@
* properties is invalid.
* @hide
*/
- @SystemApi
public IpSecTransform buildTunnelModeTransform(
InetAddress localAddress, InetAddress remoteAddress) {
//FIXME: argument validation here