How to recognize HttpClient requests from Evo

Search This thread
Is there any easy way for an app to determine whether or not it's running on an Evo? Say...

* at the server side, by examining the http_user_agent string (or some other header sent by HttpClient with POST/GET requests) for something that indicates it's an Evo... or at least likely to be an Evo/Incredible/N1-class phone?

* at the client side, by sniffing the local runtime environment?
 

joeykrim

Inactive Recognized Developer
Jan 9, 2009
1,979
1,310
Is there any easy way for an app to determine whether or not it's running on an Evo? Say...

* at the server side, by examining the http_user_agent string (or some other header sent by HttpClient with POST/GET requests) for something that indicates it's an Evo... or at least likely to be an Evo/Incredible/N1-class phone?

* at the client side, by sniffing the local runtime environment?
server side - visiting http://www.owt.com/test.html shows the http user agent string:
Mozilla/5.0 (Linux; U; Android 2.1-update1; en-us; Sprint APA9292KT Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

client side by reading /system/build.prop will probably work?
 

Amon_RA

Retired Senior Recognized Developer
Jan 2, 2009
1,295
400
Is there any easy way for an app to determine whether or not it's running on an Evo? Say...

* at the server side, by examining the http_user_agent string (or some other header sent by HttpClient with POST/GET requests) for something that indicates it's an Evo... or at least likely to be an Evo/Incredible/N1-class phone?

* at the client side, by sniffing the local runtime environment?

use the props of the phone => adb shell getprop | grep ro.build.fingerprint
 
server side - visiting http://www.owt.com/test.html shows the http user agent string:
Mozilla/5.0 (Linux; U; Android 2.1-update1; en-us; Sprint APA9292KT Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

Is that the string returned by the Evo's browser, or specifically sent by a running app that instantiates a HttpClient object to do the request?

If it's sent by HttpClient as well, Is the "ERE27" part specific to the Evo, or is it shared by other phones as well (particularly, the Incredible and/or Nexus One)? Likewise, is the "APA929KT" part both common AND specific to the Evo (ie, no other phone uses it, and all known Evos -- even those that are rooted & reflashed -- are believed to use it)?
 

rdude

Senior Member
Oct 24, 2006
95
42
Seattle
twitter.com
server side - visiting http://www.owt.com/test.html shows the http user agent string:
Mozilla/5.0 (Linux; U; Android 2.1-update1; en-us;

Is that the string returned by the Evo's browser, or specifically sent by a running app that instantiates a HttpClient object to do the request?

If it's sent by HttpClient as well, Is the "ERE27" part specific to the Evo, or is it shared by other phones as well (particularly, the Incredible and/or Nexus One)? Likewise, is the "APA929KT" part both common AND specific to the Evo (ie, no other phone uses it, and all known Evos -- even those that are rooted & reflashed -- are believed to use it)?

ERE 27 is used by other phones. The other thing I've never seen before. Overall your choices are going to be detecting based on Android version or getting the UA string for every phone you want to support. The latter is a bad idea since there will alwaysbe browser updates or new phones you haven't accounted for.
 

sjwaste

Senior Member
Jun 8, 2010
257
24
See the URL that I posted. Those are the constants used to build the device fingerprint.

EDIT: This is assuming you're running an app on a device and want to know what kind of device it is. If it's running server side, disregard - my info isn't helpful for that.
 
Basically, it's an Android client to a web service that seems to be having major Evo problems. Right now, I'm mainly trying to quickly figure out how many Evo owners are actually having problems. If it's something that's crippling most/all Evo owners, it's a very high priority to fix. If it's something that's crashing only for a few Evo owners who insist on weird configurations that almost defy logic, it's way down the priority list. The thing is, right now, I have no idea at all how widespread the problem is.

I'd really prefer to be able to do it based on a http request header sent by the HttpClient object, because THEN I can just make a quick tweak to the server end and log enough data in a few hours to get a better idea of where we stand tonight and this weekend. However, if the only way to do it is by having the client itself probe its environment, I'll have to slip it into the next release and start collecting that data instead.
 
Well, here's a distilled copy of the http_user_agent strings seen by the server this afternoon. Unfortunately, none of them seem to jump out and scream, "Evo!"

Java0
Dalvik/1.2.0 (Linux; U; Android 2.2; Nexus One Build/FRF72)
Dalvik/1.2.0 (Linux; U; Android 2.2; Nexus One Build/FRF50)
Dalvik/1.2.0 (Linux; U; Android 2.2; Droid Build/FRFxx)
Dalvik/1.2.0 (Linux; U; Android 2.2; Droid Build/FRF57)
Dalvik/1.1.0 (Linux; U; Android Itfunz2.1_Eclipse_Terminator; Milestone Build/SHOLS_U2_02.31.0)
Dalvik/1.1.0 (Linux; U; Android 2.1; Nexus One Build/ERD79)
Dalvik/1.1.0 (Linux; U; Android 2.1; HTC Legend Build/ERD79)
Dalvik/1.1.0 (Linux; U; Android 2.1; Eris Build/ERD79)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; YP-MB2 Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; XT800 Build/TITA_M2_16.12.4)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; XT720 Build/STSKT_N_79.22.39R)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; XT720 Build/STSKT_N_79.11.36R1)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; T-Mobile myTouch 3G Slide Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; SPH-M900 Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; SKY IM-A600S Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; SHW-M100S Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; RBM2 Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; PC36100 Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Nexus One Build/ERE36B)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Nexus One Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Nexus One Build/EPF30)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Nexus One Build/EPF21B)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Nexus One Build/EPE54B)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Milestone Build/SHOLS_U2_02.34.3)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Milestone Build/SHOLS_U2_02.34.0)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Milestone Build/SHOLS_U2_02.31.0)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; HTC Magic Build/EPE54B)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; HTC Legend Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; HTC Hero Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; HTC Desire Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; HERO200 Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; GT-I9000 Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; GT-I5700 Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Droid Build/ESE81)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; AOSP on XDANDROID MSM Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Ally Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; ADR6300 Build/ERE27)
Dalvik/1.1.0 (Linux; U; Android 2.1-update1; Acer Liquid Build/ECLAIR)
Dalvik/1.1.0 (Linux; U; Android 2.0.1; A853 Build/SHLA_U2_02.01.0)
 
Bingo! I found it. I decided to try the direct approach, hunt down someone with an Evo, and get them to run the app while I watched the logs. Here it is:

(drumroll....)

"Dalvik/1.1.0 (Linux; U; Android 2.1-update1; PC36100 Build/ERE27)"

Best of all, he said it worked perfectly. So I've now confirmed at least one Evo user who's not having problems :)


Update: it turns out, it really was just a very, very few (but very, very vocal) Evo owners with weird configurations. Overall, the Evo users seem to have fewer problems overall than ANYONE. Unsurprisingly, the group with a 100% failure rate so far (dying after the first web service call, but before the second web service call... the point when it stops until it gets a valid location from the network location service) seems to be almost entirely comprised of Samsung Galaxy phones (I didn't think they were even OUT yet anywhere). I was initially shocked to discover that the second-worst group seems to be Droid owners. However, I did some traceroutes on the IP addresses, and it looks like they're actually Droids that got rooted & reflashed to (sort of) work on carriers besides Verizon, like Metro PCS and US Cellular. In that scenario, it makes perfect sense... they're probably still trying to get location info from Verizon, and getting ignored (assuming their traffic even makes it to Verizon's servers in the first place). Either way, the whole current location implementation is going out the window in another week or two :)
 
Last edited: