Update README

The old one's really old.
We move the old readme to the dataconnection directory, since that's
what it's about.

Change-Id: Ic46d14d181efbb5476d58a25608bd8620c14f641
Fixes: 114302387
Test: no behavior change

2 files changed, 98 insertions, 61 deletions

diff --git a/README.txt b/README.txt
index e613a00a36..9e40b7713d 100644
--- a/README.txt
+++ b/README.txt
@@ -1,71 +1,37 @@
-This package contains classes used to manage a DataConnection.
+-- README for frameworks/opt/telephony --
 
-A criticial aspect of this class is that most objects in this
-package run on the same thread except DataConnectionTracker
-This makes processing efficient as it minimizes context
-switching and it eliminates issues with multi-threading.
+This directory contains telephony libraries which function as the
+implementation code for APIs in TelephonyManager, SubscriptionManager,
+SmsManager and others.
 
-This can be done because all actions are either asynchronous
-or are known to be non-blocking and fast. At this time only
-DcTesterDeactivateAll takes specific advantage of this
-single threading knowledge by using Dcc#mDcListAll so be
-very careful when making changes that break this assumption.
+These libraries run in the com.android.phone process and exist to support
+telephony services created by the user’s apps (generally carrier apps), or by
+the system. This includes making phone calls, sending SMS/MMS, and connecting
+to data. Many APIs are plumbed down to the radio through HIDL calls defined in
+hardware/interfaces/radio/ hardware/interfaces/radio/config and return values
+that are sent back up as responses.
 
-A related change was in DataConnectionAc I added code that
-checks to see if the caller is on a different thread. If
-it is then the AsyncChannel#sendMessageSynchronously is
-used. If the caller is on the same thread then a getter
-is used. This allows the DCAC to be used from any thread
-and was required to fix a bug when Dcc called
-PhoneBase#notifyDataConnection which calls DCT#getLinkProperties
-and DCT#getLinkCapabilities which call Dcc all on the same
-thread. Without this change there was a dead lock when
-sendMessageSynchronously blocks.
+We define several AIDL interfaces in frameworks/base/telephony/ which we
+implement in this directory and packages/services/Telephony. This IPC scheme
+allows us to run public API code in the calling process, while the
+telephony-related code runs in the privileged com.android.phone process. Such
+implementations include PhoneInterfaceManager, SubscriptionController and
+others.
 
+The declaration of the com.android.phone process is in
+packages/services/telephony and the top-level application class is PhoneApp,
+which initializes everything else.
 
-== Testing ==
+-- Testing --
 
-The following are Intents that can be sent for testing pruproses on
-DEBUGGABLE builds (userdebug, eng)
+Unit tests are found in frameworks/opt/telephony/tests and can be
+run on a device connected through ADB with the command:
 
-*) Causes bringUp and retry requests to fail for all DC's
+	atest FrameworksTelephonyTests
 
-  adb shell am broadcast -a com.android.internal.telephony.dataconnection.action_fail_bringup --ei counter 2 --ei fail_cause -3
+Tests can also be run individually or by class:
 
-*) Causes all DC's to get torn down, simulating a temporary network outage:
+	atest <testClassName
+	atest <testClassName>#<testMethodName>
 
-  adb shell am broadcast -a com.android.internal.telephony.dataconnection.action_deactivate_all
-
-*) To simplify testing we also have detach and attach simulations below where {x} is gsm, cdma or sip
-
-  adb shell am broadcast -a com.android.internal.telephony.{x}.action_detached
-  adb shell am broadcast -a com.android.internal.telephony.{x}.action_attached
-
-
-== System properties for Testing ==
-
-On debuggable builds (userdebug, eng) you can change additional
-settings through system properties.  These properties can be set with
-"setprop" for the current boot, or added to local.prop to persist
-across boots.
-
-device# setprop key value
-
-device# echo "key=value" >> /data/local.prop
-device# chmod 644 /data/local.prop
-
-
--- Retry configuration --
-
-You can replace the connection retry configuration.  For example, you
-could change it to perform 4 retries at 5 second intervals:
-
-device# setprop test.data_retry_config "5000,5000,5000"
-
-
--- Roaming --
-
-You can force the telephony stack to always assume that it's roaming
-to verify higher-level framework functionality:
-
-device# setprop telephony.test.forceRoaming true
+For more on atest run `atest --help`
diff --git a/src/java/com/android/internal/telephony/dataconnection/README.txt b/src/java/com/android/internal/telephony/dataconnection/README.txt
new file mode 100644
index 0000000000..e613a00a36
--- /dev/null
+++ b/src/java/com/android/internal/telephony/dataconnection/README.txt
@@ -0,0 +1,71 @@
+This package contains classes used to manage a DataConnection.
+
+A criticial aspect of this class is that most objects in this
+package run on the same thread except DataConnectionTracker
+This makes processing efficient as it minimizes context
+switching and it eliminates issues with multi-threading.
+
+This can be done because all actions are either asynchronous
+or are known to be non-blocking and fast. At this time only
+DcTesterDeactivateAll takes specific advantage of this
+single threading knowledge by using Dcc#mDcListAll so be
+very careful when making changes that break this assumption.
+
+A related change was in DataConnectionAc I added code that
+checks to see if the caller is on a different thread. If
+it is then the AsyncChannel#sendMessageSynchronously is
+used. If the caller is on the same thread then a getter
+is used. This allows the DCAC to be used from any thread
+and was required to fix a bug when Dcc called
+PhoneBase#notifyDataConnection which calls DCT#getLinkProperties
+and DCT#getLinkCapabilities which call Dcc all on the same
+thread. Without this change there was a dead lock when
+sendMessageSynchronously blocks.
+
+
+== Testing ==
+
+The following are Intents that can be sent for testing pruproses on
+DEBUGGABLE builds (userdebug, eng)
+
+*) Causes bringUp and retry requests to fail for all DC's
+
+  adb shell am broadcast -a com.android.internal.telephony.dataconnection.action_fail_bringup --ei counter 2 --ei fail_cause -3
+
+*) Causes all DC's to get torn down, simulating a temporary network outage:
+
+  adb shell am broadcast -a com.android.internal.telephony.dataconnection.action_deactivate_all
+
+*) To simplify testing we also have detach and attach simulations below where {x} is gsm, cdma or sip
+
+  adb shell am broadcast -a com.android.internal.telephony.{x}.action_detached
+  adb shell am broadcast -a com.android.internal.telephony.{x}.action_attached
+
+
+== System properties for Testing ==
+
+On debuggable builds (userdebug, eng) you can change additional
+settings through system properties.  These properties can be set with
+"setprop" for the current boot, or added to local.prop to persist
+across boots.
+
+device# setprop key value
+
+device# echo "key=value" >> /data/local.prop
+device# chmod 644 /data/local.prop
+
+
+-- Retry configuration --
+
+You can replace the connection retry configuration.  For example, you
+could change it to perform 4 retries at 5 second intervals:
+
+device# setprop test.data_retry_config "5000,5000,5000"
+
+
+-- Roaming --
+
+You can force the telephony stack to always assume that it's roaming
+to verify higher-level framework functionality:
+
+device# setprop telephony.test.forceRoaming true