Low level network information?

Showing 1-93 of 93 messages
Low level network information? Joao MG 10/8/09 5:30 AM
Hi,

I'm interested in fetching low level Radio network information: rxLev,
rxQual, BSIC, BCCH, and other GSM/UMTS network info.

Basic data, such as cellid and location area code is already available
from the SDK API (android.telephony.gsm.GsmCellLocation).

However, detailed Radio network behaviour and information is not
available.

My question: is there a way to fetch this information? Perhaps from
ril / rild?

In order to make add these changes to the Android source code (SDK),
where should I start to look?
- ril / rild (C platform code)
- Telephony (Java / SDK API code)
- Phone and Dialer app's (Java / application code)
Re: Low level network information? Joao MG 10/15/09 3:08 PM
An update on this thread.

After going through parts of the source code:

- Java
com.android.internal.telephony.RIL
com.android.internal.telephony.Phone
com.android.internal.telephony.gsm.GSMPhone
...

- platform / hardware / ril
ril.h
ril.c
reference-ril.c
...

I've found no RIL command (solicited or unsolicited) that returns low-
level Radio network information (the reference, open source,
implementation).

However this is somehow possible in HTC's RIL implementation (I
understand it's closed, proprietary, source).

HTC's FieldTest app (com.htc.fieldtest) presents detailed Radio
network info. The kind I'm interested in making available through the
framework.
http://phoneftd.blogspot.com/2009/03/google-g1-phone-field-test.html

Any thoughts on how to implement this?

A futher request: can anyone execute the FieldTest app and post the
logcat -b radio output?

JMG


On Oct 8, 1:30 pm, joao <joa...@gmail.com> wrote:
> Hi,
>
> I'm interested in fetching low level Radionetworkinformation: rxLev,
> rxQual, BSIC, BCCH, and other GSM/UMTSnetworkinfo.
>
> Basic data, such as cellid and location area code is already available
> from the SDK API (android.telephony.gsm.GsmCellLocation).
>
> However, detailed Radionetworkbehaviour and information is not
Re: Low level network information? Roman ( T-Mobile USA) 10/19/09 5:04 PM
Have you checked out which AT commands could be used to ask for low
level information. Of course you would have to find out which AT
commands are supported on the Baseband for radio related information.
You should be able to follow the pattern how currently AT commands are
passed down to the baseband.

--
Roman Baumgaertner
Sr. SW Engineer-OSDC
·T· · ·Mobile· stick together
The views, opinions and statements in this email are those of the
author solely in their individual capacity, and do not necessarily
represent those of T-Mobile USA, Inc.

On Oct 15, 3:08 pm, joao <joa...@gmail.com> wrote:
> An update on this thread.
>
> After going through parts of the source code:
>
> - Java
> com.android.internal.telephony.RIL
> com.android.internal.telephony.Phone
> com.android.internal.telephony.gsm.GSMPhone
> ...
>
> - platform / hardware / ril
> ril.h
> ril.c
> reference-ril.c
> ...
>
> I've found no RIL command (solicited or unsolicited) that returns low-
> level Radio network information (the reference, open source,
> implementation).
>
> However this is somehow possible in HTC's RIL implementation (I
> understand it's closed, proprietary, source).
>
> HTC's FieldTest app (com.htc.fieldtest) presents detailed Radio
> network info. The kind I'm interested in making available through the
> framework.http://phoneftd.blogspot.com/2009/03/google-g1-phone-field-test.html
Re: Low level network information? Joao MG 10/20/09 6:36 AM
The +CPOS/CPOSR commands can return radio related information (using
the assist_data parameter/event).

This command was introduced to the 3GPP 27.007 specs in version 8.60
(December 2008):
http://www.3gpp.org/ftp/Specs/archive/27_series/27.007/27007-860.zip

In my previous post I asked for radio logcat output in the ADP1 phone
while running the FieldTest app.

This log should tell what type of commands HTC's ADP1 phone uses to
fetch the radio information from the baseband. It could be the CPOS
command, or other proprietary, Qualcomm method.

If anyone, owner of a ADP1 phone, could please take the time to check
this.. it would be extremely helpful to this discussion.

Joao MG

On Oct 20, 1:04 am, "Roman ( T-Mobile USA)" <roman.baumgaert...@t-
> > I've found noRILcommand (solicited or unsolicited) that returns low-
> > level Radio network information (the reference, open source,
> > implementation).
>
> > However this is somehow possible in HTC'sRILimplementation (I
> > understand it's closed, proprietary, source).
>
> > HTC's FieldTest app (com.htc.fieldtest) presents detailed Radio
> > network info. The kind I'm interested in making available through the
> > framework.http://phoneftd.blogspot.com/2009/03/google-g1-phone-field-test.html
>
> > Any thoughts on how to implement this?
>
> > A futher request: can anyone execute the FieldTest app and post the
> > logcat -b radio output?
>
> > JMG
>
> > On Oct 8, 1:30 pm, joao <joa...@gmail.com> wrote:
>
> > > Hi,
>
> > > I'm interested in fetching low level Radionetworkinformation: rxLev,
> > > rxQual, BSIC, BCCH, and other GSM/UMTSnetworkinfo.
>
> > > Basic data, such as cellid and location area code is already available
> > > from the SDK API (android.telephony.gsm.GsmCellLocation).
>
> > > However, detailed Radionetworkbehaviour and information is not
> > > available.
>
> > > My question: is there a way to fetch this information? Perhaps from
> > >ril/ rild?
>
> > > In order to make add these changes to the Android source code (SDK),
> > > where should I start to look?
> > > -ril/ rild (C platform code)
Re: Low level network information? Miguel Paraz 10/20/09 8:25 PM
Hi,
Here is the output of logcat for the FieldTest app, when trying the
different functions. Looks like it doesn't say much:

