OK. Here we go for a long post, this is the work that came from disassembling glgps daemon and spending quite a few hours/nights driving around to test things. I also drew on my knowledge of GPS systems and used my Bluetooth GPS as a comparison.
The glgps daemon is responsible for communication between the GPS chipset in the SGS and the android userspace. It pulls settings both from NVRAM and some files in /data/gps and /etc. It uses this information to initalize the GPS system at startup and hold it ready to service location requests. This is where all the tweaking that will make a difference regarding GPS output should take place. (If we can get into NVRAM there's more stuff there too.)
I've attached to this post an update.zip with the latest build of the glgps daemon (/vendor/bin/gpsd from nexus s), relocated to /system/bin/gpsd/glgps_samsungJupiter where it sits on the SGS ROMs. I've also included secgps.conf and jupiter.xml, which i've commented with all possible values I could find disassembling it, and the various effects I observed testing them. I also outfitted the jupiter.xml with the most optimal settings I ran into.
A simple breakdown of what I did was to turn off smoothing and interpolation, by using pedestrian mode and a few new variables available in the nexus s daemon. This yields an output as close to what the GPS chip is seeing as possible. It doesn't necessarily mean that it will be more accurate to reality, only that the firmware and daemon won't filter out results that it thinks don't match what it should see. This behavior is more desireable for me than the GPS chip trying to guess, I can be aware of the variations by looking at the accuracy indicator.
[size=+2]How to get logging out of the glgps daemon so you can observe the effects of tweaks, environmental effects, etc. (A.K.A. lets not stab at the dark!)[/size]
1. Root your device
2. adb shell
3. $ su
#
4. cd /system/bin/gpsd
5. mv glgps_samsungJupiter glgps
6. reboot
Now the glgps daemon won't load at startup. After your device reboots, repeat steps 2-4. Then:
7. cp /system/etc/jupiter.xml /sdcard/
8. adb pull /sdcard/jupiter.xml .
9. edit jupiter.xml on your pc as desired.
10. adb push jupiter.xml /sdcard/
11. adb shell
12. su
13. cd /system/bin/gpsd/
14. ./glgps -c /sdcard/jupiter.xml
alternate command line for activating a "job" in glgps:
11. ./glgps -c /sdcard/jupiter.xml jobname <---------- jobname can be anything defined in your jupiter.xml as a job. Examples from mine: normal cold-single-supl freq-aid-test sim-cold-auto. Some jobs will exit immediately after you stop attempting a fix.
Now the glgps will be loaded, and if bPrintToConsole="true" cLogEnabled="true" are both set, you will start seeing debug output in the console. It will indicate the file it is saving log data to, all initialization information, and display info throughout the time you are connected with adb.
To revert glgps back so that it starts again at bootup as normal, rename glgps back to it's original name. It will then continue to load /system/etc/jupiter.xml on the next reboot as normal. (replace this file with your edited one if you want to continue using the settings)
NOTE: Occaisionally i've had the logging verbosity so high that the GPS cannot get a lock at all. To a certain extent you can work around this by adjusting the "niceness" of the process using the program "renice" (which makes it "meaner" giving it a higher priority over other processes (thus more CPU power to work with) - "renice -20 -p $(pidof glgps)" to make it highest priority.
[size=+2]How do I change what goes in the log file (verbosity)?[/size]
<gll LogPriMask="LOG_FLAG | LOG_FLAG2" LogFacMask="LOG_FLAG | LOG_FLAG2" > control this. Possible LOG_FLAGs are as follows, seperated by a | (pipe)
LOG_EMERG | LOG_ALERT | LOG_CRIT | LOG_ERR | LOG_WARNING | LOG_NOTICE | LOG_INFO | LOG_DEBUG | LOG_GLLAPI | LOG_NMEA | LOG_RAWDATA | LOG_ASIC_IO | LOG_RF_DEBUG | LOG_BBTEST | LOG_DEVCV | LOG_DEVET | LOG_DEVJG | LOG_DEVIA | LOG_DEVKF | LOG_DEVMR | LOG_DEVMS | LOG_DEVSP | LOG_DEVDH | LOG_DEVRA | LOG_DEVRS | LOG_DEVVG | LOG_USR1 | LOG_USR2 | LOG_USR3 | LOG_USR4 | LOG_USR5 | LOG_USR6 | LOG_UNITTEST | LOG_DEFAULT
I've documented some of the logging switches in the jupiter.xml comments. Some of these generate HUGE logs. (large enough to use so much I/O and CPU that glgps can't determine your location at all) - be aware that using full verbosity will also probably result in never getting a fix
LOG_DEVVG output: GetSigMeasForClockModel:: SvId 23 Snr 0.000000 mode 1 accepted!
LOG_DEVRA output: GlMeasEng::EnableLowPowerExt(F) GlMechanMgr::UpdateTo12Chan() - Update to 12 full channels AcqMgr::LogAgc() vga_ctrl=0x18 agc=9
LOG_DEVDH output: Raw calculation data (large log)
LOG_DEVMS output: Raw calculation data (large log)
LOG_DEVMR output: #240355D BlndMgr TerminateSearches(2) #240366D BlndMgr(otLstOfSvIdScanNonTrk:686): #240366D BlndMgr(otLstOfSvIdDrillNonTrk:687): #240367D BlndMgr(otSvIdKillLst:691):
LOG_DEVKF output: Fix Data (Lat, Long, Alt, Estimated Accuracy
LOG_DEVIA output: SNR, Latency, Vector, Measurement (large log)
LOG_DEVJG output: Per channel SNR, Latency, Vector, Measurement (large log)
LOG_DEVET output: TCXO calibration data, Doppler calculations (large log)
LOG_DEVCV output: SATAID data, Oscillator data
LOG_DEFAULT output: All on! Realllllllllllllllllly Big!
NOTE: For NMEA output, set LOG_NMEA and also set "GPS Logging" to ON in lbstestmode app. This will generate /sdcard/gps/tracking/NMEA-<DATESTAMP>-<TIMESTAMP>.txt files for each track (from the time you are using the gps til the time you release it) - These .txt files follow the NMEA standard and you can use them to generate tracklogs or do other nifty GPS related things (check out the PC program gpsbabel, for example)
NOTE2: If you want to restart the glgps daemon on the fly, to load new jupiter.xml settings for testing, open a concurrent adb shell connection in root, and type: "kill $(pidof glgps)" this will kill the glgps daemon in the other shell window and you can restart it with a new jupiter.xml
[size=+2]Sample output from logging:[/size]
Code:
H187754I OpenFifo: Opened "/data/gps/glgpsctrl"
H187765I Certificate Path : /system/bin/gpsd/
H187765I TLS enable = 1
H187768I Certificate Path : /system/bin/gpsd/
H187768I TLS enable = 1
H187768I LBS_A: starting event handler
H187768I LBS_I: ASN1 manager: 1237d4, 2044 bytes
H187768I LBS_I: Encode/decode buffer: 123fd4, 6120 bytes
H187768I LBS_I: Dynamic memory buffer: 1257bc, 24480 bytes
H187769I LBS_I: @(#)Broadcom LBS ver. 2.1.0.0 86303, 2010/Nov/07, 13:12:55
H187769I LBS_I: API: gllbs_init(32768)
H187769I LBS_I: CB: nv_open
H187769I LBS_I: CB: nv_read
H187769I LBS_I: CB: nv_close
H187769I LBS_I: 3 cells loaded
Take a look at my provided jupiter.xml for more info on the possible parameters. I've documented it as I went along with comments. I'll update the 2nd post here with more info soon.
[size=+3]Attached file[/size]: CWM update.zip with new glgps daemon from nexus s, jupiter.xml with pedestrian mode settings
NOTE: CWM update.zips will not work in eclair, you must change the following:
Code:
gpioNStdbyPath="/sys/class/sec/gps/GPS_PWR_EN/value"
gpioNResetPath="/sys/class/sec/gps/GPS_nRST/value"
to:
Code:
gpioNStdbyPath="/sys/class/gpio/gpio121/value"
gpioNResetPath="/sys/class/gpio/gpio120/value"
[size=+2]Notable Settings[/size]:
<hal acEEDir="/data/gps/" acEEFileName="xtra.bin" /> : Defines an Extended Ephemeris file for the glgps daemon to load for AGPS data. The drivers normally do not appear to download this file successfully and the daemon says it is corrupt.
<hal bPrintToConsole="true" cLogEnabled="false acLogDirectory="/sdcard/gps/log"" /> : Determines of the logging output should be printed to console and/or to a text file. The text file will be placed in the directory provided and named gl-<TIMESTAMP>.txt. Inside will be the logging output at the verbosity you defined using LOG_FLAGs in <gll LogPriMask="LOG_FLAG | LOG_FLAG2" LogFacMask="LOG_FLAG | LOG_FLAG2" >
<hal arp-supl-enable="true" arp-supl-cap-msb="true" arp-supl-cap-msa="false" arp-supl-cap-ecid="true" arp-supl-reaiding-time-sec = "600" /> : These settings tell the glgps daemon what the SUPL AGPS server provided next is capable of. MS-B means Mobile Station Based, MS-A is Mobile Station Assisted, ECID is unknown. Reaiding time defines the minimum amount of time before attempting to re-inject AGPS data to keep the fix tight in seconds.
<hal acSuplServer="h-slp.mnc410.mcc310.pub.3gppnetwork.org" SuplPort="7275" tlsCertPath="/system/bin/gpsd/" /> : This defines the AGPS server to use for SUPL data (only used if enhanced-assisted="true") - if cp-enhanced-assisted="true" is set, will use the providers control plane rather than normal packet data to access SUPL server. Note that the provided SUPL server is AT&T's SUPL server, which is only accessible within their network. Use google's if you are not on AT&T's network. tlsCertPath defines the location in the filesystem to search for SSL certificates used when connecting to the AGPS server. Most ROMs come with AT&T's, if yours doesn't have it, you'll need to add it for the connection to work.
<hal LbsEnable="true" LbsLocal="true" LbsServer="bcmls2.glpals.com" LbsPort="7275" LbsSyncTimeSec = "60" LbsSyncLto="true" LbsSyncCells="true" /> : These settings tell the glgps daemon to use this server for LBS aiding (Location Based Services.) When LbsLocal is true, the glgps daemon will record all cell sites it sees and your reported GPS location at the time. Any future fix attempt will use these coordinates to seed your fix if the current cell tower you are on matches one the glgps daemon has seen before. This data is stored by default in /data/gps/, so note that it will get erased if you clear the /data partition. It might be useful for frequent flashers to modify the jupiter.xml to store data in /sdard/gps/ or some other less volatile location instead, so the local cell db gets a chance to populate.
<gll CNoSmoothEnable="true" > : This disables some of the glgps daemon's internal smoothing algorithms, makes the GPS a little more accurate to its readings. POSSIBLE VALUES: true false
<gll DynMode="DYN_PEDESTRIAN" > : Defaults to automatic mode which makes the glgps daemon determine on the fly if you are on foot or in a vehicle. This affects the interpolation algorithms used (In GPS land, pedestrian mode means the GPS will report each fix it gets, usually 1 per second.) Vehicle mode will not report movement under a certain amount (usually 3-5 meters) in order to keep the indicator more "stable" POSSIBLE VALUES: DYN_AUTOMATIC DYN_PEDESTRIAN DYN_VEHICLE
<gll RfAtt="GL_RF_ATT_DISABLED" > : I haven't tested this enough to be sure if the chip actually has a built in attenuator you can adjust with this parameter, but if so, it goes all the way up to 18dB. The function of an attenuator is to lower the overall incoming signal in order to better compensate for enviornmental noise. Cordless phones, WiFi, Microwaves, and any number of devices work on frequencies close enough to GPS to cause interference. Assuming there is an attenuation circuit present and it's controllable via this parameter, it will yield better performance for various people in various situations. Requires testing
<gll RfType="GL_RF_4751_DANUBE" > : GL_RF_4751_BLUEFIN GL_RF_4751_DANUBE GL_RF_4751_DANUBE_EXT_LNA are values that I have tested working with our GPS. _EXT_LNA comes default on Nexus S, DANUBE default on ours. BLUEFIN I haven't seen set anywhere, but does work. Danube and Bluefin are likely different revisions of the 4751 chipset.
[size=+2]Other settings not found in jupiter.xml[/size]
glgps also seems to heed what the user has set in Settings -> Location and Security, for "Use wireless networks" and "Use sensor aiding". Wireless networks causes nearby WiFi access point info to be used for a faster first fix, and Use sensor aiding attempts to save power by putting the GPS in low power mode when it sees you moving in a straight line, and shutting off entirely when the accelerometer detects that the phone is stationary. This can cause issues when the compass or accelerometer are providing false values (due to interference, mismatched kernel, etc.)
Also, glgps reads settings from NVRAM that are set by the lbstestmode app. These settings are also stored in secgps.conf, but the settings in NVRAM do NOT necessarily match up. Make sure you set your lbstestmode to "standalone" operation so that Android relies on the glgps daemon for AGPS support. My settings are:
Code:
Session Type: Tracking
Test Mode: S/W
Operation Mode: Standalone
Start Mode: Hot Start
GPS Plus: ON
Dynamic Accuracy: ON
Accuracy: 80
GPS Logging: OFF (use ON and LOG_NMEA to get NMEA logs)
Server FQDN Type: Custom Config
Server: h-slp.mnc410.mcc310.pub.3gppnetwork.org <MATCH THIS WITH YOUR JUPITER.XML>
Server Port: 7275 <MATCH THIS WITH YOUR JUPITER.XML>
SUPL Secure Socket: ON <VARIES WITH SERVER, GOOGLE IS OFF>
AGPS Mode: SUPL <OR CONTROL PLANE, MATCH WITH JUPITER.XML>
[SIZE=+3]To summarize the problem i've identified with our GPS so far:[/SIZE]
AGPS was not properly deployed at the factory, or in any of the updates pushed to the Captivate. Only Control Plane AGPS mode is properly configured, but not active by default. As a result, out of the box, the phone is essentially always in standalone mode regardless of settings (without a modified jupiter.xml)
The GPS chip appears to be receiving some kind of interference from other component(s) on the mainboard. This appears to only manifest itself when the handset is under a heavy usage pattern (such as G Maps/G My Tracks plotting your position, scrolling the map, using cell data, reading gps). This interference is causing the GPS chip to have a major drop in performance. I suspect the phones that don't experience this have an exceptional unit that can perform regardless of this interference (I suspect if they tested with raw signal strength showing, the drop would show)
The glgps daemon attempts to do post processing on the data received in the stream from the GPS chip. Because the data received is generally already incorrect, this further compounds the issue. My jupiter.xml already has these post processing algorithms disabled.
That drop in GPS signal due to interference is the kicker. I haven't yet narrowed down the exact cause of the interference, but suspects are:
1.) Cellular Radio - if this is the case, testing with wifi on and the cell radio off should yield a more desireable result (although hard to test while moving in that situation without another device to tether to for mobile data)
2.) CPU Usage on Host CPU - I don't think this is the case. The only CPU intensive thing that runs on the Host CPU is the glgps daemon, and if this were the case, "renice -20 -p $(pidof glgps_samsungJupiter)" would fix the problem. It does not.
3.) GPU usage - This is a possibility.
4.) CPU usage on baseband CPU - There are also some GPS functions handled in the baseband. I doubt this is the cause but possible.
5.) EM leakage from other system components - I'm leaning towards this right now. I'll have to open up the captivate and throw an EM shield over the GPS chip and see what the results are.
reserved for more two
Sweet! Trying this out now. Will post results. Thanks Da_g
Been watching the progress on this lately and have to say big props on all the research. Will try it out and see how it goes
Sent from my SAMSUNG-SGH-I897 using XDA App
I'll try it and see how well it does when I get home from work..
Mac
So just install it through CWM?
Yes, the attached zip is a CWM zip. Note that these settings are only what I found optimum, and as this is the development forum, I encourage you to tinker with the possible values (commented inside the jupiter.xml) to figure out what works best for you
Just walked from inside heavy building to outside...after 10 Seconds I had a full lock while walking showing 5m distance...holy [email protected]$#& s&$#$ that is already amazing. I'll use it driving home after work....mad props
Sent from my SAMSUNG-SGH-I897 using XDA App
Da_G said:
<hal acSuplServer="h-slp.mnc410.mcc310.pub.3gppnetwork.org" SuplPort="7275" tlsCertPath="/system/bin/gpsd/" /> : This defines the AGPS server to use for SUPL data (only used if enhanced-assisted="true") - if cp-enhanced-assisted="true" is set, will use the providers control plane rather than normal packet data to access SUPL server. Note that the provided SUPL server is AT&T's SUPL server, which is only accessible within their network. Use google's if you are not on AT&T's network. tlsCertPath defines the location in the filesystem to search for SSL certificates used when connecting to the AGPS server. Most ROMs come with AT&T's, if yours doesn't have it, you'll need to add it for the connection to work.
Click to expand...
Click to collapse
So can I change this before flashing the rom? if so, how? is it possible you can push a "AT&T" version and a "Google" version?
Sure, you can edit the file /system/etc/jupiter.xml in the zip before flashing it to the device. I'll make one with settings for google and control plane and post them in a sec.
Da_G said:
Sure, you can edit the file /system/etc/jupiter.xml in the zip before flashing it to the device. I'll make one with settings for google and control plane and post them in a sec.
Click to expand...
Click to collapse
given i'm in Australia, is there any value at all to changing my ntp servers to local ones (0.au.pool.ntp.org) as opposed to US ones?
Edit I'm posting to slow lol
Sent from my SAMSUNG-SGH-I897 using XDA App
I would soooo try this out right now if I was not overseas atm. It'll be 3 weeks before I can try this out but to Da_G thank you for doing something that Samsung should be working on the most!
Ok, updated first post with AT&T, Google, and Control Plane versions. Control Plane should work on any cellular provider (if they have implemented it, which all should have)
Regarding changing the NTP server that can't hurt, but should only affect the TTFF (Time To First Fix) as it should sync up to the GPS satellites after that.
Da_G said:
Ok, updated first post with AT&T, Google, and Control Plane versions. Control Plane should work on any cellular provider (if they have implemented it, which all should have)
Click to expand...
Click to collapse
Is there any value of Control Plane vs Google SUPL? should one be "better" than the other?
Da_G said:
Regarding changing the NTP server that can't hurt, but should only affect the TTFF (Time To First Fix) as it should sync up to the GPS satellites after that.
Click to expand...
Click to collapse
Cool. Didn't quite understand how it was used in relation to GPS.
Is there a rough laymans terms of why having WIFI on (and connected to an AP) leads to far more accurate results faster, when its a new AP that i've not connected to before? I was thinking it might have something to do with Time Servers and Latency (as latency to an NTP would be *dramatically* lower over Wifi VS any form of cellular comms) - given your explanation re NTP, I don't think thats the case now.
It certainly can't be "google knows where the AP's are", given that I work in IT Services and create/delete/move AP's all the time.
In the case of AGPS, your current CellID, along with MNC and MCC are sent to the database (your cell providers control plane server, google, or any other SUPL server provided in jupiter.xml) in order to obtain approximate Latitude/Longitude for an initial fix. (due to the nature of GPS, having an initial "guess" as to your current location helps to seed a faster initial fix, which is the main function of AGPS) The reason your Cellular Provider's database could be better is that it is more likely to be up to date than googles. But of course this varies! Some providers don't even maintain a CP server for AGPS.
The reason WiFi helps the time to first fix is similar. Google actually does have your phone report its visible APs (by MAC address) and current best-guess location to its servers. Everyone else's does this too (assuming they have the wireless tick box on) - This allows them to build a large database with which to seed AGPS from. You may have noticed the first time you turn on "Use wireless networks" in Settings - Location and Security, you get a boilerplate disclaimer about allowing google to collect anonymous connection data. That's what this is for
Adding some info to the first post about "Use sensor aiding" and "Use wireless networks" now.
Da_G said:
In the case of AGPS, your current CellID, along with MNC and MCC are sent to the database (your cell providers control plane server, google, or any other SUPL server provided in jupiter.xml) in order to obtain approximate Latitude/Longitude for an initial fix. (due to the nature of GPS, having an initial "guess" as to your current location helps to seed a faster initial fix, which is the main function of AGPS) The reason your Cellular Provider's database could be better is that it is more likely to be up to date than googles. But of course this varies! Some providers don't even maintain a CP server for AGPS.
The reason WiFi helps the time to first fix is similar. Google actually does have your phone report its visible APs (by MAC address) and current best-guess location to its servers. Everyone else's does this too (assuming they have the wireless tick box on) - This allows them to build a large database with which to seed AGPS from. You may have noticed the first time you turn on "Use wireless networks" in Settings - Location and Security, you get a boilerplate disclaimer about allowing google to collect anonymous connection data. That's what this is for
Adding some info to the first post about "Use sensor aiding" and "Use wireless networks" now.
Click to expand...
Click to collapse
Pardon my ignorance...but does this mean after the initial boot with google it is no longer needed to have wi-fi on to get good locks ?
Mac
With stock settings (JF6/JH7), all the aiding data was not saved, but with the proper settings in jupiter.xml, aiding data should be saved into /data/gps and NVRAM so that the GPS chip can use it on the next fixes. This data is only good for a short period of time (hours to days) so unless you are using the GPS that frequently, WiFi on is still beneficial. You only need to have it on at the time you get the first fix, after that you can shut it off.
Da_G said:
With stock settings (JF6/JH7), all the aiding data was not saved, but with the proper settings in jupiter.xml, aiding data should be saved into /data/gps and NVRAM so that the GPS chip can use it on the next fixes. This data is only good for a short period of time (hours to days) so unless you are using the GPS that frequently, WiFi on is still beneficial. You only need to have it on at the time you get the first fix, after that you can shut it off.
Click to expand...
Click to collapse
Cool...thanks for that detailed explaination
Mac
Anyone else noticed with the diagnosis icon as a short cut if you have been in the menu i was asked earlier to update it in the marketplace ?
Nothing has changed as far as i can see in the diagnosis menu, nor lost any functionality or gained any, I'm not even thinking "this was an update, before any random comments" i'm just pondering and wondering if anyone else had this yet ?
I've got the icon, but no updates as yet...
mwako said:
Anyone else noticed with the diagnosis icon as a short cut if you have been in the menu i was asked earlier to update it in the marketplace ?
Nothing has changed as far as i can see in the diagnosis menu, nor lost any functionality or gained any, I'm not even thinking "this was an update, before any random comments" i'm just pondering and wondering if anyone else had this yet ?
Click to expand...
Click to collapse
Had it through as well - didn't notice any new additions or removals from what's already there.
Update: When inputting the codes (i.e. *#0002*28345#) the phone now vibrates whereas it didn't before
skeet94 said:
Had it through as well - didn't notice any new additions or removals from what's already there.
Update: When inputting the codes (i.e. *#0002*28345#) the phone now vibrates whereas it didn't before
Click to expand...
Click to collapse
Can't believe i didn't notice that , I remember now thinking it was an odd feel before when it didn't vibrate inputing the codes, after every other touch/input/exit on the device makes it vibrate, Seems they are doing something then. Lets see if anyone finds any new interesting menus inside ?
The "root menu" doesn't work any more it seems. I don't quite recall the command since I always check the Focus threads.
Updated Service Codes
We have extracted about 90% of the Service Codes from the latest Version I have downloaded. So far, not much in additional options. Maybe some changes in the old ones. Needs to be checked. There are again, some dead codes which are not referenced, so this is normal and not a wrong code from me.
The most interesting codes run a check before they start. If the conditions do not apply, the diag function will not start.
This would be
TESTMODE <--Root
AUDIOGAINCONTROL <-- What a shame as I still need to tweak the Volume on Level 1/30. Which should play more this Level.
(Yes I know, I have tweaked the Sound Tuning options)
The App runs a functions called "check cable" and this one calls "JIG_UART"
This function checks for two conditions. Unfortunately just some numbers, which cannot be explained because of a number code only..
This seems to be a Service Cable, as I was not able to run those codes, even when changed from USB to UART in the menu. So lets get an UART cable
If the UART Service Cable is not needed, maybe someone else finds out...
There are also two commands which check a registry value from the phone, and start not for me:
FTAMAIN
VIEWHISTORYNW
So far I have seen only the following new ones:
SerialNumber --> Starts but does not show anything
TFlashUnPairing --> Starts but have not tested it. I don't need to know everything
Some Menu Item was deleted, forgot which ones...
I have attached the Commands and the Hash table. It does not make sense to transfer every hash code, because most of them are already resolved.
I explain how to resolve it, in case you want to try one:
As an example I have chosen the SMDINFO (Open the TXT file)command, because it has only 5 digits:
The first Number: (4) Tells you the length of the code. Because we use 0 too, this code has 5 positions:
Next to the number in the brackets, is the number you put into the DiagApp Tool, starting from the last. Because SMDINFO shows, you only two of them in the same line, you just continue downwards. You can also use the search option:
This results in:
*#03#
Again you look for the numbers next to the numbers in the brackets. So you need to find the numbers for:
(4) (3) (2) (1) (0)
(4) (3) are easy, on the same line... the looks for the next (2), which can be found under: DisableSellOutSMS If you are unsure, use search...
Its easier as it sounds...
If I find anything new and useful, I will let you know...
Let me know any interesting file to disassemble. The is always more then the eye can catch.. At least with a debug guru in the team...
MC
mchabr said:
The most interesting codes run a check before they start. If the conditions do not apply, the diag function will not start.
This would be
TESTMODE <--Root
Click to expand...
Click to collapse
I guess the well known workaound, will result in the same root access.
*#1111# continue to press any number, until the long number at the top gets a minus symbol. Then just press back, until you jump into the main menu.
Hallo everbody,
im writing a background service to get informations like the time an active app (not my app) is running.
With this information i can show the user a list of the most used apps depending on the time.
The methods of the ActivityManager-class are useless, because the received informations aren't reliable.
So i thought, because the Android-System is based on a Linux-Kernel, i can use the internal structure to get these informations.
So i read out the pseudo proc-filesystem to get the process informations and for the 2nd time i thought
thats the right place for me to get what i want.
I read out the stat-file in every single process-directory to get the starttime(in clock_ticks) of the process.
I dynamic calculate the HZ USER_HZ value and use it to get the real starttime but this time never changes.
It's more like a timestamp of the first start on the system after boot.
The user-code-time and kernel-code-time seems to be too short and the values are updated too irregular.
So i just got a time value, that tells me the time when the app was first started after system boot
but i want a timestamp or anything else i can get from a currently running app to calculate the time this app is active.
Long life services and background services are not my goal.
Now i'm here because i don't know if i just miscalculate the values from this pseudo filesystem or
if i'm absolutely wrong where i get my informations from.
My Questions:
1. Do i read the wrong values files filesystem (if yes, where can i find these informations in the system structures)
2. Do i misunderstand some of the values i read out
3. Why do the files in the process directories become updated so irregular or once in a lifetime (just if im in the right filesystemfile)
I hope u can help me. *-*
Well, interesting approaches. :good:
The only way I see is running a background service and storing the launch time yourself.
I'm sorry but I don't know the answers to your questions.
You could
a) use su to get the active process list
b) get to /proc/??? folder (where ??? is the apppropriate process you enquire, for example /proc/80/)
c) get the /proc/80/sched text file and look for exec_runtime or vruntime or what ever works for you
carbonpeople said:
You could
a) use su to get the active process list
b) get to /proc/??? folder (where ??? is the apppropriate process you enquire, for example /proc/80/)
c) get the /proc/80/sched text file and look for exec_runtime or vruntime or what ever works for you
Click to expand...
Click to collapse
Oh, getting the currently running tasks can even be done much easier and doesn't require root. This is what I use:
Code:
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> processInfoList = am.getRunningAppProcesses();
carbonpeople said:
You could
a) use su to get the active process list
b) get to /proc/??? folder (where ??? is the apppropriate process you enquire, for example /proc/80/)
c) get the /proc/80/sched text file and look for exec_runtime or vruntime or what ever works for you
Click to expand...
Click to collapse
that seems to be exactly what i need!
but there are the next questions:
what is the unit of the "se.sum_exec_runtime"-field? is it in nano-secs?
what does the point do in the value? does it indicates a floating-point value?
im kinda confused and didnt really find something meaningful about the unit (*-*)
and im not very handy with the kernel code from "lxr.linux.no"
nikwen said:
Oh, getting the currently running tasks can even be done much easier and doesn't require root. This is what I use:
Code:
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> processInfoList = am.getRunningAppProcesses();
Click to expand...
Click to collapse
Following Note can be found in the android-doc:
"this method is only intended for debugging or building a user-facing process management UI."
And the "RunningAppProcessInfo"-class (given by the Method) doesnt provide any infos about the running time of a process.
So i think it's more reliable for me to read out the process-infos directly in the proc-filesystem.
Dalorikai said:
Following Note can be found in the android-doc:
"this method is only intended for debugging or building a user-facing process management UI."
And the "RunningAppProcessInfo"-class (given by the Method) doesnt provide any infos about the running time of a process.
So i think it's more reliable for me to read out the process-infos directly in the proc-filesystem.
Click to expand...
Click to collapse
1) True.
2) That's why I wrote this:
nikwen said:
The only way I see is running a background service and storing the launch time yourself.
Click to expand...
Click to collapse
3) But if the other method works and if you don't care about root rights as a requirement, it might be better. :good:
Dalorikai said:
what is the unit of the "se.sum_exec_runtime"-field? is it in nano-secs?
what does the point do in the value? does it indicates a floating-point value?
im kinda confused and didnt really find something meaningful about the unit (*-*)
and im not very handy with the kernel code from "lxr.linux.no"
Click to expand...
Click to collapse
replying to my own post i think the point in the value of the field indicates the milli-secs.
just an idea - im not sure but would be plausible if the unit is nano-secs.
what do u think or possibly know? ^^
I have an RK3066-based generic 2-DIN Android head unit (see here). I've managed to install a rooted image on it (Yay!).
I want to connect it to a vehicle CAN bus, and I'm trying with an ELM327-based USB to OBD2 adaptor (which includes CAN as one of its protocols).
When I plug it into Ubuntu desktop, I get a "/dev/ttyUSB0". I can access it with Putty terminal and send commands as per the ELM documentation. For primitive access from the command line, I can do this (just to see whether it works at a basic level, without any terminal program):
Code:
sudo stty -F /dev/ttyUSB0 speed 38400
sudo cat /dev/ttyUSB0
And in another terminal:
Code:
sudo sh -c "echo "\r\n">/dev/ttyUSB0"
This produces "> ?" in the first terminal, in line with the expected prompt from the device. Good!
However, I can't get it to work on my Android device.
When plugged in, dmesg reports a Prolific USB-Serial device found and added to /dev/ttyUSB0.
"ls /dev/ttyUSB0" shows that it exists and is owned by "radio".
"stty -F /dev/ttyUSB0 speed" shows the speed is set to 9600 (this is also the default on Ubuntu desktop, and if not changed, the above test doesn't work).
However, I can't change the speed, and the test of sending a character to the decide doesn't work.
I've tried changing the permissions of the serial device (see this post) but it didn't help. I also tried changing to 'radio' with "su radio" but that also didn't work.
Whenever I try "stty -F /dev/ttyUSB0 speed 38400" I get either:
stty: /dev/ttyUSB0: cannot perform all requested operations
Or:
stty: /dev/ttyUSB0: cannot perform all requested operations: No such file or directory
I also tried with a couple of terminal programs including the "Serial Port API sample" app. The device never responds, and I think it is for the same reason (the baud rate isn't set to 38400). Note I can select the baud rate in these programs but I don't think it is actually set - stty still reports 9600.
I feel like I am very close to at least talking to the ELM327 but I am missing something. The Torque app claims to have found the OBD2 adaptor, but I can't actually connect it to a vehicle right now so I don't know if it actually works. In any case I need to access it from my own app.
Wondering if anyone knows the answer to this problem... I can write my own app to access /dev/ttyUSB0 (in theory...) but don't want to waste my time if it's hopeless!
Similar Problem
Hi There --- I'm interested in doing a similar thing to what you're doing...communicating with a usb serial device via the command line in android --- I'm wondering if there's any way to do that without rooting the phone. Like you, I can do it successfully on an ubuntu desktop. I'm specifically trying to do this, you can read about it below.
Thanks and Cheers!
Big Picture: I've attached an arduino uno to an android phone via the micro-usb connection on the phone. My goal is to SSH into the phone over its network or internet connection and then run commands from terminal such as this:
echo -n "h" > /dev/ttyACM0
where h is the character actually sent to the arduino and /dev/ttyACM0 is the hypothetical arduino device as it appears in the linux /dev folder.
Unfortunately i'm stuck and i'm wondering if it's because i need a rooted device in order for this to work.
What I've succeeded in doing so far:
-I successfully sent commands to the arduino uno as above (echo -n "h" > /dev/ttyACM0) using a desktop ubuntu 14.04 linux machine
-I can successfully SSH into the android phone via Putty on a windows computer, while also using the SSHDroid host app from google play on the phone itself. but I cannot access the /dev folder...well, I've looked around using an app that claimed it could show all root accessible files and folders (smart kit 360 on google play) and there were no tty items in the /dev folder. I got an app called "list usb devices" and it gave some other path for the device that was /sys ...but it said i didn't have permission to access that.
-I can successfully send individual character commands from the phone to the arduino uno using another google play app called "DroidTerm" ...similar to the old windows hyperterminal program.
So I've verified that all the individual pieces of this puzzle should work each in a particular context. However, when I try to SSH into the phone and then run the command "echo -n "h" > /dev/ttyACM0"
it throws an error regarding permissions, though I'm surprised it didn't throw an error regarding the existence of /dev/ttyACM0, given the missing tty files i mentioned earlier..I was hoping they were just hidden (if this is the device name "file" on one linux machine, will it be the same on a different linux machine (since android is technically linux?)? I was hoping it would be.
Ideas, known solutions, and alternatives are very welcome!
Alternatives I've tried instead of SSH:
remote control the android device with rc software and control the app droidterm.
I tried that, and it's quite expensive in terms of bandwidth (i don't need to send the whole screen constantly), doesn't allow multi-tasking applications on the phone which i need (yes, I know that android nougat supports multi-tasking but my phone is old and won't load it without serious intervention at the level of rooting that I'd rather not do), and has several other issues that will be problematic.
Yesterday, I noticed my Dynalink 4K Box struggling with 4K video. After running "top" in "adb shell", I found a strange process named "askey_tr", running as root (!), occasionally pegging the CPU at 100-200%.
I decided to dig around and in the end was so spooked (and annoyed with the performance drop) that I ended up rooting my device and removing this binary with a DIY Magisk module. Here's what I found by running "strings" on the binary.
It seems to include help strings for common unix tools like ping and traceroute:
Code:
Modern traceroute for Linux, version 2.1
Copyright (c) 2016 Dmitry Butskoy, License: GPL v2 or any later
You do not have enough privileges to use this traceroute method.
ping: can't set multicast time-to-live
This would've almost fooled me (maybe "tr" in askey_tr stands for traceroute, right?), however, it gets more interesting after you look more. There are references to something called TR069:
Code:
external/tr069/source/atomic.c
external/tr069/source/sd.c
external/tr069/source/ft.c
Googling revealed that TR069 is a protocol for remote management of consumer devices, including set-top boxes. That would make some sense. There is even a paper describing use of TR069 for Android devices. However, the unknown extent of this type of "management" scares me. Wouldn't Android's standard update mechanisms be enough?
There are also some strings that look like metrics about the device:
Code:
Device.DeviceInfo.ProcessorNumberOfEntries
Device.DeviceInfo.SupportedDataModel.1.URN
Device.DeviceInfo.ProcessStatus.ProcessNumberOfEntries
Device.ManagementServer.ConnectionRequestUsername
Device.ManagementServer.STUNUsername
Device.ManagementServer.StandbyPolicy.NetworkAwarenessCapable
Device.UserInterface.PasswordRequired
Device.UserInterface.ISPName
Device.UserInterface.RemoteAccess.X_Charter_AllowedIpRanges
Device.Ethernet.RMONStats.template.DropEvents
Device.Ethernet.Interface.2.Enable
Device.Ethernet.Interface.2.Stats.BytesReceived
Device.Ethernet.Interface.1.Enable
Device.Ethernet.Interface.template.LowerLayers
Device.Ethernet.Interface.template.Stats.BytesReceived
Device.Ethernet.Link.2.Stats.DiscardPacketsSent
Device.Ethernet.Link.1.Stats.UnicastPacketsSent
Device.Ethernet.Link.template.Stats.BroadcastPacketsSent
Device.Ethernet.Link.template.Stats.BroadcastPacketsReceived
Device.Ethernet.VLANTermination.template.Stats.BroadcastPacketsReceived
Device.SoftwareModules.ExecutionUnit.template.Status
Device.SoftwareModules.ExecutionUnit.template.References
Things related to XMPP protocol:
Code:
ctrl_send_sig ctrl_sig_xmpp_status_changed
jabber:client
xmpp_load_pem_cert
And some other things that give us clues: HTTP request templates, symbols from OpenSSL, etc.
I also tried to drop this executable into Ghidra, but felt way out of my depth as I'm not experienced in reverse engineering. Perhaps this will pique the interest of someone more skilled.
So in conclusion, this may be something as benign as a software for delivering OTA updates, or a full-on backdoor. The troubling part is it running automatically as "root" and the fact that its nature is not documented anywhere.
I'm attaching the binary and a zip of the contents of /data/tr069 where the executable seems to store its data.
sus
looked through the string table
found RAND_seed, Device.Users.User.2.Password, GetSSIDFromTR069ManagerServer
TR-069 is a remote management protocol standard. It's likely been put in that box for remote command and set up. I've been working with one Android TV OEM to include it in a set top for monitoring and basic config/maintenance stuff. In a way it would be a kind of backdoor to change config info or diagnostics. It was likely built in by the manufacturer for that purpose though and not some nefarious 3rd party (assuming the manufacturer's intentions are noble). I think it boils down to if you trust the box maker or not. TR-369 is the newer variation of it. This doc goes into some more detail on what it can be used for.