History log of /frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
c67761d00a25bd095364e3ff4e4cb8e88b2e974c 13-Oct-2013 David Braun <dabraun@google.com> Make SmsApplication checks more defensive

When SmsApplication::getApplication is called it will check to see if the
configured default SMS app and the phone package have the needed app ops
to work properly. If the call was made from a privilidged caller where
updateIfNeeded == true then the issue will be corrected, if the call was
made from an insecure caller we will return null indicating no default SMS
app which will cause client apps to know that they are not properly set
as the default SMS app. Either way we log an error.

When SmsApplication::setDefaultApplication is called we will ensure that
even if the previous app is no longer enabled or no longer set up as a
valid SMS app, we will still revoke it's OP_WRITE_SMS permission.

Bug: 11071837 Hangouts on KLP lost the WRITE_SMS permission
Change-Id: Ifea39a3d63e4ec3a30a6a1fa5834878dcc9ccfa0
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
33ab7bad1f2ccb5dea26d0def6e43a4f2d1b9cb9 19-Sep-2013 David Braun <dabraun@google.com> Ensure that a default SMS app is configured at boot

Make sure that two things are true on boot so that SMS/MMS will work
properly:
1) We have selected a default SMS/MMS app that will have write permission
to the SMS database
2) The Phone app always has permission to the database because it needs
to write to the raw tables when delivering MMS messages.

Note: If you change the default app explicitly the problems sending SMS
and MMS messages in Messaging will still happen. Preventing this requires
a larger change to prevent Mms from trying to send when it is not the
default app.

Bug: 10819150 Messaging App crashes while sending MMS
Bug: 10837862 Unable to send messages in Messaging app
Change-Id: Ie920e308b9b4067f0bbe1b6b2184c22aaf663065
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
5ceae6074e0729fbbc422db2f263bf7cf453bf1a 29-Aug-2012 Naveen Kalla <nkalla@codeaurora.org> Initialize RIL with the correct CDMA subscription mode setting

Users choice of CDMA Subscription Source is stored in CDMA_SUBSCRIPTION_MODE
setting in database.
If telephony restarts after a crash, use CDMA_SUBSCRIPTION_MODE instead
of PREFERRED_CDMA_SUBSCRIPTION in PhoneFactory to prevent
mismatch with the value in the settings database chosen by the user.

Also, remove the Setting PREFERRED_CDMA_SUBSCRIPTION from the database.
With this change the special treatment for LTE on CDMA will not be needed.
The correct value can be set in the database for CDMA_SUBSCRIPTION_MODE
and that will be taken on power-up by this code.

Change-Id: I11fff596a5fe721c64f192c889672326517dc43d
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
d5fc65e2ca1ed72a936b497681784146449fe20b 06-Aug-2013 Ying Wang <wangying@google.com> Fix build.

Reference:
https://android-review.googlesource.com/#/c/61723/5

Change-Id: I327733be1c2ab3cda933b9f0c7c0a63332223ae8
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
22d85a8e3a575a6d01d2c788587971657dfe20c6 23-Feb-2013 Wink Saville <wink@google.com> Clean up member variables.

Change-Id: Ib60f350131ade626aca682407ea0b4377b16f6c6
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
cbaa45bbf2cab852b6c9c3a887e9f803d4e857ea 23-Feb-2013 Wink Saville <wink@google.com> Clean up

- Add @Overrides where needed.
- Update javadoc comments
- Remove extra semi-colons
- Rename DataConnection.java to DataConnectionBase.java
- Rename GsmDataConnection.java to DataConnection.java
- Add defaults to switch statements
- Remove/fix most "if (false)" statements. Fixed by using a CONSTANT
- Fix hidden variables by hoisting to base class or renaming
- Tweak some debug output

Change-Id: If38de2fdeaacafbf40cdfd7f84dc5c52030ba2a3
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
99c2e1d6749cfad2a8ca94a47857d8c3bfc09454 27-Nov-2012 Wink Saville <wink@google.com> Use Rlog instead of Log.

Change-Id: I2f44193b294513e743526e5c163e7d9a45308b28
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
6ce6af4664de8d12c238f00b1f566db010d52a44 01-Oct-2012 Jeff Sharkey <jsharkey@android.com> Migrate telephony settings to Global.

Bug: 7231764
Change-Id: I2e1c23ed930bb9499c8bca53ac68c38da85085b5
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
e287feac673ff68565b766e0e463d105fa9cef9d 10-Jul-2012 Alex Yakavenka <ayakav@codeaurora.org> Telephony: Remove CdmaLteUicc objects

-Pass IccCard object to GsmMmiCode
-Create IccCardProxy
-Make IccCard an interface and pass instance of IccCardProxy to
external applications (PhoneApp). IccCardProxy will use internal
UiccCard to map Icc requests to current active application on
UiccCard to maintain backwards compatibility for external
applications
-Add documentation to UiccController

The primary advantage of UiccController is that we can work with
multiple uicc applications at the same time. And that is a
requirement for modes like Cdma/Lte. The existing code supports
Cdma/Lte only partially and with guessing on modem side. However,
some things modem can guess, while others - it can't.

For instance, when a user tries to edit the fdn list the current
code will pass ef_id for fdn (0x6F3B). But the modem will have no
clue which fdn list the user wants to edit (csim or usim, both
have path 7FFF), and it's impossible for modem to guess correctly
all the time. All the modem can do is try to be consistent and
hope another device is doing same things. Imagine you bring your
card from another Cdma/Lte device to your new Cdma/Lte device:
if this modem uses different fdn file, it won't work as all
existing entries won't be there.

Another example is when the modem's guess is wrong for files like
csim/ef_li (7FFF 6F3A) versus usim/ef_adn (7FFF 6F3A). They have
same ef_ids so Android really should pass aid of the app it wants
to access. Without aids there is no way modem can know for sure
which file Android wants to read! However, in the current code
even Android doesn't know which aid it wants to read file from
since CdmaLteRecords has only 1 aid.

All of these problems cause more and more hacks, both in the modem
and in Android side. UiccController cleans up current code and
provides framework to work with multiple Uicc applications at the
same time.

Change-Id: I60216887b14140bdf833a8ed579ba16cad932bdc
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java
c38bb60d867c5d61d90b7179a9ed2b2d1848124f 12-Jul-2012 Wink Saville <wink@google.com> Create telephony-common - DO NOT MERGE

telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony

Change-Id: I32cbb5eec1fa239c1587e055c8f7ef4fc48fb62c
/frameworks/opt/telephony/src/java/com/android/internal/telephony/PhoneFactory.java