D/RILJ    (  142): [0076]> OEM_HOOK_RAW
[0000000008000000010000005f000000]
D/RILJ    (  142): [0076]< OEM_HOOK_RAW [B@437db138
D/RILJ    (  142): [0077]> OEM_HOOK_RAW[0100000000000000]
D/RILJ    (  142): [0077]< OEM_HOOK_RAW [B@437dbc68
D/RILJ    (  142): [0078]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0078]< OEM_HOOK_RAW [B@4377b7a0
D/RILJ    (  142): [0079]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0079]< OEM_HOOK_RAW [B@437adc28
D/RILJ    (  142): [0080]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0080]< OEM_HOOK_RAW [B@437b4c88
D/RILJ    (  142): [0081]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0081]< OEM_HOOK_RAW [B@437bc6b0
D/RILJ    (  142): [0082]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0082]< OEM_HOOK_RAW [B@437984f0
D/RILJ    (  142): [0083]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0083]< OEM_HOOK_RAW [B@43814880
D/RILJ    (  142): [0084]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0084]< OEM_HOOK_RAW [B@438202f0
D/RILJ    (  142): [0085]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0085]< OEM_HOOK_RAW [B@4382c300
D/RILJ    (  142): [0086]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0086]< OEM_HOOK_RAW [B@43837d70
D/RILJ    (  142): [0087]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0087]< OEM_HOOK_RAW [B@438437e0
D/RILJ    (  142): [0088]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  142): [0088]< OEM_HOOK_RAW [B@43760468
D/RILJ    (  142): [0089]> OEM_HOOK_RAW
[0000000008000000000000005f000000]
D/RILJ    (  142): [0089]< OEM_HOOK_RAW [B@43788300
D/RILJ    (  142): [0090]> OEM_HOOK_RAW
[0000000008000000010000005f000000]
D/RILJ    (  142): [0090]< OEM_HOOK_RAW [B@437da6c0
D/RILJ    (  142): [0091]> OEM_HOOK_RAW[0100000000000000]
D/RILJ    (  142): [0091]< OEM_HOOK_RAW [B@4376ec98
D/RILJ    (  142): [0092]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0092]< OEM_HOOK_RAW [B@43809280
D/RILJ    (  142): [0093]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0093]< OEM_HOOK_RAW [B@4381c370
D/RILJ    (  142): [0094]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0094]< OEM_HOOK_RAW [B@4382a4a0
D/RILJ    (  142): [0095]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0095]< OEM_HOOK_RAW [B@43830888
D/RILJ    (  142): [0096]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0096]< OEM_HOOK_RAW [B@437e55f0
D/RILJ    (  142): [0097]> OEM_HOOK_RAW
[0000000008000000000000005f000000]
D/RILJ    (  142): [0097]< OEM_HOOK_RAW [B@437b7a88
D/RILJ    (  142): [0098]> OEM_HOOK_RAW
[0000000008000000010000005f000000]
D/RILJ    (  142): [0098]< OEM_HOOK_RAW [B@43807980
D/RILJ    (  142): [0099]> OEM_HOOK_RAW[0100000000000000]
D/RILJ    (  142): [0099]< OEM_HOOK_RAW [B@43839240
D/RILJ    (  142): [0100]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0100]< OEM_HOOK_RAW [B@4383bf40
D/RILJ    (  142): [0101]> OEM_HOOK_RAW
[0000000008000000000000005f000000]
D/RILJ    (  142): [0101]< OEM_HOOK_RAW [B@43839860
D/RILJ    (  142): [0102]> OEM_HOOK_RAW
[0000000008000000010000005f000000]
D/RILJ    (  142): [0102]< OEM_HOOK_RAW [B@437e82f0
D/RILJ    (  142): [0103]> OEM_HOOK_RAW[0100000000000000]
D/RILJ    (  142): [0103]< OEM_HOOK_RAW [B@437fde48
D/RILJ    (  142): [0104]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0104]< OEM_HOOK_RAW [B@437f20f8
D/RILJ    (  142): [0105]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0105]< OEM_HOOK_RAW [B@43824bb8
D/RILJ    (  142): [0106]> OEM_HOOK_RAW[0300000000000000]
D/RILJ    (  142): [0106]< OEM_HOOK_RAW [B@4385ddf8
D/RILJ    (  142): [0107]> OEM_HOOK_RAW[0400000000000000]
D/RILJ    (  142): [0107]< OEM_HOOK_RAW [B@437fecb0
D/RILJ    (  142): [0108]> OEM_HOOK_RAW[0400000000000000]
D/RILJ    (  142): [0108]< OEM_HOOK_RAW [B@437d77e0
D/RILJ    (  142): [0109]> OEM_HOOK_RAW[0400000000000000]
D/RILJ    (  142): [0109]< OEM_HOOK_RAW [B@437d44e8
D/RILJ    (  142): [0110]> OEM_HOOK_RAW[0400000000000000]
D/RILJ    (  142): [0110]< OEM_HOOK_RAW [B@437ccd90
D/RILJ    (  142): [0111]> OEM_HOOK_RAW[1b00000000000000]
D/RILJ    (  142): [0111]< OEM_HOOK_RAW [B@437c10c8
D/RILJ    (  142): [0112]> OEM_HOOK_RAW[1b00000000000000]
D/RILJ    (  142): [0112]< OEM_HOOK_RAW [B@437b94d8
D/RILJ    (  142): [0113]> OEM_HOOK_RAW[1b00000000000000]
D/RILJ    (  142): [0113]< OEM_HOOK_RAW [B@437b5078
D/RILJ    (  142): [0114]> OEM_HOOK_RAW[1b00000000000000]
D/RILJ    (  142): [0114]< OEM_HOOK_RAW [B@4385e270
D/RILJ    (  142): [0115]> OEM_HOOK_RAW[1b00000000000000]
D/RILJ    (  142): [0115]< OEM_HOOK_RAW [B@43816588


Re: Low level network information? Joao MG 10/21/09 1:28 AM
Thank you Miguel, it does provides some ligth on this matter.

The output is from RIl.java, in package
com.android.internal.telephony.gsm (the RILJ log tag).

The method is invokeOemRilRequestRaw, using the
RIL_REQUEST_OEM_HOOK_RAW solicited command.

There's no log output from HTC's ril implementation (rild, etc),
probably it's switched off at build time.

In ril.h file, RIL_REQUEST_OEM_HOOK_RAW has the following note:

"This request reserved for OEM-specific uses. It passes raw byte
arrays * back and forth."

regards,

Joao MG
Re: Low level network information? Joao MG 10/27/09 4:20 PM
(warning long post)

After further analysis of the logcat output, we can identify two
message types:
- request to ril: "> OEM_HOOK_RAW"
- response from ril: "< OEM_HOOK_RAW"

The request is sent from invokeOemRilRequestRaw method and registered
in the log by:
if (RILJ_LOGD) riljLog(rr.serialString() + "> " + requestToString
(rr.mRequest) + "[" + SimUtils.bytesToHexString(data) + "]");

So, the byte arrays passed over to the ril are written to the log as a
hexadecimal string.

From the log we can identify 7 different hex request strings
(different order in the log):
0000000008000000010000005f000000
0000000008000000000000005f000000
0100000000000000
0200000000000000
0300000000000000
0400000000000000
1b00000000000000

We can decode the hex string back to a byte[] using a simple function
(a kind of bytesToHexString reverse);
public static byte[] hexStringToBytes(String hex) {
   byte[] bts = new byte[hex.length() / 2];
   for (int i = 0; i < bts.length; i++) {
      bts[i] = (byte) Integer.parseInt(hex.substring(2*i, 2*i+2), 16);
   }
   return bts;
}

This code was taken from http://forums.sun.com/thread.jspa?threadID=546486.

The resulting byte array can be parsed to different raw types (short,
int, long). No way to tell the correct, used by HTC FieldTest app.

Taking 0100000000000000 as an example, each byte is represented by two
hex char:
03 00 00 00 00 00 00 00

Assuming this represents a byte array:
System.out.println(Byte.parseByte("01", 16));
System.out.println(Byte.parseByte("00", 16));
System.out.println(Byte.parseByte("00", 16));
System.out.println(Byte.parseByte("00", 16));
System.out.println(Byte.parseByte("00", 16));
System.out.println(Byte.parseByte("00", 16));
System.out.println(Byte.parseByte("00", 16));
System.out.println(Byte.parseByte("00", 16));
Output: 1,0,0,0,0,0,0,0

Or, assuming it's a int array:
System.out.print(Short.parseShort("0100", 16));
System.out.print("," + Short.parseShort("0000", 16));
System.out.print("," + Short.parseShort("0000", 16));
System.out.println("," + Short.parseShort("0000", 16));
Output: 256,0,0,0

No way to tell. Please correct if I'm mistaken.

The good news is that it doesn't matter, so long as we can duplicate
the byte array, we can send the command over to the ril and expect a
response.

These different byte arrays could represent queries for different type
of information: GSM, GSM Neighbouring Cells, etc (all the options
found in HTC's FieldTest).

Now, for the response log messages.

The log output for the response comes from processSolicited method,
also in RIL.java.

The [B@437dbc68, and similar values found in the log, are produced by
line (in retToString method, called from processSolicited):
s = ret.toString();

The actual value returned by ril is handled by the method responseRaw,
and returns a byte[]. Unfortunately, retToString doesn't handle byte[]
in any special way.

So the next step must be modifying retToString in order to translate
the byte[] to a hex string;

This would give us the hexadecimal representation of the ril response
to the various RIL_REQUEST_OEM_HOOK_RAW requests. I'm hopping to
decode this to meaningful data using FieldTest specific options along
with the logcat ouput.

This would only work on a adp1, running HTC's FieldTest on a modified
RIL.java.

Can anyone please validate this analysis and the proposed course of
action.

Joao MG
Re: Low level network information? Master_Ne0 10/30/09 2:27 AM
Hi,

You seem to be on the right track, but why do you need this
information? There may be a simpler way of achieving your goal.

Ne0
> This code was taken fromhttp://forums.sun.com/thread.jspa?threadID=546486.
Re: Low level network information? Joao MG 10/30/09 7:12 AM
Hello,

This information is useful to characterize the radio environment.

You'll find more in this development issue: http://code.google.com/p/android/issues/detail?id=700

I've pursued HTC's FieldTest because I've found no other significant
methods in the API's (Java framework and reference ril).

Since each vendor's ril implementation is closed source, it's
difficult to find out specific ril requests that could return this
information.

Also, there's no publicly available documentation of each vendor's ril
(HTC, Motorola, etc).

If you have some suggestion... please let me know!

regards,

Joao

On Oct 30, 9:27 am, Master_Ne0 <master.ne0s.soluti...@googlemail.com>
wrote:
> ...
>
> read more »
Re: Low level network information? Master_Ne0 10/30/09 8:03 AM
Issue 700 is way down on the priority list!!

Apologies if this going over what you have already discovered, but the
OEM_HOOK_RAW message comes from the GSMPhone invoking raw ril
requests. The message requests a response from the OEM RIL, this
response message has an ecoded response, i see you have managed to
catch the outgoing OEM RIL request message, have you managed catch a
message in response to it?

I have a lot of experience with the Android RIL and will help you
where i can, but i still a little confused why you would want an app
to be able to read this data?

NeO
> ...
>
> read more »
Re: Low level network information? Joao MG 10/30/09 8:45 AM
Eheh, I know it's way down.. I'm trying to work on it.

And no, I haven't captured a response, I don't have a adp1 phone. The
radio logcat was posted by Miguel Paraz.

This data is useful to better understand the radio network behaviour,
there are a couple of possible scenarios:

- Android mobile users -> to send network bug reports to their telco
provider (complaining about mobile coverage, bad quality, slow upload/
download speed, etc);
- OEM manufacturers -> receiving this data from users to debug and
optimize the radio chipset;
- Telco operators -> receiving this data from their customers and
improve the network;

Basically this information gives an idea of the radio network quality.

With this data, one could build an app to report problems in the
network (a similar concept to FireFox Talkback http://kb.mozillazine.org/Talkback).

regards,

Joao MG

On Oct 30, 3:03 pm, Master_Ne0 <master.ne0s.soluti...@googlemail.com>
wrote:
> ...
>
> read more »
Re: Low level network information? Joao MG 11/1/09 10:55 AM
Back to technical stuff.

When trying to know more about the OEM_HOOK_RAW request, I've come
across debugCallback function in ril.cpp (libril):

        ...
        unsigned int qxdm_data[6];
        ...
        case 3:
            LOGI ("Debug port: QXDM log enable.");
            qxdm_data[0] = 65536;
            qxdm_data[1] = 16;
            qxdm_data[2] = 1;
            qxdm_data[3] = 32;
            qxdm_data[4] = 0;
            qxdm_data[4] = 8;
            issueLocalRequest(RIL_REQUEST_OEM_HOOK_RAW, qxdm_data,
                              6 * sizeof(int));
            break;
        case 4:
            LOGI ("Debug port: QXDM log disable.");
            qxdm_data[0] = 65536;
            qxdm_data[1] = 16;
            qxdm_data[2] = 0;
            qxdm_data[3] = 32;
            qxdm_data[4] = 0;
            qxdm_data[4] = 8;
            issueLocalRequest(RIL_REQUEST_OEM_HOOK_RAW, qxdm_data,
                              6 * sizeof(int));
            break;
            ...

This function is being used from radiooptions.c, in rild (in source
hardware/ril/rild).

It's an example of sending a unsigned int array to the ril/baseband
using RIL_REQUEST_OEM_HOOK_RAW.

Interestingly, between the disable and enable requests, the only
difference is the third int: 0 or 1.

As a side note, these lines don't seem right:
            qxdm_data[4] = 0;
            qxdm_data[4] = 8;

Probably should be:
            qxdm_data[4] = 0;
            qxdm_data[5] = 8;

There are some similar examples in Java, check out
com.android.settings.RadioInfo.java.

In this class the getQxdmSdlogData method packs int parameters into a
byte array. The returning byte array is latter used in
invokeOemRilRequestRaw to enable/disable QXDM logging.

Btw, QXDM stands for Qualcomm eXtensible Diagnostic Monitor.

Joao MG


On Oct 30, 3:45 pm, Joao MG <joa...@gmail.com> wrote:
> Eheh, I know it's way down.. I'm trying to work on it.
>
> And no, I haven't captured a response, I don't have a adp1 phone. The
> radio logcat was posted by Miguel Paraz.
>
> This data is useful to better understand the radio network behaviour,
> there are a couple of possible scenarios:
>
> - Android mobile users -> to send network bug reports to their telco
> provider (complaining about mobile coverage, bad quality, slow upload/
> download speed, etc);
> - OEM manufacturers -> receiving this data from users to debug and
> optimize the radio chipset;
> - Telco operators -> receiving this data from their customers and
> improve the network;
>
> Basically this information gives an idea of the radio network quality.
>
> With this data, one could build an app to report problems in the
> network (a similar concept to FireFox Talkbackhttp://kb.mozillazine.org/Talkback).
> ...
>
> read more »
Re: Low level network information? chrisnew 11/9/09 5:52 AM
The raw requests from 0x0200000000000000 to 0x1b00000000000000 map to
the pages of data in the Field Test app. For example, the first page
contains the GSM data which is in the screenshot link elsewhere in
this thread. HTC appear to have compiled the data responses into the
radio firmware as a chunk of data for each page.

> 0200000000000000 = GSM page data
> 0300000000000000 = GPRS / E-GPRS page data
> 0400000000000000 = AMR page data
...
> 1b00000000000000 = 3G Dnlink Transport Format Comb. page data

I've just realised that there should be a few more pages of data
rather than the 21 displayed so maybe there are a few hidden ones.

0x0100000000000000 is just the index page which doesn't display any
data. 0x0000000008000000010000005f000000 is possibly for
initialization.

chris


On Oct 27, 11:20 pm, Joao MG <joa...@gmail.com> wrote:
> This code was taken fromhttp://forums.sun.com/thread.jspa?threadID=546486.
Re: Low level network information? Joao MG 11/9/09 6:57 AM
That's great information! Thank's.

I'll be getting my hands on a ADP1 in 1-2 weeks.. can't wait to try
this requests!

Joao MG
> ...
>
> read more »
Re: Low level network information? Master_Ne0 11/27/09 2:20 AM
Have managed to get anywhere with this Joao?

Ne0
> ...
>
> read more »
Re: Low level network information? Joao MG 11/29/09 3:03 AM
No, I haven't had time to try any approach.. perhaps in a couple of
weeks.

As soon as I have something new, I'll post it in this thread.

Joao MG

On Nov 27, 10:20 am, Master_Ne0 <master.ne0s.soluti...@googlemail.com>
wrote:
> ...
>
> read more »
Re: Low level network information? lizi 12/10/09 9:35 AM
hi,jiao

any progress on this thread, i also has the same needs with you get
the phsical layer information, look forward to your result

Thanks!
lizi
> ...
>
> read more »
Re: Low level network information? Ricardo Silva @ Lyncode 12/12/09 5:50 AM
Hi all,

I need too that information :P

Looks like many people need this

Regards,
Ricardo Silva
> > > > > > - response fromril: "< OEM_HOOK_RAW"
>
> > > > > > The request is sent from invokeOemRilRequestRaw method and registered
> > > > > > in the log by:
> > > > > > if (RILJ_LOGD) riljLog(rr.serialString() + "> " + requestToString
> > > > > > (rr.mRequest) + "[" + SimUtils.bytesToHexString(data) + "]");
>
> > > > > > So, the byte arrays passed over to therilare written to the log as a
> > > > > > the byte array, we can send the command over to theriland expect a
> > > > > > response.
>
> > > > > > These different byte arrays could represent queries for different type
> > > > > > of information: GSM, GSM Neighbouring Cells, etc (all the options
> > > > > > found in HTC's FieldTest).
>
> > > > > > Now, for the response log messages.
>
> > > > > > The log output for the response comes from processSolicited method,
> > > > > > also inRIL.java.
>
> > > > > > The [B@437dbc68, and similar values found in the log, are produced by
> > > > > > line (in retToString method, called from processSolicited):
> > > > > > s = ret.toString();
>
> > > > > > The actual value returned byrilis handled by the method responseRaw,
> > > > > > and returns a byte[]. Unfortunately, retToString doesn't handle byte[]
> > > > > > in any special way.
>
> > > > > > So the next step must be modifying retToString in order to translate
> > > > > > the byte[] to a hex string;
>
> > > > > > This would give us the hexadecimal representation of therilresponse
> > > > > > to the various RIL_REQUEST_OEM_HOOK_RAW requests. I'm hopping to
> > > > > > decode this to meaningful data using FieldTest specific options along
> > > > > > with the logcat ouput.
>
> > > > > > This would only work on a adp1, running HTC's FieldTest on a modified
> > > > > >RIL.java.
>
> > > > > > Can anyone please validate this analysis and the proposed course of
> > > > > > action.
>
> > > > > > Joao MG
>
> > > > > > On Oct 21, 8:28 am, joao <joa...@gmail.com> wrote:
>
> > > > > > > Thank you Miguel, it does provides some ligth on this matter.
>
> > > > > > > The output is fromRIl.java, in package
> > > > > > > com.android.internal.telephony.gsm (the RILJ log tag).
>
> > > > > > > The method is invokeOemRilRequestRaw, using the
> > > > > > > RIL_REQUEST_OEM_HOOK_RAW solicited command.
>
> > > > > > > There's no log output from HTC'srilimplementation (rild, etc),
> > > > > > > probably it's switched off at build time.
>
> > > > > > > Inril.h file, RIL_REQUEST_OEM_HOOK_RAW has the following note:
> ...
>
> read more »
Re: Low level network information? Ricardo Silva @ Lyncode 12/21/09 11:08 AM
Hi again,

Is possible to include the RIL shared library (libril.so) from system/
lib?

And then call the functions directly from code? Such this function:
static void issueLocalRequest(int request, void *data, int len) (from
RIL.cpp)

Regards

> ...
>
> read more »

Re: Low level network information? Master_Ne0 12/22/09 2:44 AM
Ricardo,

I'm not 100% clear on what you are trying to do, though if you are
trying to call RIL functions you should look at RIL.java. There is a
Sender and Receiver socket that is the interface between the kernal
and Android (thats my understanding anyway!). The only functions that
can be called in RIL.cpp, are called using this inteface. However it
will not give you any more network info then that available from the
SDK telephony manager, if you want more network info you have to be
able to invoke the OEM raw ril requests as described above, then you
have to decode the response.

These requests and responses will be dependent on the phone, there is
no open source standard for the low level network info yet. As for htc
(Dream anyway), libhtc_ril.so is their radio interface. If you have
any joy decoding OEM responses please post it here.

Ne0

> ...
>
> read more »

Re: Low level network information? Ricardo Silva @ Lyncode 1/11/10 1:56 AM
I want to, for example, turn off the radio interface or change the
cell. I dont know how to decode the OEM responses.

How I use the RIL.java? because is not included in the SDK.

Other thing, I cant communicate with the rild, because the sockets
only accepts one connection and only from the RIL.java. I tried the
rild-debug but when I turn off the radio interface through there, cant
turn on again (the telephony services stops).

It´s possible to replace the libril.so for a libril.so modified and
compiled by me?

On Dec 22 2009, 10:44 am, Master_Ne0


<master.ne0s.soluti...@googlemail.com> wrote:
> Ricardo,
>
> I'm not 100% clear on what you are trying to do, though if you are
> trying to callRILfunctions you should look atRIL.java. There is a

> Sender and Receiver socket that is the interface between the kernal
> and Android (thats my understanding anyway!). The only functions that
> can be called inRIL.cpp, are called using this inteface. However it

> will not give you any more network info then that available from the
> SDK telephony manager, if you want more network info you have to be
> able to invoke the OEM rawrilrequests as described above, then you

> have to decode the response.
>
> These requests and responses will be dependent on the phone, there is
> no open source standard for the low level network info yet. As for htc
> (Dream anyway), libhtc_ril.so is their radio interface. If you have
> any joy decoding OEM responses please post it here.
>
> Ne0
>
> On Dec 21, 7:08 pm, Ricardo Silva <ban...@gmail.com> wrote:
>
> > Hi again,
>
> > Is possible to include theRILshared library (libril.so) from system/> ...
>
> read more »

unk...@googlegroups.com 2/5/10 6:44 AM <This message has been deleted.>
Re: Low level network information? Liam Alford 2/5/10 12:10 PM

Its not open source. Its a htc application.

On 5 Feb 2010 15:45, "mobot" <mark...@gmail.com> wrote:

Has anyone located  the Field Test in the source? Please let me know.


On Jan 11, 4:56 am, Ricardo Silva <ban...@gmail.com> wrote:
> I want to, for example, turn off the ...

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
...

unk...@googlegroups.com 2/5/10 1:02 PM <This message has been deleted.>
Re: Low level network information? Ne0 2/8/10 1:03 AM
This thread was dedicated to doing so, but it appears to have gone quiet. What info are you after?

On Fri, Feb 5, 2010 at 9:02 PM, Mark Sebik <mark...@gmail.com> wrote:
Oh. Thanks. Any luck getting at this info in other ways?

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

unk...@googlegroups.com 2/8/10 7:36 AM <This message has been deleted.>
Re: Low level network information? Ne0 2/8/10 8:20 AM
Well just in case you havent already found it, dial *#*#4636#*#* and look at RadioInfo.java from the source. Will get you some of the info you need.

What phone are you using? ##data# (##3282#) ##debug#(##33284#) dont seem to do anything on my Magic and Dream.

On Mon, Feb 8, 2010 at 3:36 PM, Mark Sebik <mark...@gmail.com> wrote:
It seems so. I'm looking for neighbor cells, rssi, ip address, etc.. Basically looking to present the current cellular landscape in an app. The same data HTC's field test app uses would be great.
Check these programs:

##data# (##3282#)
##debug#(##33284#)

So there is a way to get to the data, I just haven't figured it out yet.

unk...@googlegroups.com 2/8/10 8:53 AM <This message has been deleted.>
Re: Low level network information? Joao MG 2/22/10 7:38 AM
( very long post)

After a long interval, back to Android RIL.

I've managed to fetch and parse a GSM Page request from the ril.

Using invokeOemRilRequestRaw method in
com.android.internal.telephony.Phone.

The approach was:

1. retrieve sample raw responses from logcat -b radio

This was done by a small change the method retToString in RIL.java:

} else if (ret instanceof byte[]) {
    byte[] bytes = (byte[]) ret;
    s = IccUtils.bytesToHexString(bytes);

This way the invokeOemRilRequestRaw raw bytes response is written to
the log (converted to an hex string).

2. After reading the log, parse the GSM Page response:

D/RILJ    (  141): [0168]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  141): [0168]< OEM_HOOK_RAW
000000003030303200000000000000000000000000000000326400000000000000000000000000000000000032363830310000000000000000000000000000001100000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d3939000000000000000000000000000000110000000000000032363830310000000000000000000000000000003538643763626235000000000000000000000000fa050000ff000000ff0000003000000000000000000000000000000000000000ff000000

So the first line is the GSM Page request, the second is the byte
response (both byte arrays converted to hex strings).

So, now we can parse this into meaningful information using:

ByteBuffer bb = ByteBuffer.wrap(bytes);
bb.order(ByteOrder.LITTLE_ENDIAN);

System.out.println("ARFCN: " + bb.getInt());
System.out.println("LAC: " + getStringFromBytes(bb, 20));
System.out.println("RAC: " + getStringFromBytes(bb, 20));
System.out.println("MNC/MCC:" + getStringFromBytes(bb, 20));
System.out.println("RSSI:" + bb.getInt());
System.out.println("Ncell Info1:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info2:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info3:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info6:" + getStringFromBytes(bb, 20));
System.out.println("RX Quality:" + bb.getInt());
System.out.println("Frequent Hopping:" + bb.getInt());
System.out.println("Last registered network:" + getStringFromBytes(bb,
20));
System.out.println("TMSI:" + getStringFromBytes(bb, 20));
System.out.println("Periodic Location Update Value:" + bb.getInt());
System.out.println("BAND:" + bb.getInt());
System.out.println("Channel In USe:" + bb.getInt());
System.out.println("RSSI 1:" + getStringFromBytes(bb, 20));
System.out.println("Last cell release cause:" + bb.getInt());

The getStringFromBytes method:

private static String getStringFromBytes(ByteBuffer buffer, int
length)
{
   byte[] bytes = new byte[length];
   buffer.get(bytes, buffer.arrayOffset(), 20);
   return new String(bytes);
}

Fortunately HTC FieldTest displays the fields in the exact same order
as their appear in the raw byte response.

The output is something like:

ARFCN: 0
LAC: 0002
RAC: 2d
MNC/MCC:26801
RSSI:17
Ncell Info1:0 -99
Ncell Info2:0 -99
Ncell Info3:0 -99
Ncell Info4:0 -99
Ncell Info4:0 -99
Ncell Info6:0 -99
RX Quality:17
Frequent Hopping:0
Last registered network:26801
TMSI:58d7cbb5
Periodic Location Update Value:1530
BAND:255
Channel In Use:255
RSSI 1:0
Last cell release cause:255

3. Now, to actually execute invokeOemRilRequestRaw

This was accomplished by changing RadioInfo.java (in
com.android.settings, the Settings apps).

I've found no other way to access the Phone. I've tried developing a
new app,
but failed to get a reference to the phone. The following method
fails:

phone = PhoneFactory.getDefaultPhone();

It returns: "PhoneFactory.makeDefaultPhones must be called from Looper
thread".

HTC FieldTest somehow manages to do it, probably because it runs as
system (it shares user id with com.android.phone,
using the sharedUserId attribute in the manifest).

Either way, I've added a bit of code to RadioInfo.java:

byte[] init1;
byte[] init2;
byte[] gsm_page;
byte[] finish;

init1 = hexStringToBytes("0000000008000000010000005f000000");
init2 = hexStringToBytes("0100000000000000");
gsm_page = hexStringToBytes("0200000000000000");
finish = hexStringToBytes("0000000008000000000000005f000000");

phone.invokeOemRilRequestRaw(init1,
mHandler.obtainMessage(EVENT_RAW));
phone.invokeOemRilRequestRaw(init2,
mHandler.obtainMessage(EVENT_RAW));
phone.invokeOemRilRequestRaw(gsm_page,
mHandler.obtainMessage(EVENT_RAW_GSM_PAGE));
phone.invokeOemRilRequestRaw(finish,
mHandler.obtainMessage(EVENT_RAW));

And also changed the mHandler:

case EVENT_RAW:
    ar= (AsyncResult) msg.obj;
    if (ar.exception == null) {
    byte[] bytes = (byte[]) ar.result;
    updateRaw(bytes);
    } else {
    mNeighboringCids.setText("unknown");
    }
    break;
case EVENT_RAW_GSM_PAGE:
    ar= (AsyncResult) msg.obj;
    if (ar.exception == null) {
    byte[] bytes = (byte[]) ar.result;
    updateRawGsmPage(bytes);
    } else {
    mNeighboringCids.setText("unknown");
    }
    break;

And added the methods:

private final void updateRaw(byte[] bytes) {
    mNeighboringCids.append("\n" + bytesToHexString(bytes));
}

private final void updateRawGsmPage(byte[] bytes) {
    ByteBuffer bb = ByteBuffer.wrap(bytes);
    bb.order(ByteOrder.LITTLE_ENDIAN);

    mNeighboringCids.append("\nARFCN: " + bb.getInt());
    mNeighboringCids.append("\nLAC: " + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nRAC: " + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nMNC/MCC:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nRSSI:" + bb.getInt());
    mNeighboringCids.append("\nNcell Info1:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info2:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info3:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info4:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info4:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info6:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nRX Quality:" + bb.getInt());
    mNeighboringCids.append("\nFrequent Hopping:" + bb.getInt());
    mNeighboringCids.append("\nLast registered network:" +
getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nTMSI:" + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nPeriodic Location Update Value:" +
bb.getInt());
    mNeighboringCids.append("\nBAND:" + bb.getInt());
    mNeighboringCids.append("\nChannel In USe:" + bb.getInt());
    mNeighboringCids.append("\nRSSI 1:" + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nLast cell release cause:" +
bb.getInt());
}

So when I execute Settings (by calling *#*#4636#*#*) and go to Phone
Information I get, in the mNeighboringCids text field, the GSM Page
data.

I've checked the execution with "logcat -b radio", it's the same as
FieldTest.

Knowing that this works, we can consider changes to the Telephony API
(android.telephony).

The idea is to make this information available, through the framework,
to all apps.

Joao MG

On Feb 8, 9:03 am, Liam Alford <liamjamesalf...@googlemail.com> wrote:
> This thread was dedicated to doing so, but it appears to have gone quiet.
> What info are you after?
>
> On Fri, Feb 5, 2010 at 9:02 PM, Mark Sebik <markse...@gmail.com> wrote:
> > Oh. Thanks. Any luck getting at this info in other ways?
>
> > On Fri, Feb 5, 2010 at 3:10 PM, Liam Alford <l...@smithmyers.com> wrote:
>
> >> Its not open source. Its a htc application.
>
> >> On 5 Feb 2010 15:45, "mobot" <markse...@gmail.com> wrote:
>
> >> Has anyone located  the Field Test in the source? Please let me know.
>
> >> On Jan 11, 4:56 am, Ricardo Silva <ban...@gmail.com> wrote:
> >> > I want to, for example, turn off the ...
> >> --
>
> >> You received this message because you are subscribed to the Google Groups
> >> "android-platform" group.
> >> ...
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "android-platform" group.
> >> To post to this group, send email to android-...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> android-platfo...@googlegroups.com<android-platform%2Bunsubscribe@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/android-platform?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com<android-platform%2Bunsubscribe@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
>

Re: Low level network information? Ricardo Silva @ Lyncode 2/22/10 8:16 AM
Hi João,

How do you import the Phone.java or RadioInfo.java to your application? (build SDK from source and import? or import each class?) or you built a new Android ROM/Image?

I successful created an application that can access the ITelephony interface (for example, to turn off the radio interface) changing the method access on the TelephonyManager.

Note: I know that using ITelephony is not a good idea, but it's only for testing purposes.

Best Regards,
Ricardo Silva


On Mon, Feb 22, 2010 at 3:38 PM, Joao MG <joa...@gmail.com> wrote:
( very long post)

After a long interval, back to Android RIL.

I've managed to fetch and parse a GSM Page request from the ril.

Using invokeOemRilRequestRaw method in
com.android.internal.telephony.Phone.

The approach was:

1. retrieve sample raw responses from logcat -b radio

This was done by a small change the method retToString in RIL.java:

} else if (ret instanceof byte[]) {
   byte[] bytes = (byte[]) ret;
   s = IccUtils.bytesToHexString(bytes);

This way the invokeOemRilRequestRaw raw bytes response is written to
the log (converted to an hex string).

2. After reading the log, parse the GSM Page response:

D/RILJ    (  141): [0168]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  141): [0168]< OEM_HOOK_RAW
000000003030303200000000000000000000000000000000326400000000000000000000000000000000000032363830310000000000000000000000000000001100000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d3939000000000000000000000000000000110000000000000032363830310000000000000000000000000000003538643763626235000000000000000000000000fa050000ff000000ff0000003000000000000000000000000000000000000000ff000000

So the first line is the GSM Page request, the second is the byte
response (both byte arrays converted to hex strings).

So, now we can parse this into meaningful information using:

ByteBuffer bb = ByteBuffer.wrap(bytes);
bb.order(ByteOrder.LITTLE_ENDIAN);

System.out.println("ARFCN: " + bb.getInt());
System.out.println("LAC: " + getStringFromBytes(bb, 20));
System.out.println("RAC: " + getStringFromBytes(bb, 20));
System.out.println("MNC/MCC:" + getStringFromBytes(bb, 20));
System.out.println("RSSI:" + bb.getInt());
System.out.println("Ncell Info1:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info2:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info3:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info6:" + getStringFromBytes(bb, 20));
System.out.println("RX Quality:" + bb.getInt());
System.out.println("Frequent Hopping:" + bb.getInt());
System.out.println("Last registered network:" + getStringFromBytes(bb,
20));
System.out.println("TMSI:" + getStringFromBytes(bb, 20));
System.out.println("Periodic Location Update Value:" + bb.getInt());
System.out.println("BAND:" + bb.getInt());
System.out.println("Channel In USe:" + bb.getInt());
System.out.println("RSSI 1:" + getStringFromBytes(bb, 20));
System.out.println("Last cell release cause:" + bb.getInt());

The getStringFromBytes method:

private static String getStringFromBytes(ByteBuffer buffer, int
length)
{
  byte[] bytes = new byte[length];
  buffer.get(bytes, buffer.arrayOffset(), 20);
  return new String(bytes);
}

Fortunately HTC FieldTest displays the fields in the exact same order
as their appear in the raw byte response.

The output is something like:

ARFCN: 0
LAC: 0002
RAC: 2d
MNC/MCC:26801
RSSI:17
Ncell Info1:0 -99
Ncell Info2:0 -99
Ncell Info3:0 -99
Ncell Info4:0 -99
Ncell Info4:0 -99
Ncell Info6:0 -99
RX Quality:17
Frequent Hopping:0
Last registered network:26801
TMSI:58d7cbb5
Periodic Location Update Value:1530
BAND:255
Channel In Use:255
RSSI 1:0
Last cell release cause:255

3. Now, to actually execute invokeOemRilRequestRaw

This was accomplished by changing RadioInfo.java (in
com.android.settings, the Settings apps).

I've found no other way to access the Phone. I've tried developing a
new app,
but failed to get a reference to the phone. The following method
fails:

phone = PhoneFactory.getDefaultPhone();

It returns: "PhoneFactory.makeDefaultPhones must be called from Looper
thread".

HTC FieldTest somehow manages to do it, probably because it runs as
system (it shares user id with com.android.phone,
using the sharedUserId attribute in the manifest).

Either way, I've added a bit of code to RadioInfo.java:

byte[] init1;
byte[] init2;
byte[] gsm_page;
byte[] finish;

init1 = hexStringToBytes("0000000008000000010000005f000000");
init2 = hexStringToBytes("0100000000000000");
gsm_page = hexStringToBytes("0200000000000000");
finish = hexStringToBytes("0000000008000000000000005f000000");

phone.invokeOemRilRequestRaw(init1,
mHandler.obtainMessage(EVENT_RAW));
phone.invokeOemRilRequestRaw(init2,
mHandler.obtainMessage(EVENT_RAW));
phone.invokeOemRilRequestRaw(gsm_page,
mHandler.obtainMessage(EVENT_RAW_GSM_PAGE));
phone.invokeOemRilRequestRaw(finish,
mHandler.obtainMessage(EVENT_RAW));

And also changed the mHandler:

case EVENT_RAW:
   ar= (AsyncResult) msg.obj;
   if (ar.exception == null) {
   byte[] bytes = (byte[]) ar.result;
   updateRaw(bytes);
   } else {
   mNeighboringCids.setText("unknown");
   }
   break;
case EVENT_RAW_GSM_PAGE:
   ar= (AsyncResult) msg.obj;
   if (ar.exception == null) {
   byte[] bytes = (byte[]) ar.result;
   updateRawGsmPage(bytes);
   } else {
   mNeighboringCids.setText("unknown");
   }
   break;

And added the methods:

private final void updateRaw(byte[] bytes) {
   mNeighboringCids.append("\n" + bytesToHexString(bytes));
}

private final void updateRawGsmPage(byte[] bytes) {
   ByteBuffer bb = ByteBuffer.wrap(bytes);
   bb.order(ByteOrder.LITTLE_ENDIAN);

   mNeighboringCids.append("\nARFCN: " + bb.getInt());
   mNeighboringCids.append("\nLAC: " + getStringFromBytes(bb, 20));
   mNeighboringCids.append("\nRAC: " + getStringFromBytes(bb, 20));
   mNeighboringCids.append("\nMNC/MCC:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nRSSI:" + bb.getInt());
   mNeighboringCids.append("\nNcell Info1:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nNcell Info2:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nNcell Info3:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nNcell Info4:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nNcell Info4:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nNcell Info6:" + getStringFromBytes(bb,
20));
   mNeighboringCids.append("\nRX Quality:" + bb.getInt());
   mNeighboringCids.append("\nFrequent Hopping:" + bb.getInt());
   mNeighboringCids.append("\nLast registered network:" +
getStringFromBytes(bb, 20));
   mNeighboringCids.append("\nTMSI:" + getStringFromBytes(bb, 20));
   mNeighboringCids.append("\nPeriodic Location Update Value:" +
bb.getInt());
   mNeighboringCids.append("\nBAND:" + bb.getInt());
   mNeighboringCids.append("\nChannel In USe:" + bb.getInt());
   mNeighboringCids.append("\nRSSI 1:" + getStringFromBytes(bb, 20));
   mNeighboringCids.append("\nLast cell release cause:" +
bb.getInt());
}

So when I execute Settings (by calling *#*#4636#*#*) and go to Phone
Information I get, in the mNeighboringCids text field, the GSM Page
data.

I've checked the execution with "logcat -b radio", it's the same as
FieldTest.

Knowing that this works, we can consider changes to the Telephony API
(android.telephony).

The idea is to make this information available, through the framework,
to all apps.

Joao MG

On Feb 8, 9:03 am, Liam Alford <liamjamesalf...@googlemail.com> wrote:
> This thread was dedicated to doing so, but it appears to have gone quiet.
> What info are you after?
>
> On Fri, Feb 5, 2010 at 9:02 PM, Mark Sebik <markse...@gmail.com> wrote:
> > Oh. Thanks. Any luck getting at this info in other ways?
>
> > On Fri, Feb 5, 2010 at 3:10 PM, Liam Alford <l...@smithmyers.com> wrote:
>
> >> Its not open source. Its a htc application.
>
> >> On 5 Feb 2010 15:45, "mobot" <markse...@gmail.com> wrote:
>
> >> Has anyone located  the Field Test in the source? Please let me know.
>
> >> On Jan 11, 4:56 am, Ricardo Silva <ban...@gmail.com> wrote:
> >> > I want to, for example, turn off the ...
> >> --
>
> >> You received this message because you are subscribed to the Google Groups
> >> "android-platform" group.
> >> ...
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "android-platform" group.
> >> To post to this group, send email to android-...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> android-platfo...@googlegroups.com<android-platform%2Bunsubscribe@googlegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/android-platform?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com<android-platform%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.


Re: Low level network information? Ne0 2/22/10 8:37 AM
Nice work Joao, one problem with getting it into the framework is that those RawRilRequests go to libhtc_ril.so, which is HTC proprietary software. Since i have only looked at HTC android devices, i am speculating a bit here, but i do not expect the same RawRilRequests to give the same response on a non-HTC device.

Ricardo, you need to build your test application as a system app then you can import any class from the Android system.
Re: Low level network information? Joao MG 2/22/10 9:11 AM
Ricardo, I've downloaded and changed the Android source code. I didn't
import RIL.java or RadioInfo.java into my application, I've changed
directly in the Android source code.

The problem was: "I've found no other way to access the Phone. I've


tried developing a new app, but failed to get a reference to the
phone." (this problem appears in runtime)

Then I used "make Settings" to build and "adb install" to replace the
Settings app in the ADP1.

Liam, yes, that's probably true. However, making this information
available in the framework could serve as an incentive to other OEMs
to support similar functionality.

It could also spark a discussion on implementing access to this data
as specific RIL_REQUESTs (similar to the ones for
RIL_REQUEST_NEIGHBORING_CELL_IDS, RIL_REQUEST_SIGNAL_STRENGTH, etc ).

For HTC's this is a good thing, it differentiates them from other
OEMs.

On Feb 22, 4:37 pm, Liam Alford <liamjamesalf...@googlemail.com>
wrote:> ...
>
> read more »

Re: Low level network information? Ricardo Silva @ Lyncode 2/22/10 10:06 AM
Thanks Liam and João, I will try these approachs.

João, about this:

"HTC FieldTest somehow manages to do it, probably because it runs as
system (it shares user id with com.android.phone,
using the sharedUserId attribute in the manifest)."

If you use a certificate to sign the application, can you access to PhoneFactory? (and get the default Phone)

Best Regards,
Ricardo Silva


To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.


Re: Low level network information? Joao MG 2/22/10 10:18 AM
Ricardo, It's worth a shot. I've tried putting the sharedUserId like
in FieldTest. But the install failed.

I've also tried to change the /data/system/packages.xml file inside
ADP1, in order for my app to match HTC FieldTest settings. Nothing
worked. Always that "PhoneFactory.makeDefaultPhones must be called
from Looper thread"" message...

I'll open a new thread on this subject. A separate app it would be
much easier to test/debug the various data pages (GSM, GPRR, etc).
Right now I have to make the Settings app. And in order to install and
replace the previous one I need a to reboot the ADP1... a long dev
cycle.

Re: Low level network information? chrisnew 2/24/10 3:55 AM
I've found it is possible to make this an installable .apk on the
ADP1. I use the following techniques:

1. compile your app which makes use of the internal classes within a
firmware build. I use:

com.android.internal.telephony.PhoneFactory.getDefaultPhone()

...to get an instance of com.android.internal.telephony.PhoneProxy.
Note this changed between 1.5 and 1.6 - in 1.5 it was possible to get
a ref to a full Phone obj. Fortunately the PhoneProxy does still
contain a lot of methods and does contain the invokeOemRilRequestRaw
for the field test strings. I am able to recompile this app
individually without needing to recompile the whole firmware.

2. Set your AndroidManifest.xml sharedUserId:

                 android:sharedUserId="android.uid.system"

3. You may need to specify additional permissions such as:

        <uses-permission
android:name="android.permission.MODIFY_PHONE_STATE" />

4. In my case I use the internal API calls within a Service. Therefore
in the AndroidManifest.xml I set the Service to run inside the phone
app process:

                                        android:process="com.android.phone"

5. Compile your app using the public SDK. In this version make the
relevant class(es) stubs which just create an object and don't do
anything. There should be no ref to the internal classes here.

6. Go to <app>/bin/yourapp.apk. Unzip it into app/bin/tmp. You will
see a classes.dex file.

7. Go to <app>/bin. You will see com/* which contains all the classes
compiled against the public SDK. Copy the .class files containing refs
to the internal telephony APIs in your firmware build version into the
public version. Only copy the classes over the ones for which you
previously created stub classes.

8. jar up the classes in the version compiled against the public SDK
with the classes injected from the private firmware build in <app>/
bin.

9. Run dx on the jar to generate a new classes.dex file. I use the dx
in the firmware source tree in <source>/out/host/linux-x86/bin/dx like
this:

<source>/out/host/linux-x86/bin/dx -JXms16M -JXmx1536M --dex --
output=./classes.dex ./classes.jar

10. Copy this over the classes.dex in the previously unzipped .apk in
<app>/bin/tmp.

11. Zip up the tmp directory to create a new .apk.

12. Sign the .apk with the ADP1 test keys from the firmware build.

<source>/out/host/linux-x86/framework/signapk.jar <source>/build/
target/product/security/platform.x509.pem <source>/build/target/
product/security/platform.pk8 your-modded-app.apk your-modded-app-
signed.apk

The techniques listed here work for me on an ADP1 using the stock 1.6
firmware image from http://developer.htc.com/adp.html. I believe that
the .apk would also work on normal HTC Android devices providing that
the app is signed with the same platform keys used to sign the
customer firmware. I have tried to contact HTC regarding this but have
not been able to get a response yet. I think Android needs an
equivalent of Symbian Signed hosted by Google where additional device
manufacturer specific permissions can be applied for from a central
site.

chris

> >> > >> System.out.println("Last registerednetwork:" +> >> > >> Last registerednetwork:26801> ...
>
> read more »

Re: Low level network information? Dianne Hackborn 2/24/10 11:57 AM
On Wed, Feb 24, 2010 at 3:55 AM, chrisnew <ch...@floor51.com> wrote:
The techniques listed here work for me on an ADP1 using the stock 1.6
firmware image from http://developer.htc.com/adp.html. I believe that
the .apk would also work on normal HTC Android devices providing that
the app is signed with the same platform keys used to sign the
customer firmware. I have tried to contact HTC regarding this but have
not been able to get a response yet. I think Android needs an
equivalent of Symbian Signed hosted by Google where additional device
manufacturer specific permissions can be applied for from a central
site.

No.  Good lord, we are not going to allow applications to run their code in the phone process.  Not to mention that this makes the app very tied to the specific product and build it was developed against, so would be completely in appropriate as a stand-alone application.

If you are working closely with a manufacturer to have some code bundled with their device, you may get into a relationship where they sign your code to run in certain processes (though to be honest I think it would probably be stupid to do this with something you don't have the source code for).  But other than that, this kind of thing is just not appropriate.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

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.

Re: Low level network information? chrisnew 2/24/10 3:53 PM

On Feb 24, 7:57 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Wed, Feb 24, 2010 at 3:55 AM, chrisnew <ch...@floor51.com> wrote:
> > The techniques listed here work for me on an ADP1 using the stock 1.6
> > firmware image fromhttp://developer.htc.com/adp.html. I believe that

> > the .apk would also work on normal HTC Android devices providing that
> > the app is signed with the same platform keys used to sign the
> > customer firmware. I have tried to contact HTC regarding this but have
> > not been able to get a response yet. I think Android needs an
> > equivalent of Symbian Signed hosted by Google where additional device
> > manufacturer specific permissions can be applied for from a central
> > site.
>
> No.  Good lord, we are not going to allow applications to run their code in
> the phone process.  Not to mention that this makes the app very tied to the
> specific product and build it was developed against, so would be completely
> in appropriate as a stand-alone application.
>
> If you are working closely with a manufacturer to have some code bundled
> with their device, you may get into a relationship where they sign your code
> to run in certain processes (though to be honest I think it would probably
> be stupid to do this with something you don't have the source code for).
>  But other than that, this kind of thing is just not appropriate.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>

I agree that having to run in the phone process is not a good solution
but really the point I'm making is that this is the only practical
solution right now. A better approach would be to significantly
enhance the public TelephonyManager class which currently enables apps
to register for signal and cell events. For example I need items such
as the telephony disconnect cause and the data reject code which are
accessible from the internal APIs I have used and could reasonably be
added to the public SDK because they are both based on the standard AT
+CMEE modem command. The HTC Field Test strings detailed previously in
this thread are more tricky to make public because they are modem
specific. However the Android platform could specify a framework for
the retrieval of this engineering mode data and the device
manufacturer could supply an add on system component which itself runs
in the phone process like the HTC Field Test app and make this
accessible to the public TelephonyManager.

The overall aim is to provide operators with detailed data on how real
customer devices are interacting with their network. I see software
defined radio as being a major advancement enabling features such as
frequency flexibility and the ability to tailor the radio experience
to a much more granular level rather than the generic one size fits
all approach that currently exists. Both the device radio and network
radio could be more adaptive. A key part of this is to be able to
analyze the daily experience on device for a large number of users
over a large period of time.

I think these elements benefit the device manufacturer, the operator
and ultimately the customer. From my point of view all I can do is
keep trying to find a way to get at this data on real customer phones.
Joao mentioned previously a new standard AT command AT+CPOS which may
help a lot:

http://groups.google.com/group/android-platform/browse_thread/thread/b55c8d3275ed7042/b54391cff17c63e4#msg_89c065a6198b5313

I listed the internal API calls to get the disconnect and reject codes
here:

http://code.google.com/p/android/issues/detail?id=700#c16

chris

Re: Low level network information? Joao MG 2/25/10 3:34 PM
As mentioned by chrisnew, apparently there's no other way to access
this information.

The oem raw requests used by HTC FieldTest seem too vendor specific to
fit the framework.

This could be a good solution:

"However the Android platform could specify a framework for the
retrieval of this engineering mode data and the device manufacturer
could supply an add on system component which itself runs in the phone
process like the HTC Field Test app and make this accessible to the
public TelephonyManager."

It would provide a standard way to extend the android platform ( an
HTC shared library API to fetch the gsm/umts info pages ).

Joao MG

> http://groups.google.com/group/android-platform/browse_thread/thread/...


>
> I listed the internal API calls to get the disconnect and reject codes
> here:
>
> http://code.google.com/p/android/issues/detail?id=700#c16
>
> chris

Re: Low level network information? uri.m 3/24/10 6:08 AM
I was wondering if anyone with an ADP1 and FieldTest.apk could attach
the following:
1. Print-screen of the WCDMA page in the FieldTest.apk
2. Dump from logcat -b radio | grep OEM

I'm trying to get the 3g fields... and I don't know what byte[] the
"invoke" method is expecting..

Thanks!

Uri.

Re: Low level network information? Saeed Akhtar 4/18/12 7:52 AM
Hi everyone. I was looking for same information in my application. But got nothing better than this thread. But its too old. So I want to know that has anyone successfully got low level network information (other than available in sdk) in their application on any specific set/OS or in general? I really need to work on that. I'll be very thankful if someone could help.

Regards 
Saeed

On Thursday, 8 October 2009 17:30:31 UTC+5, Joao MG wrote:
Hi,

I'm interested in fetching low level Radio network information: rxLev,
rxQual, BSIC, BCCH, and other GSM/UMTS network info.

Basic data, such as cellid and location area code is already available
from the SDK API (android.telephony.gsm.GsmCellLocation).

However, detailed Radio network behaviour and information is not
available.

My question: is there a way to fetch this information? Perhaps from
ril / rild?

In order to make add these changes to the Android source code (SDK),
where should I start to look?
- ril / rild (C platform code)
- Telephony (Java / SDK API code)
- Phone and Dialer app's (Java / application code)
Re: Low level network information? Saeed Akhtar 4/18/12 7:55 AM
Hi everyone. 
   I was looking for same information in my application too. I tried to search on internet but got nothing better than this thread. But its quite old now. I was wondering that if anyone was successful in fetching low level information (other than available in sdk) in their application. even if its for a specific mobile/OS or for modified OS, doesn't matter too much for my requirements.
  I'll be very thankful for any help.
Re: Low level network information? Ricardo Silva @ Lyncode 4/23/12 2:25 AM
Hello,

Use the code posted here by João. You need a HTC phone (Nexus One or something). Also need a custom ROM and compile the code through the Android source code. I was successful in fetching low level information with that code.

Kind Regards,

Quarta-feira, 18 de Abril de 2012 15:55:22 UTC+1, Saeed Akhtar escreveu:
Re: Low level network information? felixad 5/13/12 5:31 AM
Hello

I am running João code too. I have two question and hope somebody will
has an solution.

1. Question
-----------------
When I restarted my phone and call the initial command, I get the
following error.

D/RILJ    (  234): [0065]>
OEM_HOOK_RAW[0000000008000000010000005f000000]
D/RILJ    (  234): [0066]> OEM_HOOK_RAW[0210000000000000]
D/RILJ    (  234): [0065]< OEM_HOOK_RAW
D/RILJ    (  234): [0066]< OEM_HOOK_RAW error:
com.android.internal.telephony.CommandException: REQUEST_NOT_SUPPORTED
D/RILJ    (  234): [0067]>
OEM_HOOK_RAW[0000000008000000000000005f000000]

I have to reinstall the app and then everything works fine. I think
the command "0210000000000000" tell us that, the request is not
allowed. Does anybody not a solution?


Second question:
-------------------------
I found the command:
invokeOemRilRequestStrings(java.lang.String[] strings, Message
response)
and the information that there exists AT-commands to call the modem.
When I am using my linux terminal I can get the some information, like
the one described in this thread:
$ adb shell
# su
# stop ril-daemon
# echo -e 'AT$GSM?\r' > /dev/smd0


Now I tried to call the invokeOemRilRequestStrings() with this
String[], but I don't know how it is formatted. I tried these two
ways:
String[] gsm_page = {"A","T","$","G","S","M","?","\r"};
and
String gsm_page2[] = new String[1];
wcdma2[0] = "AT$GSM?\r";

But both will return a "REQUEST_NOT_SUPPORTD". Does anybody has an
idea?


Thanks.
Cheers
Felix
Re: Low level network information? citus 5/13/12 5:03 PM
Instead of:

String[] gsm_page = {"A","T","$","G","S","M","?","
\r"};

Try:
String[] commandString = {"UNIAT", "AT$GSM?\r"};

I have used this and it does work. I don't know how the rest of your code is setup, and I cannot guarantee that the AT$GSM? command will work, but that is definitely how you call invokeOemRilRequestStrings.
Re: Low level network information? felixad 5/14/12 5:34 AM
Hi citus

Thank you very much! This was the solution!

My RIL response looks like that:
D/RILJ    (  235): [0079]>
OEM_HOOK_RAW[0000000008000000010000005f000000]
D/RILJ    (  235): [0080]> OEM_HOOK_STRINGS
D/RILJ    (  235): [0079]< OEM_HOOK_RAW
D/RILJ    (  235): [0080]< OEM_HOOK_STRINGS {UNIAT, $GSM:
560,"1b68","92","22803",0 -99,0 -99,0 -99,0 -99,0 -99,0
-99,0,"22803","46a2bfb5",1530,1,5,-70,0

For my first question it found the answer. I always reinstalled the
app with "adb install -r ......". With this way I only installed
updates which where deleted after a reboot and the first version of
the app was restored. Now I deleted the app in /system/app and
everything was fine.

Thank you for your help.

Cheers
Felix
Re: Low level network information? Damien O'Reilly 6/22/12 4:49 PM
Can you share your code please?

Im having trouble with reflection as im targeting SDK 2.3.3
Re: Low level network information? Damien O'Reilly 6/22/12 4:50 PM
Can you share your code please?

Im having trouble with reflection as im targeting SDK 2.3.3

Re: Low level network information? FelixG 7/7/12 1:13 AM
Hello

Does anybody know, if the device must be rooted to read these low level network information?

My little app is nice running on my HTC magic 32B (second developer phone). Now I tested it on my new HTC One X and I get the message:
Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE]

I also found the HTC FieldTest app for the HTC One XL but I can't install it on my device. I get the same error:
Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE]

You can download the FieldTest here, if anybody needs it:

Would be happy for any hints.
Felix

Am Samstag, 23. Juni 2012 01:50:25 UTC+2 schrieb Damien O'Reilly:
Re: Low level network information? Ricardo Silva @ Lyncode 7/9/12 2:57 AM
Hi,

You need a Android system not only rooted, but running in debug mode (or engineering mode), to install applications with shared:userid == system.

Kind Regards,
Ricardo Silva 
ric...@lyncode.com

Sábado, 7 de Julho de 2012 9:13:24 UTC+1, FelixG escreveu:
Re: Low level network information? chrisnew 7/9/12 2:03 PM
Hi I think something changed in 2.3 to the installer. As root I remount the system partition as read write and just copy the apk over to /system/app to get around the error. Try something like this which is for the Desire HD:

mount -o rw,remount -t ext4 /dev/block/mmcblk0p25 /system

Chris
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/rB-1saKQ0gkJ.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Re: Low level network information? Ricardo Silva @ Lyncode 7/9/12 3:33 PM
Chris,

Did you installed an app with shareduserid == system copying it to system/app?

Kind Regards,
Ricardo Silva
Re: Low level network information? chrisnew 7/9/12 4:39 PM
Hi Ricardo yes. It doesn't install as such - it just appears.

Cheers
Chris
Re: Low level network information? FelixG 7/22/12 12:26 PM
Hi Ricardo

This was a big help but unfortunetly I could not solve it up to now. What I have done:
- I rooted my HTC One X. 
- I am not sure what you ment with "debug mode". Do you mean Settings->Development>USB-Debugging? 

Or does debug mode/engineering mode means that I need a engineering hboot-version?

Then I tried what "chrisnew" wrote and I only copied the FieldTest app to /system/app. But I can't run it. I think the problem is, that the app is not installed (maybe because the permission couldn't be set). I tried to start the activity with the LauncherPro. It was not succesful. Then I tried it directly from adb shell with:
adb shell
am start -a android.intent.action.MAIN -n com.htc.fieldtest/.FieldTest

But I only get the message, that the app does not exist...

I would be happy, if you could give me a short hint how to fix it.

Thanks

Best regards
Felix


Am Montag, 9. Juli 2012 11:57:51 UTC+2 schrieb Ricardo Silva @ Lyncode:
Re: Low level network information? chrisnew 7/22/12 5:32 PM
Hi Felix the FieldTest app on the XDA forum is signed with test keys. To run it on a production HTC One X it needs to be signed with the live keys otherwise it really shouldn't work. Unless you have the live HTC Android platform key (!) to sign it with you will need to flash on something like the CyanogenMod firmware or your own. Then you will have a firmware signed with the same test keys. You'll need to do this for you own stuff but you could extract HTC's FieldTest from a normal production phone and use that instead of the XDA one without flashing. I'm surprised the One X doesn't already have it though.

I'm not quite sure what Ricardo means by debug/engineering mode either so will be good to hear back on this. It sounds like a way to switch off the security (!) so then it wouldn't matter which key is used.

I haven't checked out the ICS installer so maybe there is also a change that breaks just copying to /system/app.

Chris
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/V71xddOUvjsJ.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Re: Low level network information? muntakim 7/29/12 2:09 AM
hi felixad,
can you please share your code on how you use invokeOemRilRequestStrings. 
muntakim
RE: Low level network information? Ricardo Silva @ Lyncode 7/29/12 2:12 AM
Hi,

You have to install on a rom compiled from source with debug keys, because your app is also compiled with debug keys.

Kind regards,
Ricardo Silva

De: FelixG
Enviado: 22-07-2012 20:26
Para: android-...@googlegroups.com
Assunto: Re: Low level network information?

--
RE: Low level network information? Ricardo Silva @ Lyncode 7/29/12 2:20 AM
Debug and eng mode is used when you compile from android source code to use test keys and some internal functionalities will be work different. If you see some source code of the telephony stack or in other packages, there are ifs in the code when the developer tests if is in eng mode or Production mode.

Eng and debug mode is used by manufacturers for Development and tests. You can find this Property in the Build.prop file (ro.build.type)

Kind regards,
Ricardo Silva
ric...@lyncode.com

De: Chris Newman
Enviado: 23-07-2012 01:29

Para: android-...@googlegroups.com
Assunto: Re: Low level network information?

Hi Felix the FieldTest app on the XDA forum is signed with test keys. To run it on a production HTC One X it needs to be signed with the live keys otherwise it really shouldn't work. Unless you have the live HTC Android platform key (!) to sign it with you will need to flash on something like the CyanogenMod firmware or your own. Then you will have a firmware signed with the same test keys. You'll need to do this for you own stuff but you could extract HTC's FieldTest from a normal production phone and use that instead of the XDA one without flashing. I'm surprised the One X doesn't already have it though.

I'm not quite sure what Ricardo means by debug/engineering mode either so will be good to hear back on this. It sounds like a way to switch off the security (!) so then it wouldn't matter which key is used.

I haven't checked out the ICS installer so maybe there is also a change that breaks just copying to /system/app.

Chris

On 22 Jul 2012, at 20:26, FelixG <felixg...@gmail.com> wrote:

Re: Low level network information? PINKERTON 8/21/12 7:18 AM
I think that these methods are still valid for any qualcomm-based baseband

Just a question, has anyone managed to obtain RNC/RRC radio states?
Re: Low level network information? chrisnew 8/21/12 1:06 PM
Yes RRC states are available using 0a00000000000000 on HTC devices and I have this working on an HTC Desire HD running CyanogenMod with 2.3. On Samsung I recall an older version of their field test app included the RRC state so this will be extractable.

Just to comment on the previous post Ricardo you stated firmware compiled in debug mode is needed to actually allow the install because of sharedUserId == system. Ok that makes sense. Something changed to the installer between 2.2 and 2.3 to thwart the release install. The remount of /system as read/write and then copying the apk to /system/app works around this for release mode. Whether the firmware is built in debug or release doesn't affect the actual running of the app once it is installed as long as the app is signed with the correct key (on 2.3).

Chris
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/tyZrnzoA4pMJ.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Re: Low level network information? muntakim 8/25/12 1:54 AM
hi chris,
the command 0a00000000000000 is returning all 255. i guess it is returning data for 3G. what command should i use to get the RRC for 2G/2.5G. please help me out.
Muntakim
Re: Low level network information? chrisnew 8/25/12 5:15 AM
Hi Muntakim yes RRC here is a 3G thing. There is a 2G connected mode so maybe there is something in the field test data to indicate idle/connected. The Channel in Use data on the first GSM page looks like it. I can see changes from CCCH to PDCTH when there is GPRS activity and to SDCCH and TCH on call followed by N/A.

Check:


Chris
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/IQEJwL5iZsAJ.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Re: Low level network information? muntakim 8/26/12 1:08 AM
hi chrisnew,
is it possible to get TCH during call in a 2G/2.5G network. if yes then how can i get it?
thanks,
muntakim
Re: Low level network information? muntakim 8/26/12 11:40 PM

hi chris,


" I can see changes from CCCH to PDCTH when there is GPRS activity and to SDCCH and TCH on call followed by N/A."

which command(AT COMMAND/Codes like "0a00000000000000") you use to see the change? can you please share.
thanks

muntakim
On Saturday, August 25, 2012 6:15:17 PM UTC+6, chrisnew wrote:
Re: Low level network information? muntakim 9/1/12 9:30 PM
hi,

Can Some one please help me to find out TCH on a 2G/2.5G network.
thanks
Re: Low level network information? chrisnew 9/2/12 6:06 PM
Hi muntakim apologies for the delay. The TCH data from the Channel in
Use data is available on the "GSM page" of the field test app data which
is accessible using 0200000000000000.

btw 0a00000000000000 is for the "Layer 3 RRC Signalling" messages page.
The RRC state is actually the first item in the "WCDMA" page which is
0900000000000000.

Chris


On 27/08/2012 07:40, muntakim wrote:
>
> hi chris,
>
> *" I can see changes from CCCH to PDCTH when there is GPRS activity and
> to SDCCH and TCH on call followed by N/A."*
>
> which command(AT COMMAND/Codes like "0a00000000000000") you use to see
> the change? can you please share.
> thanks
> muntakim
> On Saturday, August 25, 2012 6:15:17 PM UTC+6, chrisnew wrote:
>
>     Hi Muntakim yes RRC here is a 3G thing. There is a 2G connected mode
>     so maybe there is something in the field test data to indicate
>     idle/connected. The Channel in Use data on the first GSM page looks
>     like it. I can see changes from CCCH to PDCTH when there is GPRS
>     activity and to SDCCH and TCH on call followed by N/A.
>
>     Check:
>
>     http://www.umtsworld.com/technology/RCC_states.htm
>     <http://www.umtsworld.com/technology/RCC_states.htm>
>
>     Chris
>
>     On 25 Aug 2012, at 09:54, muntakim <muntak...@gmail.com
>>>             ------------------------------------------------------------------------
>>>>                 S�bado, 7 de Julho de 2012 9:13:24 UTC+1, FelixG
>>>>                             > > I am running Jo�o code too. I have
>>>>             <https://groups.google.com/d/msg/android-platform/-/V71xddOUvjsJ>.
>>>>             To post to this group, send email to
>>>>             android-...@googlegroups.com.
>>>>             To unsubscribe from this group, send email to
>>>>             android-platfo...@googlegroups.com.
>>>>             For more options, visit this group at
>>>>             http://groups.google.com/group/android-platform?hl=en
>>>>             <http://groups.google.com/group/android-platform?hl=en>.
>>>
>>>             --
>>>             You received this message because you are subscribed to
>>>             the Google Groups "android-platform" group.
>>>             To post to this group, send email to
>>>             android-...@googlegroups.com.
>>>             To unsubscribe from this group, send email to
>>>             android-platfo...@googlegroups.com.
>>>             For more options, visit this group at
>>>             http://groups.google.com/group/android-platform?hl=en
>>>             <http://groups.google.com/group/android-platform?hl=en>.
>>>
>>>         --
>>>         You received this message because you are subscribed to the
>>>         Google Groups "android-platform" group.
>>>         To view this discussion on the web visit
>>>         https://groups.google.com/d/msg/android-platform/-/tyZrnzoA4pMJ
>>>         <https://groups.google.com/d/msg/android-platform/-/tyZrnzoA4pMJ>.
>>>         To post to this group, send email to
>>>         android-...@googlegroups.com.
>>>         To unsubscribe from this group, send email to
>>>         android-platfo...@googlegroups.com.
>>>         For more options, visit this group at
>>>         http://groups.google.com/group/android-platform?hl=en
>>>         <http://groups.google.com/group/android-platform?hl=en>.
>>
>>     --
>>     You received this message because you are subscribed to the Google
>>     Groups "android-platform" group.
>>     To view this discussion on the web visit
>>     https://groups.google.com/d/msg/android-platform/-/IQEJwL5iZsAJ
>>     <https://groups.google.com/d/msg/android-platform/-/IQEJwL5iZsAJ>.
>>     To post to this group, send email to android-...@googlegroups.com
>>     <javascript:>.
>>     To unsubscribe from this group, send email to
>>     android-platfo...@googlegroups.com <javascript:>.
>>     For more options, visit this group at
>>     http://groups.google.com/group/android-platform?hl=en
>>     <http://groups.google.com/group/android-platform?hl=en>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "android-platform" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-platform/-/FWK_y_diHp0J.
Re: Low level network information? muntakim 9/3/12 4:49 AM
hi Chris,
thanks very much. but in the GSM page i see that there is only BCCH(ARFCN). i also check the GSM page during call but that doesn't change.
i want to know the TCH which is enabled during call time only.
thanks
Muntakim


>>>>                 Sábado, 7 de Julho de 2012 9:13:24 UTC+1, FelixG >>>>                             > > I am running João code too. I have
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.


Re: Low level network information? chrisnew 9/3/12 12:34 PM
Hi Muntakim ok the Channel In Use on the GSM page just indicates TCH is
allocated on the GSM page during a call whereas normally it's on CCCH.

Maybe the AMR page (04) will help - I see EFR is indicated so it's on a
full TCH and also the Timeslot Used is populated.

Chris




On 03/09/2012 12:49, Md. Mahmud Muntakim Khan wrote:
> hi Chris,
> thanks very much. but in the GSM page i see that there is only
> BCCH(ARFCN). i also check the GSM page during call but that doesn't change.
> i want to know the TCH which is enabled during call time only.
> thanks
> Muntakim
>
>
> On Mon, Sep 3, 2012 at 7:06 AM, Chris Newman <ch...@floor51.com
>     <mailto:muntak...@gmail.com>
>     <mailto:nar...@gmail.com>> wrote:
>     >>
>     >>>         I think that these methods are still valid for any
>     >>>         qualcomm-based baseband
>     >>>
>     >>>         Just a question, has anyone managed to obtain RNC/RRC radio
>     >>>         states?
>     >>>
>     >>>         On Sunday, 29 July 2012 11:20:11 UTC+2, Ricardo Silva @
>     >>>         Lyncode wrote:
>     >>>
>     >>>             Debug and eng mode is used when you compile from android
>     >>>             source code to use test keys and some internal
>     >>>             functionalities will be work different. If you see some
>     >>>             source code of the telephony stack or in other packages,
>     >>>             there are ifs in the code when the developer tests if is
>     >>>             in eng mode or Production mode.
>     >>>
>     >>>             Eng and debug mode is used by manufacturers for
>     >>>             Development and tests. You can find this Property in the
>     >>>             Build.prop file (ro.build.type)
>     >>>
>     >>>             Kind regards,
>     >>>             Ricardo Silva
>     >>>             ric...@lyncode.com <mailto:ric...@lyncode.com>
>     >>>            
>     ------------------------------------------------------------------------
>     >>>             De: Chris Newman
>     >>>             Enviado: 23-07-2012 01:29
>     >>>             Para: android-...@googlegroups.com
>     <mailto:android-...@googlegroups.com>
>     >>>>                 ric...@lyncode.com <mailto:ric...@lyncode.com>
>     >>>>
>     >>>>                 S�bado, 7 de Julho de 2012 9:13:24 UTC+1, FelixG
>     <mailto:cit...@gmail.com>> wrote:
>     >>>>                             > Instead of:
>     >>>>                             > String[] gsm_page =
>     >>>>                             {"A","T","$","G","S","M","?","
>     >>>>                             > \r"};
>     >>>>                             >
>     >>>>                             > Try:
>     >>>>                             > String[] commandString = {"UNIAT",
>     >>>>                             "AT$GSM?\r"};
>     >>>>                             >
>     >>>>                             > I have used this and it does work. I
>     >>>>                             don't know how the rest of your code
>     >>>>                             > is setup, and I cannot guarantee that
>     >>>>                             the AT$GSM? command will work, but
>     >>>>                             > that is definitely how you call
>     >>>>                             invokeOemRilRequestStrings.
>     >>>>                             >
>     >>>>                             >
>     >>>>                             >
>     >>>>                             >
>     >>>>                             >
>     >>>>                             >
>     >>>>                             >
>     >>>>                             > On Sunday, May 13, 2012 7:31:52 AM
>     >>>>                             UTC-5, felixad wrote:
>     >>>>                             >
>     >>>>                             > > Hello
>     >>>>                             >
>     >>>>                             > > I am running Jo�o code too. I have
>     <mailto:android-...@googlegroups.com>.
>     >>>>             To unsubscribe from this group, send email to
>     >>>>             android-platfo...@googlegroups.com
>     <mailto:android-platfo...@googlegroups.com>.
>     >>>>             For more options, visit this group at
>     >>>>             http://groups.google.com/group/android-platform?hl=en
>     >>>>            
>     <http://groups.google.com/group/android-platform?hl=en>.
>     >>>
>     >>>             --
>     >>>             You received this message because you are subscribed to
>     >>>             the Google Groups "android-platform" group.
>     >>>             To post to this group, send email to
>     >>>             android-...@googlegroups.com
>     <mailto:android-...@googlegroups.com>.
>     >>>             To unsubscribe from this group, send email to
>     >>>             android-platfo...@googlegroups.com
>     <mailto:android-platfo...@googlegroups.com>.
>     >>>             For more options, visit this group at
>     >>>             http://groups.google.com/group/android-platform?hl=en
>     >>>             <http://groups.google.com/group/android-platform?hl=en>.
>     >>>
>     >>>         --
>     >>>         You received this message because you are subscribed to the
>     >>>         Google Groups "android-platform" group.
>     >>>         To view this discussion on the web visit
>     >>>        
>     https://groups.google.com/d/msg/android-platform/-/tyZrnzoA4pMJ
>     >>>        
>     <https://groups.google.com/d/msg/android-platform/-/tyZrnzoA4pMJ>.
>     >>>         To post to this group, send email to
>     >>>         android-...@googlegroups.com
>     <mailto:android-...@googlegroups.com>.
>     >>>         To unsubscribe from this group, send email to
>     >>>         android-platfo...@googlegroups.com
>     <mailto:android-platfo...@googlegroups.com>.
>     >>>         For more options, visit this group at
>     >>>         http://groups.google.com/group/android-platform?hl=en
>     >>>         <http://groups.google.com/group/android-platform?hl=en>.
>     >>
>     >>     --
>     >>     You received this message because you are subscribed to the
>     Google
>     >>     Groups "android-platform" group.
>     >>     To view this discussion on the web visit
>     >>     https://groups.google.com/d/msg/android-platform/-/IQEJwL5iZsAJ
>     >>    
>     <https://groups.google.com/d/msg/android-platform/-/IQEJwL5iZsAJ>.
>     >>     To post to this group, send email to
>     android-...@googlegroups.com <mailto:android-...@googlegroups.com>
>     >>     <javascript:>.
>     >>     To unsubscribe from this group, send email to
>     >>     android-platfo...@googlegroups.com
>     <mailto:android-platfo...@googlegroups.com> <javascript:>.
>     >>     For more options, visit this group at
>     >>     http://groups.google.com/group/android-platform?hl=en
>     >>     <http://groups.google.com/group/android-platform?hl=en>.
>     >
>     > --
>     > You received this message because you are subscribed to the Google
>     > Groups "android-platform" group.
>     > To view this discussion on the web visit
>     > https://groups.google.com/d/msg/android-platform/-/FWK_y_diHp0J.
>     > To post to this group, send email to
>     android-...@googlegroups.com
>     <mailto:android-...@googlegroups.com>.
>     > To unsubscribe from this group, send email to
>     > android-platfo...@googlegroups.com
>     <mailto:android-platform%2Bunsubscribe@googlegroups.com>.
>     > For more options, visit this group at
>     > http://groups.google.com/group/android-platform?hl=en.
>
>     --
>     You received this message because you are subscribed to the Google
>     Groups "android-platform" group.
>     To post to this group, send email to
>     android-...@googlegroups.com
>     <mailto:android-...@googlegroups.com>.
>     To unsubscribe from this group, send email to
>     android-platfo...@googlegroups.com
>     <mailto:android-platform%2Bunsubscribe@googlegroups.com>.
>     For more options, visit this group at
Re: Low level network information? muntakim 9/3/12 11:47 PM
hi Chris, 
thanks.. i used AT$AMR to get the output ...i get  the output "$AMR: 1,0,2,4,255,30,255" during call time...here the second last parameter("30") is always changing... now can you please explain the output.. i cant understand the output... during idle time all the datas are "255".
thanks
Muntakim
>     >>>>                 S�bado, 7 de Julho de 2012 9:13:24 UTC+1, FelixG
>     >>>>                             > > I am running Jo�o code too. I have
>     >>>> &n
...
Re: Low level network information? chrisnew 9/4/12 2:37 AM
Hi Muntakim I'm not familiar with the proprietary AT commands do you
have a list? What's your device model and firmware version?

I think the output you are seeing maps partially to the field test app
though this is just a guess.

Check the screenshot here:

http://dev.radioagent.net/fieldagent/platforms/android/htc/images/screenshots/htcft_AMR_03_1.png

In this there are 9 elements compared to your 7. The second to last is
possibly the timeslot used like the field test app. When I activate a
call I can see this is the only element that changes in the field test
app. Could be coincidental though and indicate something else.

Chris



On 04/09/2012 07:47, muntakim wrote:
> hi Chris,
> thanks.. i used AT$AMR to get the output ...i get  the output "$AMR:
> 1,0,2,4,255,30,255" during call time...here the second last
> parameter("30") is always changing... now can you please explain the
> output.. i cant understand the output... during idle time all the datas
> are "255".
> thanks
> Muntakim
>
> On Tuesday, September 4, 2012 1:34:13 AM UTC+6, chrisnew wrote:
>
>     Hi Muntakim ok the Channel In Use on the GSM page just indicates TCH is
>     allocated on the GSM page during a call whereas normally it's on CCCH.
>
>     Maybe the AMR page (04) will help - I see EFR is indicated so it's on a
>     full TCH and also the Timeslot Used is populated.
>
>     Chris
>
>
>
>
>     On 03/09/2012 12:49, Md. Mahmud Muntakim Khan wrote:
>     > hi Chris,
>     > thanks very much. but in the GSM page i see that there is only
>     > BCCH(ARFCN). i also check the GSM page during call but that
>     doesn't change.
>     > i want to know the TCH which is enabled during call time only.
>     > thanks
>     > Muntakim
>     >
>     >
>     > On Mon, Sep 3, 2012 at 7:06 AM, Chris Newman <ch...@floor51.com
>     <javascript:>
>     >     >>>>                             > > # echo -e 'AT$GSM?\r' >
>     /dev/smd0
>     >     >>>>                             >
>     >     >>>>                             > > Now I tried to call the
>     >     >>>>                             invokeOemRilRequestStrings()
>     with this
>     >     >>>>                             > > String[], but I don't
>     know how
>     >     it is
>     >     >>>>                             formatted. I tried these two
>     >     >>>>                             > > ways:
>     >     >>>>                             > > String[] gsm_page =
>     >     >>>>                            
>     {"A","T","$","G","S","M","?","\r"};
>     https://groups.google.com/d/msg/android-platform/-/FWK_y_diHp0J
>     <https://groups.google.com/d/msg/android-platform/-/FWK_y_diHp0J>.
>     >     > To post to this group, send email to
>     >     android-...@googlegroups.com <javascript:>
>     >     <mailto:android-...@googlegroups.com <javascript:>>.
>     >     > To unsubscribe from this group, send email to
>     >     > android-platfo...@googlegroups.com <javascript:>
>     >     <mailto:android-platform%2Bunsubscribe@googlegroups.com
>     <javascript:>>.
>     >     > For more options, visit this group at
>     >     > http://groups.google.com/group/android-platform?hl=en
>     <http://groups.google.com/group/android-platform?hl=en>.
>     >
>     >     --
>     >     You received this message because you are subscribed to the
>     Google
>     >     Groups "android-platform" group.
>     >     To post to this group, send email to
>     >     android-...@googlegroups.com <javascript:>
>     >     <mailto:android-...@googlegroups.com <javascript:>>.
>     >     To unsubscribe from this group, send email to
>     >     android-platfo...@googlegroups.com <javascript:>
>     >     <mailto:android-platform%2Bunsubscribe@googlegroups.com
>     <javascript:>>.
>     >     For more options, visit this group at
>     >     http://groups.google.com/group/android-platform?hl=en
>     <http://groups.google.com/group/android-platform?hl=en>.
>     >
>     >
>     > --
>     > You received this message because you are subscribed to the Google
>     > Groups "android-platform" group.
>     > To post to this group, send email to android-...@googlegroups.com
>     <javascript:>.
>     > To unsubscribe from this group, send email to
>     > android-platfo...@googlegroups.com <javascript:>.
Re: Low level network information? muntakim 9/4/12 3:32 AM
hi chris,
i am using htc desire hd with CM7 rom. i can also parse the code (04) if you can just let me know the parsing logic. another thing can you tell how i can know the TCH from that AMR page (your link).
thanks
muntakim
Re: Low level network information? chrisnew 9/6/12 5:42 PM
Hi Muntakim check Joao's post here:


My comment on TCH from the AMR page is just that if the Enhanced Full Rate codec is indicated then the allocated TCH is probably also full rate. Not sure about an identifier.

Following on from a previous thread and pinkerton's message I just tried this on a latest ICS device today and it works.

Chris
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/L5lDh2SeJ5oJ.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Re: Low level network information? android_newbie 9/25/12 9:18 AM
Hi Richardo,

How do I make the phone run in debug mode?

Re: Low level network information? FelixG 9/30/12 7:50 AM
Hi

Like "chrisnew" mentioned some posts above you have to install a system like CyanogenMod on your phone. When you have the sourcecode on your computer, you can use this to compile your app.

I am running my app successfully on a HTC Magic with Cyanogenmod 6. Now I compiled and installed Cyanogenmod on a Nexus One. When I try to install my app I get the failure:
Failure [INSTALL_FAILED_INVALID_INSTALL_LOCATION]

Has anybody an idea, what the problem is? I heard that some more apps will cause this failure in Cyanogenmod 7.

Thanks in advance.

Felix

Am Dienstag, 25. September 2012 18:18:58 UTC+2 schrieb android_newbie:
Hi Richardo,

How do I make the phone run in debug mode?

Re: Low level network information? FelixG 9/30/12 8:16 AM
Hi guys

I got the solution. Sorry for asking to fast. chrisnew answered this some posts before.

1. mount /system partiton as read write:
adb shell
su
mount -o rw,remount -t ext4 /dev/block/mmcblk0p25 /system

2. copy your app to /system/app
cd /sdcard
cp YourApp.apk /system/app/YourApp.apk

3. Close the adb shell
exit
exit


Hope it helps.

Cheers
Felix


Am Sonntag, 30. September 2012 16:50:00 UTC+2 schrieb FelixG:
Re: Low level network information? Roger 10/30/12 7:53 AM
Hi Joao MG,
Is is possible to enable QXDM on Android phone and dump QXDM RAW data by using your method?
I saw below code on ril.cpp 
        case 3:
            LOGI ("Debug port: QXDM log enable.");
            qxdm_data[0] = 65536;     // head.func_tag
            qxdm_data[1] = 16;        // head.len
            qxdm_data[2] = 1;         // mode: 1 for 'start logging'
            qxdm_data[3] = 32;        // log_file_size: 32megabytes
            qxdm_data[4] = 0;         // log_mask
            qxdm_data[5] = 8;         // log_max_fileindex
            issueLocalRequest(RIL_REQUEST_OEM_HOOK_RAW, qxdm_data,
                              6 * sizeof(int));
            break;
        case 4:
            LOGI ("Debug port: QXDM log disable.");
            qxdm_data[0] = 65536;
            qxdm_data[1] = 16;
            qxdm_data[2] = 0;          // mode: 0 for 'stop logging'
            qxdm_data[3] = 32;
            qxdm_data[4] = 0;
            qxdm_data[5] = 8;
            issueLocalRequest(RIL_REQUEST_OEM_HOOK_RAW, qxdm_data,
                              6 * sizeof(int));
            break;

But, I don't know how to enable QXDM, how to dump qxdm_data.

Thanks,
Roger

On Thursday, February 25, 2010 5:34:29 PM UTC-6, Joao MG wrote:
As mentioned by chrisnew, apparently there's no other way to access
this information.

The oem raw requests used by HTC FieldTest seem too vendor specific to
fit the framework.

This could be a good solution:

"However the Android platform could specify a framework for the
retrieval of this engineering mode data and the device manufacturer
could supply an add on system component which itself runs in the phone
process like the HTC Field Test app and make this accessible to the
public TelephonyManager."

It would provide a standard way to extend the android platform ( an
HTC shared library API to fetch the gsm/umts info pages ).

Joao MG

On Feb 24, 11:53 pm, chrisnew <ch...@floor51.com> wrote:
> On Feb 24, 7:57 pm, Dianne Hackborn <hack...@android.com> wrote:
>
>
>
> > On Wed, Feb 24, 2010 at 3:55 AM, chrisnew <ch...@floor51.com> wrote:
> > > The techniques listed here work for me on an ADP1 using the stock 1.6
> > > firmware image fromhttp://developer.htc.com/adp.html. I believe that
> > > the .apk would also work on normal HTC Android devices providing that
> > > the app is signed with the same platform keys used to sign the
> > > customer firmware. I have tried to contact HTC regarding this but have
> > > not been able to get a response yet. I think Android needs an
> > > equivalent of Symbian Signed hosted by Google where additional device
> > > manufacturer specific permissions can be applied for from a central
> > > site.
>
> > No.  Good lord, we are not going to allow applications to run their code in
> > the phone process.  Not to mention that this makes the app very tied to the
> > specific product and build it was developed against, so would be completely
> > in appropriate as a stand-alone application.
>
> > If you are working closely with a manufacturer to have some code bundled
> > with their device, you may get into a relationship where they sign your code
> > to run in certain processes (though to be honest I think it would probably
> > be stupid to do this with something you don't have the source code for).
> >  But other than that, this kind of thing is just not appropriate.
>
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com
>
> I agree that having to run in the phone process is not a good solution
> but really the point I'm making is that this is the only practical
> solution right now. A better approach would be to significantly
> enhance the public TelephonyManager class which currently enables apps
> to register for signal and cell events. For example I need items such
> as the telephony disconnect cause and the data reject code which are
> accessible from the internal APIs I have used and could reasonably be
> added to the public SDK because they are both based on the standard AT
> +CMEE modem command. The HTC Field Test strings detailed previously in
> this thread are more tricky to make public because they are modem
> specific. However the Android platform could specify a framework for
> the retrieval of this engineering mode data and the device
> manufacturer could supply an add on system component which itself runs
> in the phone process like the HTC Field Test app and make this
> accessible to the public TelephonyManager.
>
> The overall aim is to provide operators with detailed data on how real
> customer devices are interacting with their network. I see software
> defined radio as being a major advancement enabling features such as
> frequency flexibility and the ability to tailor the radio experience
> to a much more granular level rather than the generic one size fits
> all approach that currently exists. Both the device radio and network
> radio could be more adaptive. A key part of this is to be able to
> analyze the daily experience on device for a large number of users
> over a large period of time.
>
> I think these elements benefit the device manufacturer, the operator
> and ultimately the customer. From my point of view all I can do is
> keep trying to find a way to get at this data on real customer phones.
> Joao mentioned previously a new standard AT command AT+CPOS which may
> help a lot:
>
> http://groups.google.com/group/android-platform/browse_thread/thread/...
>
> I listed the internal API calls to get the disconnect and reject codes
> here:
>
> http://code.google.com/p/android/issues/detail?id=700#c16
>
> chris

Re: Low level network information? FelixG 1/1/13 2:24 PM
Hello

Has anybody every seen RIL responses like:
Error! GENERIC_FAILURE
or
+CME ERROR: 100

It happens on a HTC One X with CM10 / Jellybean. On my Nexus One with CM9 / IceCreamSandwich or my HTC Magic with CM7 is everything fine.

Has something changed in the RIL communication in Android Jellybean?

My logcat -b radio looks like this for example:
If I call: 0200000000000000
 (t=1357078390)>> AT$GSM?\r
D/HTC_RIL (  161): TX::> AT$GSM?\r
D/RILJ    (  698): [3690]< OEM_HOOK_RAW error: com.android.internal.telephony.CommandException: GENERIC_FAILURE

If I call: AT$GPRS?\r
(t=1357078390)>> AT$GPRS?\r
D/HTC_RIL (  161): TX::> AT$GPRS?\r
}/RILJ    (  698): [3691]< OEM_HOOK_STRINGS {UNIAT, +CME ERROR: 100


Thank you for any answers.

Felix


Am Freitag, 7. September 2012 02:42:09 UTC+2 schrieb chrisnew:
Re: Low level network information? Shrawan Gupta 1/1/13 10:53 PM
In my application, I have to fetch the info related to these Radio parameters: BCCH, Band, BLER, Txpwr & Handover Parameters. In the above discussion, I understood that I have to modify retToString in RIL.java then from my application, have to send the request to RIL using invokeOemRilRequestRaw() which will take the AT command as a first parameter.

So, I fetched the framework.jar from rooted android device which is targated for my project and decompiled it to get all the class files then converted RIL.class to RIL.java & edited as described in the given post. But I got stuck on how to compile RIL.java (as it have dependencies of hidden files) to again make modified framework.jar.

I will then call invokeOemRilRequestRaw() of RIL class from my application to get the output from modified RIL.java.

Any pointer will be highly appreciated.
Please correct me if I am on wrong track.

Re: Low level network information? FelixG 1/2/13 12:19 AM
I use the Cyanogenmod environment.

At first I download and compile Cyanogenmod as described here: http://wiki.cyanogenmod.org/wiki/HTC_One_XL:_Compile_CyanogenMod_(Linux)

Then I flash it on my phone and copy my FieldTest code to the folder ~/android/samples/development/samples. How a app should look like can be seen on the other apps in this folder. Then I have to compile the app with system sources. Here is my code for the HTC One X (endeavoru):

. build/envsetup.sh 
breakfast endeavoru
mmm -B development/samples/FieldTestApp/

I hope it helps.

Am Mittwoch, 2. Januar 2013 07:53:07 UTC+1 schrieb Shrawan Gupta:
Re: Low level network information? Shrawan Gupta 1/3/13 10:41 PM

Thanks Felix for your response. I am able to access Phone object using PhoneFactory.getDefaultPhone() for my targat device HTC Hero (2.3.3).

1. I have called invokeOemRILRequestString() & passed the AT command:
    String[] commandString = {"UNIAT", "AT+CCED?\r"};
    Message msg = mHandler
        .obtainMessage(EVENT_RIL_OEM_HOOK_CMDSTR_COMPLETE);
    // Send request
    mPhone.invokeOemRilRequestStrings(commandString, msg);

My observation: I am getting proper response for AT+CSQ?, but always getting Rx::> 4\r for AT+CCED?.
Ques 1: Do I need to always pass "UNIAT" in 1st argument & for what is means for?
Ques 2: Can anyone plz let me know if I am on wrong track.

2. I have called invokeOemRILRequestRaw() & passed the hexa decimal byte array as a input:

    /*
     * Sending request to RIL
     */
    public void onRun(View view) {
        // Get the checked button
        int idButtonChecked = mRadioGroupAPI.getCheckedRadioButtonId();

        byte[] oemhook = null;
        switch (idButtonChecked) {
        case R.id.radio_api1:           
            oemhook = new BigInteger("0000000008000000010000005f000000", 16).toByteArray();//hexStringToBytes("0000000008000000010000005f000000");
            break;
        case R.id.radio_api2:
            oemhook = new BigInteger("0100000000000000", 16).toByteArray();
            break;
        case R.id.radio_api3:
            oemhook = new BigInteger("0200000000000000", 16).toByteArray();
            break;
        case R.id.radio_api4:
            // Send OEM/AT command string given by user
            break;
        default:
            log("unknown button selected");
            break;
        }

        if (idButtonChecked != R.id.radio_api4) {
            Message msg = mHandler
                    .obtainMessage(EVENT_RIL_OEM_HOOK_CMDRAW_COMPLETE);
            mPhone.invokeOemRilRequestRaw(oemhook, msg);
            responseTextView.setText("");
        } else {
            // Copy string from EditText and add carriage return
            String oemhookstring =  ((EditText) findViewById(R.id.edit_cmdstr))
                    .getText().toString() + '\r' ;
           
            String[] commandString = new String[2];
            commandString[0] = "UNIAT"; //In 1 of post, citus told to add {"UNIAT", "AT$GSM?\r"};
            commandString[1] = oemhookstring; //AT-command/String from user input
            // Create message
            Message msg = mHandler
                    .obtainMessage(EVENT_RIL_OEM_HOOK_CMDSTR_COMPLETE);
            // Send request
            mPhone.invokeOemRilRequestStrings(commandString, msg);
            responseTextView.setText("---Wait response---");
        }
    }

    /*
     * Parsing the response coming from RIL
     */

    void displayRILRawResponse(byte[] byteArray){

        ByteBuffer bb = ByteBuffer.wrap(byteArray);
        bb.order(ByteOrder.LITTLE_ENDIAN);

        System.out.println("ARFCN: " + bb.getInt());
        System.out.println("LAC: " + getStringFromBytes(bb, 20));
        System.out.println("RAC: " + getStringFromBytes(bb, 20));
        System.out.println("MNC/MCC:" + getStringFromBytes(bb, 20));
        System.out.println("RSSI:" + bb.getInt());
        System.out.println("Ncell Info1:" + getStringFromBytes(bb, 20));
        System.out.println("Ncell Info2:" + getStringFromBytes(bb, 20));
        System.out.println("Ncell Info3:" + getStringFromBytes(bb, 20));
        System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
        System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
        System.out.println("Ncell Info6:" + getStringFromBytes(bb, 20));
        System.out.println("RX Quality:" + bb.getInt());
        System.out.println("Frequent Hopping:" + bb.getInt());
        System.out.println("Last registered network:"
                + getStringFromBytes(bb, 20));
        System.out.println("TMSI:" + getStringFromBytes(bb, 20));
        System.out.println("Periodic Location Update Value:" + bb.getInt());
        System.out.println("BAND:" + bb.getInt());
        System.out.println("Channel In USe:" + bb.getInt());
        System.out.println("RSSI 1:" + getStringFromBytes(bb, 20));
        System.out.println("Last cell release cause:" + bb.getInt());
    }
   
My observation: I am getting the (272-500 digit)long hx output similar to as mentioned by Joao but after formatting it in my displayRILRawResponse() most of the fields are zero (0).
Question: Am I passing some wrong input value to mPhone.invokeOemRilRequestRaw() ?


Thanks Gents in Advance.
Please share your expert opinion with me.

-Shrawan.
Re: Low level network information? Shrawan Gupta 1/4/13 6:54 AM
Hi Frnds,

My end-to-end approach on fetching the low level information for my rooted HTC Hero (2.3.3) & hence want to share it. May be helpful to some1. Though I am not sure about the final output and also I tried to install this app on other rooted samsung device but it is giving installation error of INSTALL_FAILED_SHARED_USER_INCOMPATIBLE (don't know why :-( )  :

1. I picked framework.jar from device.
2. Decompiled to get .dex then extract all .class file & created framework_new.jar
3. Created HelloWorld project & added android:sharedUserId="android.uid.phone" & android:process="com.android.phone" in manifest file.
4. Added framework_new.jar as a external jar in application (do not select the checkbox).
5. Now you would be able to use PhoneFactory & Phone class. And It will not push the framework_new.jar while deploying app in phone rather app will take the reference of the framework.jar after installation.
6. In my activity, I have implemented the code of FieldTest, provided somewhere in the mail thread. Which will send request to RIL using invokeOemRilRequestRaw() with "0200000000000000" as a input string.
7. Format the received byte array which is around 270-500 digit value. For my case I am able to get it as shown in attached screenshot.

The output I am getting is very much similar to what Joao has mentioned in above replies.

But I think the output what we are getting is not the appropriate values. As it is showing:
1. Rx Qual 14 which should be 1-7
2. Band: 255 which should be GSM 900, 1800 etc.
3. Ncell Info: 0 -99

Please correct me if you have more information regarding the final output as shown in attachment.

- shraw...@gmail.com
Re: Low level network information? FelixG 1/13/13 4:10 AM
Dear Joao MG 
Dear chrisnew 
Dear Ricardo Silva
Dear Shrawan Gupta 

I decided to write complete open source verion of the whole HTC FieldTest app. I am just coding under the Nexus One and HTC One S. The European version of the HTC One X was not possible to adapt because it has no Qualcomm chipset. But I have seen, that there are some changes in the responses if I compare my app with the FiledTest app on the HTC Magic 32B. 
Does somebody of you has a newer version FieldTest app on a his HTC phone? Could you send me scressnhots of all displayed pages, that I can finish my FieldTest app?

Attachted are two pictures. The first is the original HTC FieldTest app and the other is my one.

Thanks in advance.
Felix















































Am Freitag, 4. Januar 2013 15:54:09 UTC+1 schrieb Shrawan Gupta:
Re: Low level network information? Shrawan Gupta 1/16/13 9:18 PM
Thanks Felix.
It would be very helpful to many people working on the similar topic. I am excited to see the final outcome when you will publish here. Meanwhile could you please brief about the approach what are you following?

-Shrawan
Re: Low level network information? Andong Zhan 2/18/13 3:38 PM
Hi FelixG

I met the same problem in the beginning (Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE]). Thanks to your update, I use the same way to push FieldTest.apk under /system/app/. Now here's a question, how can I launch this app? I tried 

am start -a android.intent.action.MAIN -n com.htc.fieldtest/.FieldTest

But a error came out:

Starting: Intent { act=android.intent.action.MAIN cmp=com.htc.fieldtest/.FieldTest }
Error type 3
Error: Activity class {com.htc.fieldtest/com.htc.fieldtest.FieldTest} does not exist.

PS. I use rooted At&t HTC One X and the software number is 2.20.502.7 710RD

Thanks,
Andong
Re: Low level network information? Andong Zhan 2/19/13 12:49 PM
Hi Chris,

What do you mean RCC states are available using 0a00000000000000? Is this an address and how to access it?

Thanks,
Andong
Re: Low level network information? chrisnew 2/19/13 5:37 PM
Hi Andong when this string is passed into invokeOemRilRequestRaw it returns the data that appears in the field test app page containing the RRC state as well as the other elements. These strings provide page by page data chunks and you have to extract the elements you want out of them.

Cheers
Chris
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.

To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Re: Low level network information? ee chuan 2/21/13 1:51 AM
Hi Shrawan Gupta,

How do you instantiate/call mHandler?
i am able to access Phone object. I know what commandstring to pass for invokeOemRILRequestString(), but i do not know what to pass for msg.

Thank you
Re: Low level network information? Andong Zhan 2/23/13 9:49 AM
Hi Joao,

Does this code work for Nexus S or Galaxy Nexus?

Thanks,
Andong

On Monday, February 22, 2010 10:38:40 AM UTC-5, Joao MG wrote:
( very long post)

After a long interval, back to Android RIL.

I've managed to fetch and parse a GSM Page request from the ril.

Using invokeOemRilRequestRaw method in
com.android.internal.telephony.Phone.

The approach was:

1. retrieve sample raw responses from logcat -b radio

This was done by a small change the method retToString in RIL.java:

} else if (ret instanceof byte[]) {
    byte[] bytes = (byte[]) ret;
    s = IccUtils.bytesToHexString(bytes);

This way the invokeOemRilRequestRaw raw bytes response is written to
the log (converted to an hex string).

2. After reading the log, parse the GSM Page response:

D/RILJ    (  141): [0168]> OEM_HOOK_RAW[0200000000000000]
D/RILJ    (  141): [0168]< OEM_HOOK_RAW
000000003030303200000000000000000000000000000000326400000000000000000000000000000000000032363830310000000000000000000000000000001100000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d393900000000000000000000000000000030202d3939000000000000000000000000000000110000000000000032363830310000000000000000000000000000003538643763626235000000000000000000000000fa050000ff000000ff0000003000000000000000000000000000000000000000ff000000

So the first line is the GSM Page request, the second is the byte
response (both byte arrays converted to hex strings).

So, now we can parse this into meaningful information using:

ByteBuffer bb = ByteBuffer.wrap(bytes);
bb.order(ByteOrder.LITTLE_ENDIAN);

System.out.println("ARFCN: " + bb.getInt());
System.out.println("LAC: " + getStringFromBytes(bb, 20));
System.out.println("RAC: " + getStringFromBytes(bb, 20));
System.out.println("MNC/MCC:" + getStringFromBytes(bb, 20));
System.out.println("RSSI:" + bb.getInt());
System.out.println("Ncell Info1:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info2:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info3:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info4:" + getStringFromBytes(bb, 20));
System.out.println("Ncell Info6:" + getStringFromBytes(bb, 20));
System.out.println("RX Quality:" + bb.getInt());
System.out.println("Frequent Hopping:" + bb.getInt());
System.out.println("Last registered network:" + getStringFromBytes(bb,
20));
System.out.println("TMSI:" + getStringFromBytes(bb, 20));
System.out.println("Periodic Location Update Value:" + bb.getInt());
System.out.println("BAND:" + bb.getInt());
System.out.println("Channel In USe:" + bb.getInt());
System.out.println("RSSI 1:" + getStringFromBytes(bb, 20));
System.out.println("Last cell release cause:" + bb.getInt());

The getStringFromBytes method:

private static String getStringFromBytes(ByteBuffer buffer, int
length)
{
   byte[] bytes = new byte[length];
   buffer.get(bytes, buffer.arrayOffset(), 20);
   return new String(bytes);
}

Fortunately HTC FieldTest displays the fields in the exact same order
as their appear in the raw byte response.

The output is something like:

ARFCN: 0
LAC: 0002
RAC: 2d
MNC/MCC:26801
RSSI:17
Ncell Info1:0 -99
Ncell Info2:0 -99
Ncell Info3:0 -99
Ncell Info4:0 -99
Ncell Info4:0 -99
Ncell Info6:0 -99
RX Quality:17
Frequent Hopping:0
Last registered network:26801
TMSI:58d7cbb5
Periodic Location Update Value:1530
BAND:255
Channel In Use:255
RSSI 1:0
Last cell release cause:255

3. Now, to actually execute invokeOemRilRequestRaw

This was accomplished by changing RadioInfo.java (in
com.android.settings, the Settings apps).

I've found no other way to access the Phone. I've tried developing a
new app,
but failed to get a reference to the phone. The following method
fails:

phone = PhoneFactory.getDefaultPhone();

It returns: "PhoneFactory.makeDefaultPhones must be called from Looper
thread".

HTC FieldTest somehow manages to do it, probably because it runs as
system (it shares user id with com.android.phone,
using the sharedUserId attribute in the manifest).

Either way, I've added a bit of code to RadioInfo.java:

byte[] init1;
byte[] init2;
byte[] gsm_page;
byte[] finish;

init1 = hexStringToBytes("0000000008000000010000005f000000");
init2 = hexStringToBytes("0100000000000000");
gsm_page = hexStringToBytes("0200000000000000");
finish = hexStringToBytes("0000000008000000000000005f000000");

phone.invokeOemRilRequestRaw(init1,
mHandler.obtainMessage(EVENT_RAW));
phone.invokeOemRilRequestRaw(init2,
mHandler.obtainMessage(EVENT_RAW));
phone.invokeOemRilRequestRaw(gsm_page,
mHandler.obtainMessage(EVENT_RAW_GSM_PAGE));
phone.invokeOemRilRequestRaw(finish,
mHandler.obtainMessage(EVENT_RAW));

And also changed the mHandler:

case EVENT_RAW:
    ar= (AsyncResult) msg.obj;
    if (ar.exception == null) {
    byte[] bytes = (byte[]) ar.result;
    updateRaw(bytes);
    } else {
    mNeighboringCids.setText("unknown");
    }
    break;
case EVENT_RAW_GSM_PAGE:
    ar= (AsyncResult) msg.obj;
    if (ar.exception == null) {
    byte[] bytes = (byte[]) ar.result;
    updateRawGsmPage(bytes);
    } else {
    mNeighboringCids.setText("unknown");
    }
    break;

And added the methods:

private final void updateRaw(byte[] bytes) {
    mNeighboringCids.append("\n" + bytesToHexString(bytes));
}

private final void updateRawGsmPage(byte[] bytes) {
    ByteBuffer bb = ByteBuffer.wrap(bytes);
    bb.order(ByteOrder.LITTLE_ENDIAN);

    mNeighboringCids.append("\nARFCN: " + bb.getInt());
    mNeighboringCids.append("\nLAC: " + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nRAC: " + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nMNC/MCC:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nRSSI:" + bb.getInt());
    mNeighboringCids.append("\nNcell Info1:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info2:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info3:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info4:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info4:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nNcell Info6:" + getStringFromBytes(bb,
20));
    mNeighboringCids.append("\nRX Quality:" + bb.getInt());
    mNeighboringCids.append("\nFrequent Hopping:" + bb.getInt());
    mNeighboringCids.append("\nLast registered network:" +
getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nTMSI:" + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nPeriodic Location Update Value:" +
bb.getInt());
    mNeighboringCids.append("\nBAND:" + bb.getInt());
    mNeighboringCids.append("\nChannel In USe:" + bb.getInt());
    mNeighboringCids.append("\nRSSI 1:" + getStringFromBytes(bb, 20));
    mNeighboringCids.append("\nLast cell release cause:" +
bb.getInt());
}

So when I execute Settings (by calling *#*#4636#*#*) and go to Phone
Information I get, in the mNeighboringCids text field, the GSM Page
data.

I've checked the execution with "logcat -b radio", it's the same as
FieldTest.

Knowing that this works, we can consider changes to the Telephony API
(android.telephony).

The idea is to make this information available, through the framework,
to all apps.

Joao MG

On Feb 8, 9:03 am, Liam Alford <liamjamesalf...@googlemail.com> wrote:
> This thread was dedicated to doing so, but it appears to have gone quiet.
> What info are you after?
>
> On Fri, Feb 5, 2010 at 9:02 PM, Mark Sebik <markse...@gmail.com> wrote:
> > Oh. Thanks. Any luck getting at this info in other ways?
>
> > On Fri, Feb 5, 2010 at 3:10 PM, Liam Alford <l...@smithmyers.com> wrote:
>
> >> Its not open source. Its a htc application.
>
> >> On 5 Feb 2010 15:45, "mobot" <markse...@gmail.com> wrote:
>
> >> Has anyone located  the Field Test in the source? Please let me know.
>
> >> On Jan 11, 4:56 am, Ricardo Silva <ban...@gmail.com> wrote:
> >> > I want to, for example, turn off the ...


> >> --
>
> >> You received this message because you are subscribed to the Google Groups
> >> "android-platform" group.
> >> ...

>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "android-platform" group.
> >> To post to this group, send email to android-...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> android-platfo...@googlegroups.com<android-platform%2Bunsubscribe@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/android-platform?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com<android-platform%2Bunsubscribe@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
>

Re: Low level network information? Andong Zhan 2/25/13 7:09 PM
Hi guys,

I successfully install FieldTest.apk into /system/app on my Nexus S. But I cannot get any info from the app. The logcat shows

V/FieldTestActivity(  545): Request -> RIL
V/FieldTestActivity(  545): Response <- RIL
D/FieldTestActivity(  545): Exception: Field Test Mode: GSM

I think the reason is Nexus S does not use Qualcomm chip, right? If so, how can we access these info from Nexus S or Galaxy Nexus?

Thanks,
Andong
Re: Low level network information? Andong Zhan 2/26/13 11:58 AM
Hi Chris,

Does this work for phones using Intel baseband, e.g., nexus S and galaxy nexus? Or this way is htc specific.

Thanks,
Andong
Re: Low level network information? Andong Zhan 2/26/13 12:05 PM
Hi guys,

I'm just wondering is it possible to get the same low level info as FieldTest.apk via AT commands on HTC One X (Rogers)? For example, I can use some AT commands via adb shell:

130|root@android:/ # cat /dev/smd0 &                                           
[1] 12325
root@android:/ # echo -e "ATQ0\r" > /dev/smd0
root@android:/ # echo -e "ATE0\r" > /dev/smd0  
root@android:/ # echo -e "AT+CGSN\r" > /dev/smd0                               
root@android:/ # echo -e "AT+CGSN\r" > /dev/smd0                               
root@android:/ # 3596*****650146
0

Do you know any AT commands can print out low level network information? Especially LTE info.

Thanks,
Andong

On Thursday, October 8, 2009 8:30:31 AM UTC-4, Joao MG wrote:
Hi,

I'm interested in fetching low level Radio network information: rxLev,
rxQual, BSIC, BCCH, and other GSM/UMTS network info.

Basic data, such as cellid and location area code is already available
from the SDK API (android.telephony.gsm.GsmCellLocation).

However, detailed Radio network behaviour and information is not
available.

My question: is there a way to fetch this information? Perhaps from
ril / rild?

In order to make add these changes to the Android source code (SDK),
where should I start to look?
- ril / rild (C platform code)
- Telephony (Java / SDK API code)
- Phone and Dialer app's (Java / application code)
unk...@googlegroups.com 4/17/13 5:15 AM <This message has been deleted.>
Re: Low level network information? Shrawan Gupta 4/17/13 5:20 AM
You can use like:

    public static Parcel obtainEngineeringModeEnableRequest(boolean var0) {
        Parcel var1 = Parcel.obtain();
        var1.writeInt(2);
        var1.writeInt(0);
        byte var2;
        if (var0) {
            var2 = 0;
        } else {
            var2 = 0;
        }

        /*var1.writeInt(0);
        var1.writeInt(0);*/
        return var1;
    }


    public void sendRILRequest() {

        // Get the checked button

        byte[] oemhook = null;
        Message msg = null;
       
        Parcel localParcel12 = obtainEngineeringModeEnableRequest(true);
        byte[] reqBArray = localParcel12.marshall();

        String reqSS = bytesToHexString(reqBArray);
       
       
        StringBuffer oemStrResponse = new StringBuffer();
        for (int i = 0; i < reqBArray.length; i++) {
            byte myByte = reqBArray[i];
            int myInt = (int) (myByte & 0xFF);
            oemStrResponse.append(Integer.toString(myInt, 16));
        }
        System.out.println("+++++ Final RAW request :: " + oemStrResponse);

     
       
        oemhook = new BigInteger("0200000000000000", 16).toByteArray();
        msg = mHandler.obtainMessage(EVENT_RIL_OEM_HOOK_CMDRAW_COMPLETE);// EVENT_RAW
        mPhone.invokeOemRilRequestRaw(reqBArray, msg);
        responseTextView.setText("");

    }

-Shra1.
Re: Low level network information? M. Prem 4/7/14 2:56 PM
Hello i am working on a project ( https://github.com/SecUpwN/Android-IMSI-Catcher-Detector ) and we are looking for the same answers like you :) and we still need developers! 

Is there a solution to get informations about the cipher indicator or the current used encryption standard (if A/0)?
More topics »