The first set of these APIs is for telephony:
Added some APIs to ITelephony and created a first party framework for them
toggleHold()
merge()
mute(boolean mute)
playDtmfTone(char digit, boolean timedShortCode)
stopDtmfTone()
swap()
addListener(ITelephonyListener listener)
removeListener(ITelephonyListener listener)
Bug: 13302451
Change-Id: Iefec5688c26a1b4fe77f5643eba6e1690a057ee6
Added two public APIs under TelephonyManager to return MMS UserAgent and
UAProfUrl strings, for apps that handle SMS/MMS.
Bug: 11054501
Change-Id: Ifa1a64990fa2bf7d0e340d784a9672bf79525338
java.lang.SecurityException: Operation not allowed
There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.
To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.
I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.
Also improve the security exception throw to have a more descriptive
error message.
Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
Since telepony.registry is a real system service notifyNow
parameter doesn't need to be conditional as telephony.registery
will never go away.
This is different from most of the other TelephonyManager
methods which are used to invoke methods on the phone service
which implements ITelephony and is implemented by
PhoneInterfaceManager in the phone application. Since the
phone app is not a system service it can and does go away when
it crashes.
Bug: 9393863
Change-Id: I1a8afc12b0e139e72f05820e49f3d996aec2b52a
For mvno, user can add or edit mvno data field. To pre-provide
the mvno data of the edited apn when the user selects one of
the mvno types, need to support IMSI, SPN, and GID1 data.
To support GID1, make API to retrieve group identifier level1.
bug:6445254
Change-Id: I1bc280054cc7cd37e78a279866cefd62872a19fb
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
- Remove SEND_SMS_NO_CONFIRMATION
- Add SEND_RESPOND_VIA_MESSAGE Permission
This permission is held by the phone and applications that want to
handle respond-via-message should require this permission of the
sender. This permission is signature/system and currently only held
by the Phone app.
Bug: 5108429
Change-Id: Ib611368d488de2f8e1e853f550eb2c654305eda4
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
Add networkId field to NetworkIdentity to identify Wi-Fi networks by
SSID. Add support for policies without usage cycles.
Only apply mobile policies when SIM state is ready, which is cleaner
than just checking for airplane mode. Also avoids creating no-op
default policies when subscriberId is null.
Bug: 3001465, 3291052
Change-Id: I1f8aaa49a5db306df022c402ea7f3f5d4bc0cfc7
To boost accurary and enhance capability of cell location api,
two new APIs, TelephonyManager.getAllCellInfo() and
TelephonyManager.listen(LISTEN_CELL_INFO), are added. Two new
Class, CellInfo and CellIdentity, are created.
This API change returns all information of one cell locaiton
at the same time. It also provides additional LTE and timestamp information.
Change-Id: I4d0f813107e625ec4ac88c8d980ffd171aa5fc30
It may not be called from an app so the app context may not exist.
Check and grab the best one.
Also remove the log that nobody paid attention to if the constructor
is called again from the same process. One context seems to be as
useful as another.
bug:5572369
bug:5622514
Change-Id: Iad23b30c7c8fe5b8d1f81a1e060eaf0cd0e3019d
IMS Module need the MSISDN value for IMS registration.(VZW Requirement)
Change-Id: I8713b6c55788276246ee1c2f91eaf2d3ab8cc813
Signed-off-by: duckyoung.chai <duckyoung.chai@samsung.com>
- Add methods to TelephonyManager to provide access to IMS records on
the ISIM application of the UICC, as well as access to the ISIM
AKA authentication algorithm.
- Add support for the new IMS methods to CDMALTEPhone, using the helper class
ImsUiccRecords to load the IMS records from the ISIM. The same approach
can be used to implement IMS support for UMTS/LTE devices.
- There is a new RIL request, RIL_REQUEST_ISIM_AUTHENTICATION, which is
used to perform IMS AKA authentication using the algorithm on the ISIM
application of the UICC. The challenge nonce and response are both encoded
as Base64 strings.
Change-Id: I73367c7d9bc573d0d883d68adf09891de1319129
Instead of deriving network identity based on raw subsystem broadcasts,
listen for updates from ConnectivityService. Added atomic view of all
active NetworkState, and build map from "iface" to NetworkIdentity set
for stats tracking.
To avoid exposing internal complexity, INetworkStatsService calls use
general templates. Added TelephonyManager mapping to classify network
types using broad labels like "3G" or "4G", used to drive templates.
Cleaned up Objects and Preconditions.
Change-Id: I1d4c1403f0503bc3635a59bb378841ba42239a91
For non-phone device, i.e. tablet doesn't have voice capability,
getDeviceId returns null while getPhoneType returns PHONE_TYPE_NONE.
This behavior is suggested by developer scheme
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
and enforced by CTS testGetDeviceId.
bug:4464907
Change-Id: Iaa3832b7323a50deccd438cb884c8e776a7a9640
It's always possible after services have been registered, so it's just early
in the process that's a problem. Lie correctly in those early cases and fix this
in MR1.
bug:3415254
Change-Id: I95811d1efd676fde01f66b742393d3aa4623482f
The new method getCurrentPhoneType has the old behavior of getPhoneType
and does not check for voice capable. This allows code to assume
the old behavior.
bug: 3198435
Change-Id: I0542838ceca2f757cceb6cd7f795e95fe886523e
