Oh. Well that's just a class inside the phone app implementing part of the UI. It's not going to be made available to apps. You can copy code out of it that works for you.
On Wed, Apr 15, 2009 at 6:42 PM, alexdonnini <[email protected]> wrote: > > Hello, > > Sorry. It's not in frameworks. I found it in > > /android/packages/apps/Settings/src/com/android/settings/ > RadioInfo.java > > At this point, after making a few changes it looks like it may be > working fairly well in spite of lack of access to Phone.java > > In any event, RadioInfo.java provides the kind of detailed phone > related information I am looking to have access and control over. > > Alex Donnini > > On Apr 15, 6:42 pm, Dianne Hackborn <[email protected]> wrote: > > Er, what is "RadioInfo.java". As far as I know there is no such thing in > > the framework. > > > > > > > > On Wed, Apr 15, 2009 at 5:56 AM, alexdonnini <[email protected]> > wrote: > > > > > Hello, > > > > > Thank you both for the constructive response. Through some testing, I > > > have realized that the phone related classes will only work inside the > > > phone process. I have been using TelephonyManager and LocationManager. > > > > > I understand the reasoning behind the current situation. At the same > > > time, I am looking forward to a time when we can use Phone.java > > > > > Thanks for the offer. I have been able to get RadioInfo.java partially > > > working by-passing the need to use Phone.java. An initial high-level > > > answer to your question is that, to start with, I would like to be > > > able to have a fully functional RadioInfo.java. > > > > > Alex Donnini > > > > > On Apr 15, 8:02 am, Mike Lockwood <[email protected]> wrote: > > > > Yes, the LocationManager would be the proper way to get the > > > > information you are asking for. It is the public API for location > > > > services and already handles the IPC and permissions checking > > > > necessary for transferring this information from the phone process to > > > > an application. Unfortunately it currently does not provide the > > > > detailed cell location information you are asking for. > > > > > > We could add the extra cell location information to the Bundle object > > > > returned via the LocationListener.onStatusChanged() callback. If you > > > > could make a proposal of the information that should be included we > > > > could try to add it in a future release. > > > > > > Mike > > > > > > On Wed, Apr 15, 2009 at 12:37 AM, Dianne Hackborn < > [email protected]> > > > wrote: > > > > > A lot of the telephony classes you'll see in the framework will > only > > > work in > > > > > the phone process, because they do not have any IPC abstraction > behind > > > > > them. There is also significant work taking place on them, such as > to > > > > > support CDMA, that we have been fairly conservative about what is > > > exposed to > > > > > avoid having to break APIs. The official APIs you can use are > > > > > TelephonyManager, for for location stuff you generally should be > using > > > > > LocationManager. > > > > > > > On Tue, Apr 14, 2009 at 7:51 PM, alexdonnini < > [email protected]> > > > wrote: > > > > > > >> Hello, > > > > > > >> As I understand it, the Phone.java interface is not available to > > > > >> application developers. This being the case (please confirm), how > can > > > > >> application developers access detailed phone related data such as > > > > >> neighboring CID (refer to the Phone.java code for additional > > > > >> information)? > > > > > > >> Retrieving this kind of information depends on the instantiation > of > > > > >> Phone (e.g. via makeDefaultPhone, or getDefaultPhones. > > > > >> makeDefaultPhone cannot be used without special permission. > > > > > > >> It looks to me like somehow, for reasons I do not quite > understand, it > > > > >> is particularly difficult to access and manage phone location > > > > >> information (e.g. have direct access to the Phone.java interface). > > > > > > >> Why is that? It cannot be a matter of security as testing of a > > > > >> function and development of an application does not automatically > > > > >> translate into publishing and approval of that application. > > > > > > >> I would appreciate anyone's feedback and help on this. > > > > > > >> Thanks. > > > > > > >> Alex Donnini > > > > > > > -- > > > > > Dianne Hackborn > > > > > Android framework engineer > > > > > [email protected] > > > > > > > Note: please don't send private questions to me, as I don't have > time > > > to > > > > > provide private support, and so won't reply to such e-mails. All > such > > > > > questions should be posted on public forums, where I and others can > see > > > and > > > > > answer them. > > > > > > -- > > > > Mike Lockwood > > > > Google android team > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
