I've been working on fixing the GPS data validity bug (where positions are reported at a lat/long of approximately 0,0 prior to lock)
Attached is a version of libhardware_legacy.so that should do the following:
Improve debugging of GPS operation (change printf()s in the main GPS library file to Android logging macros)
Fix/workaround the 0,0 bug (I say workaround because I have yet to identify the root cause of the issue - however it is "fixed" from the point of view of an end user
A few "under the hood" cleanups/fixes
Things that are NOT implemented/fixed in this library:
XTRA (driver/library support for QuickGPS data loading)
Obtaining satellite status prior to GPS lock on Rhodiums (behavior on non-Rhodium unknown, but this should not change actual behavior at all except for the false 0,0 fixes)
Any methods for improved lock speed - all this does is prevent you from appearing south of Africa prior to lock
To test this fix (Intended for FRX05, may work with other 2.2.2 based builds that are derived from xdandroid FRX05):
Unzip the attached zip file
Place libhardware_legacy.so somewhere on your SD card. For organization, I use bindfiles/system/lib/libhardware_legacy.so
Open conf/froyo.user.conf in your favorite text editor
Within the custom_shells{} section of froyo.user.conf, add:
mount --bind /sdcard/bindfiles/system/lib/libhardware_legacy.so /system/lib/libhardware_legacy.so
Restart, and at this point:
1) 0,0 false locks should go away
2) You'll see lots of new GPS debugging info in ADB logcats
Edit: For testing, I usually use the "GPS Status and Toolbox" app from the market, since Google Maps does not show sat status.
With the stock GPS libraries, GPS Status and Toolbox will immediately report a 0,0 fix on startup
With this library, you should see that funky "wait for it circle" in the lower status area until you are locked. As mentioned above - you will not see satellite signal strength reports prior to lock
I was just looking at setting up the kernel build environment myself the other day.
The main useful reference I found was this:
http://forum.ppcgeeks.com/tp2-andro...modules-tinboot-nand-boot-more-beginners.html
However, that one's a bit of a firehose, too, since it deals with a lot of stuff specific to NAND.
In short clone these two repositories into the same directory:
Code:
git clone git://android.git.kernel.org/platform/prebuilt.git
git clone git://gitorious.org/linux-on-qualcomm-s-msm/linux-msm.git
The first is the vanilla kernel, and the second is the XDAndroid kernel modifications. You'll need the first to compile.
From that guide, compile:
Code:
cd android
mkdir modules
cd linux-msm
make clean
make ARCH=arm htc_msm_android_defconfig
make ARCH=arm CROSS_COMPILE=~/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- INSTALL_MOD_PATH=~/android/modules zImage modules modules_install
Follow that guide for putting together the modules for wifi and the location of your compiled files.
Thanks! I will take a look at that, although I get the impression from reading through things that that GPS handling is at a layer somewhere above the kernel but below where we start having to deal with Java. I just can't quite figure out where since I have never done any Android development before.
I am probably going to poke at the kernel at some point though to try and fix the LED behaviors. It is clear from the "sleep of death fix" test kernels that there is knowledge of how to change these behaviors - at the very least I want to make it turn things *off* when in deep powersave. (Seems nonsensical to me to indicate that the device is in a deep power save mode by turning on a bright power-burning LED, although maybe the LED consumption is negligible even when the device is asleep.)
Entropy512 said:
Thanks! I will take a look at that, although I get the impression from reading through things that that GPS handling is at a layer somewhere above the kernel but below where we start having to deal with Java. I just can't quite figure out where since I have never done any Android development before.
I am probably going to poke at the kernel at some point though to try and fix the LED behaviors. It is clear from the "sleep of death fix" test kernels that there is knowledge of how to change these behaviors - at the very least I want to make it turn things *off* when in deep powersave. (Seems nonsensical to me to indicate that the device is in a deep power save mode by turning on a bright power-burning LED, although maybe the LED consumption is negligible even when the device is asleep.)
Click to expand...
Click to collapse
Whoops, didn't read carefully enough at where you'd narrowed the problem down to. I haven't gotten around to setting up an environment for the system build yet, sorry I couldn't be more of a help!
Yup, http://gitorious.org/xdandroid/hardware_libhardware_legacy/blobs/master/gps/gps_msm7k.c is my first target. There may also be issues in gps-rpc.c
http://xdandroid.com/wiki/Getting_the_Source goes thru how to build the system image. It starts with getting the source and cascades all the way thru building a system image.
I'm setup to build it as well, and I've always wondered how we could fix this problem... Love to see it squashed!
Thanks! I'll start working on that, although probably not until after the weekend is over at this point.
The ghetto approach as an interim fix would be to not set GPS_LOCATION_HAS_LAT_LONG if both are exactly zero - This is not the right way to do it, but the chances of it affecting anyone before a proper validity condition is identified are slim. (Even if you ARE near lat/long of 0/0, there will be enough noise in the GPS solution that you'll almost never actually be blanked).
Probably should assume that all of the other validity flags should not be set if we don't have a position fix. (Assumption: The MSM7k GPS does not take inputs from the magnetometer or accelerometer, if the Rhodium even has a magnetometer, didn't think it did.)
Of course, I haven't quite figured out how GPS_LOCATION_HAS_LAT_LONG and such roll up to higher levels. There's some odd interactions in terms of when SV status becomes available, for example.
Entropy512 said:
Thanks! I'll start working on that, although probably not until after the weekend is over at this point.
The ghetto approach as an interim fix would be to not set GPS_LOCATION_HAS_LAT_LONG if both are exactly zero - This is not the right way to do it, but the chances of it affecting anyone before a proper validity condition is identified are slim. (Even if you ARE near lat/long of 0/0, there will be enough noise in the GPS solution that you'll almost never actually be blanked).
Probably should assume that all of the other validity flags should not be set if we don't have a position fix. (Assumption: The MSM7k GPS does not take inputs from the magnetometer or accelerometer, if the Rhodium even has a magnetometer, didn't think it did.)
Of course, I haven't quite figured out how GPS_LOCATION_HAS_LAT_LONG and such roll up to higher levels. There's some odd interactions in terms of when SV status becomes available, for example.
Click to expand...
Click to collapse
Yup, definitely no magnetometer in the Rhodium.
Good luck with this, it'll be a nice little fix if you can get GPS to stop reporting locks before it has one.
Source downloaded, have a build going. (First an unchanged one...)
I'm working on a Froyo tree for the moment, since I think in the Gingerbread alphas GPS is simply "not working", although the degree of "not working" was not defined. Once I'm more familiar with the GPS handling code I might take a look at how it works for Gingerbread.
A few notes about the Froyo repo in its current state:
The URL for Google Apps that device/xdandroid/msm/unzip-files.sh is outdated. cyanogen-mirror.local.host.name does not exist any more. android.local.host.name does but doesn't have the HDPI Froyo apps. I forget which mirror I used - the list is in the CyanogenMod wiki if you search for gapps
The froyo build scripts direct you to http://source.android.com/download - URL no longer exists, it is http://source.android.com/source/download.html now
The process for installing Sun Java 5 on Ubuntu 10.10 is in the URL above - you need it to do a froyo build.
Also, the wiki instructions are missing lib32readline5-dev as an Ubuntu package that needs to be installed (it's in the source.android.com docs tho) - I'll try to update the wiki later.
Entropy512, glad to see someone is interested in looking at the GPS code. I helped phh with it in the last go around to get the RPC messaging part working working, but nothing has been done since.
The NMEA parsing stuff you see in the current gps lib is unused, all the data comes from RPC. Before getting the data directly from RPC was working, we took advantage of the fact that NMEA is output to smd27 and parsed that string data. In any case, once the GPS is brought up, that NMEA data is still viewable by catting /dev/smd27.
If you want to check out other similar code, look at the vogue gps code. I think it supposed to work pretty well, and the RPC behind it is similar. Theirs is a bit different in that they split the gps processing across the kernel and userland, where ours is all userland.
Ultimately, this stuff needs a bit of a rewrite, because the libhardware_legacy interface to GPS that the current lib is written to, is gone for Gingerbread. If we could just get the RPC stubs generated, we might be able to plug into the reference Qualcomm implementation and take advantage of that well sorted code. Check out the cyanogenmod libhardware gps to see what that looks like.
Thanks for the additional pointers bzo.
I'm at the stage where I managed to build the froyo tree, but have not yet had a chance to test the built system ext2 image. That's a goal for tomorrow.
OK, dumb question - Since I'm now trying to understand that RPC code - Where do all those printfs in gps-rpc.c print to?
edit: Never mind, figured it out - it's buried in the logcat... Was trying to go back in time using Android System Info, but adb logcat lets me view it as it happens.
edit 2: Nope, those are D() statements in gps_msm7k.c - don't know where the printf()s in gps-rpc.c are going - nowhere? Should these be D() statements???
those printfs were from when that code was a console test application. Not surprising that they wouldn't show up by default in the logcat. I'm sure there is some way to make them show up. Dunno off hand, but some googling on android debug logging and redirection of stdout and such may dig up that info.
bzo said:
those printfs were from when that code was a console test application. Not surprising that they wouldn't show up by default in the logcat. I'm sure there is some way to make them show up. Dunno off hand, but some googling on android debug logging and redirection of stdout and such may dig up that info.
Click to expand...
Click to collapse
Ah. That makes sense why they aren't D() statements like in gps_msm7k.c
I tried changing as many of the printf()s to D() macros as I could, I'll test it tonight.
Edit: Had a chance to test it this morning. No output from any of the printf()s that I changed to D()s. Either I did something wrong, or none of those code paths are hit in a no-signal/low-signal situation prior to lock. Doing a make clean followed by a rebuild to make sure.
Those debug statements don't display by default. You'll have to change some compile and/or android settings to have them show up.
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
bzo said:
Those debug statements don't display by default. You'll have to change some compile and/or android settings to have them show up.
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
Click to expand...
Click to collapse
Hmm, got any pointers in this regard? They are working for gps_msm7k.c, but not my changes to gps-rpc.c - these are built by the same Makefile and components of the same library as far as I can tell. Is there a log tag filter somewhere?
Thanks for the mount --bind tip - will try that on my next build attempt.
if you copied over the same #define for D(...) from gps_msm7k.c, it seems like it should work the same in the other file. I haven't looked that much into android logging though.
For some reason my copy-and-pasted #defines for D() were failing.
Using LOGD() directly works.
I'm adding another set of LOGD()s now - It appears that something is calling update_gps_location() with bogus data.
BINGO! - It appears we are receiving PDSM_PD_EVENT_HEIGHT and PDSM_PD_EVENT_VELOCITY events prior to a position fix. No clue why - but even though GPS_LOCATION_HAS_LAT_LONG is not set, apps assume lat/long is valid when an update_gps_position() callback occurs.
Going to make it so we only do the update_gps_location() callback when GPS_LOCATION_HAS_LAT_LONG is set. Also going to try and figure out the right situations where we can call update_gps_svstatus() - right now it is only done when we get a PDSM_PD_EVENT_POS.
bzo said:
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
Click to expand...
Click to collapse
This is a good suggestion, but the bind mount statement would go in the froyo.user.conf, not the startup.txt .
arrrghhh said:
This is a good suggestion, but the bind mount statement would go in the froyo.user.conf, not the startup.txt .
Click to expand...
Click to collapse
yea, yea, that's what I meant , thanks for the correction
Related
I'm trying to figure out how to write an app that uses HTC API's. Specifically I want my app to switch scenes but I can't figure out how to call in to their libraries.
I unzipped Rosie.apk and it is only resources, no java.
it's the classes.dex
Right but how do I import something from a dex in eclipse and build it?
manicmethod said:
Right but how do I import something from a dex in eclipse and build it?
Click to expand...
Click to collapse
no way.
.dex is compiled, not source.
does java have a way to forward-declare classes so I can tell java they'll be there when it tries to run?
I haven't done much (read: any) actual development on Android yet, as I just got my Hero recently (developing solely on an emulator? ewww), but isn't the typical way of interacting with other applications on Android through Intents and Actions?
Browsing through the AndroidManifest.xml file in Rosie.apk, there seems to be a reference to com.htc.launcher.ThemeChooser.action.theme_change - Maybe this would be a place to start?
Ah yes, I'm still in the mindset of calling other peoples interfaces to do things. Thanks for the tip.
trying to figure out what to do with it will be fun, I'm sure
So com.htc.launcher.ThemeChooser.action.theme_change launches the chooser. I need to be able to change the scene under the covers by telling it what theme to switch to, any one have any ideas?
Glad to see that you made a little bit of progress I did some more searching, but this time in Rosie.odex. I found an ACTION_THEME_CHANGE string. Perhaps it could be something like this:
Component Name: com.htc.launcher.ThemeChooser.action.theme_change
Action: ACTION_THEME_CHANGE
Data: ?
Like I mentioned, I'm new to this stuff I'm not sure if there is a way to log or monitor intents (that would sure make this easy, wouldn't it?).
After looking at this more I think I need to hook into the htc settings content provider and see if I can change the settings like that. I found this in the manifest.xml:
E: provider (line=191)
A: android:name(0x01010003)="LauncherProvider" (Raw: "LauncherProvider")
A: android:readPermission(0x01010007)="com.htc.launcher.permission.READ_SETTINGS" (Raw: "com.htc.launcher.permission.READ_SETTINGS")
A: android:writePermission(0x01010008)="com.htc.launcher.permission.WRITE_SETTINGS" (Raw: "com.htc.launcher.permission.WRITE_SETTINGS")
A: android:authorities(0x01010018)="com.htc.launcher.settings" (Raw: "com.htc.launcher.settings")
so according to http://developer.android.com/guide/topics/providers/content-providers.html it looks like the Uri should be:
Uri u = Uri.parse("content://com.htc.launcher.settings");
except when I try that I get an exception saying that is an invalid URI :\
I'm not sure that it would be a setting. I mean, I'm sure you could find an attribute to set, but I don't think the switch would be instantaneous (likely requiring a reboot to show), unless there is something listening for changes to the settings. I could be wrong, of course.
Figured it out:
final Uri u = Uri.parse("content://com.htc.launcher.settings/widget_workspaces");
And the resulting table has
_id, display_name, created, status, and ancestor_id
So I think I can change status and then figure out how to throw a notify
I guess you were right, it looks like the widget_workspaces table has all the scenes available but the status field doesn't do what I assumed it would, rather it looks like it indicates whether a scene was shipped by HTC, is your saved scene or is unsaved.
I was really hoping this would do it because I don't know where to look now.
Well, looking at the ddms, it seems like I am wrong. It looks like ThemeChooser activity will do the swapping itself after you have selected a different scene. So it doesn't look like you will be able to make use of HTC's packages to do the swapping for you. Unfortunately, the only thing I can think that you could do next, is figure out how it is storing the scenes and load it and call all of the loading functions yourself...
Well, I have no way of calling their loading functions so I guess I'm out of luck :X
Check out smali and baksmali to snoop around in the classes.dex.
P
I used ddx1.7 to snoop in the dex files and found the tables and everything they were storing settings in. Unfortunately it looks like they neither store the current active scene in the table nor have an intent to call that will switch it without popping up the dialog.
It looks like what I want to do isn't possible.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Android on your Windows Mobile HTC Device...
Supports Blackstone, Diamond, Diamond 500, Fuze, Raphael, Raphael 800, Rhodium, Tilt 2 & Topaz
First things first, this post is PURELY an instruction guide for noobies that aims to reflect the latest status and downloads (give or take a day).
I am not an Android developer, I do not create any of this software... this is done by far more talented people than I. This thread is purely to collate the latest info for Android on Windows Mobile HTC devices and make deploying Android on your device as simple as possible.
If you have new information that should be added to the guide (and is relevant for ALL folks) then feel free to add to the thread and I'll update the OP frequently.
These opening few posts should have ALL the latest info you need to get started (no need to trawl through the threads).
The only time you 'might' need to look in the thread is for 'breaking news' info that is no more than a day old...i.e. The Opening Post is the place!
Credits: There are too many to mention, and many are unknown, but basically the guys poring Android to our devices should be thanked, along with all those making the effort to help others test, document, or use their work (along with those who provide answers to the same questions, time and time again). These are the guys who deserve the credit. From memory...
osamaa,
babijoee,
phhusson,
herpez
scanny
klinux
and many more
What's New?
Latest Update: 27 Jun 2010 (V2.5a)
InitRD - 20100611-5816d27 (new)
Rootfs - 20100626-a700154 (new)
System - XDANDROID.2.1.AOSP.21.06.10 + Advanced Task Killer + disabled HW3D + Setup Wizard fix
Kernel - htc-msm-linux @ 201006211555 (No Debug) (new)
Voice search working!
HW3D Disabled (it's problematic on some devices and just doesn't work on Blackstone)
Stopped (I hope) the setup wizard 'conflict' at first boot.
This release is pretty fast (but I'd advise that once installed, you also launch SpareParts, and configure the window animations etc to 'fast'
There is a chance that after installation, some Startup.txt settings MAY be incorrect for your device. If you discover any mistake, PLEASE let me know, I will correct asap. I need your help on this guys.
How To Install (CAB Version)
Step 1 - Prepare your SD Card
Find a nice clean SD card to load Android on.
You can either format your card to get it entirely clean, or you can leave all the files you may already have on there.
*Warning* - If you have valuable data on your card, back it up. Android is usually safe, but if you can't afford to lose the data on your card, don't risk it!
Some cards have difficulty working, there is a POSSIBILITY this is due to the formatting of the card. If in doubt, format to FAT32, not FAT16
Step 2 - Download and install the CAB
Download and install the following 'full package' cab (a collection of ALL the files you'll need to run Android on your device) by clicking the XDAndroid Cab button below.
You MUST install on the Storage Card. The cab file will take a couple of minutes to install Android. Please be patient.
For those that are interested the cab files does the following:
- Installs Android in the root of the SD Card
- Deploys the correct Startup.txt for the device (the user can choose their device type)
- Adds a high res icon for Android in the root of the SD Card
- Installs a shortcut in Program Files named "Android" (launches Haret.exe)
- Installs the high res icon in the registry for WM6.5 users
Step 3 - Run Android
Android is now installed... So launch 'Android' from your Program Files menu in WinMo. Your phone should reboot into Android with 2 quick vibrations.
Have patience... the first time you do this can take a LONG time (3 mins or more). During the first boot on SOME devices, you will be asked to calibrate the screen. This is very similar to Windows Mobile screen calibration (except it's in text mode).
The reason the first boot takes longer is that Android is 'preparing' your device for the first time.
How To Install (ZIP Version)
Step 1 - Prepare your SD Card
Find a nice clean SD card to load Android on.
You can either format your card to get it entirely clean, or you can leave all the files you may already have on there.
*Warning* - If you have valuable data on your card, back it up. Android is usually safe, but if you can't afford to lose the data on your card, don't risk it!
Some cards have difficulty working, there is a POSSIBILITY this is due to the formatting of the card. If in doubt, format to FAT32, not FAT16
Step 2 - Download and extract the ZIP
Download and install the following 'full package' zip(a collection of ALL the files you'll need to run Android on your device) by clicking the XDAndroid zip button below.
You MUST unzip to the ROOT of the Storage Card. The zip file will take a short while to extract. Please be patient.
Once you've extracted the zip:
- Click Auto-Setup.exe to configure XDAndroid for your particular device
Step 3 - Run Android
Android is now installed... So launch 'Android' from your Program Files menu in WinMo. Your phone should reboot into Android with 2 quick vibrations.
Have patience... the first time you do this can take a LONG time (3 mins or more). During the first boot on SOME devices, you will be asked to calibrate the screen. This is very similar to Windows Mobile screen calibration (except it's in text mode).
The reason the first boot takes longer is that Android is 'preparing' your device for the first time.
If you want to exit Android and go back to Windows Mobile, then you need to remove the battery, or press the reset button of your device. Sorry folks, but that's how it is!)
Known Issues
Many things are still not working properly, and the developers are fully aware of 99% of them.
SDCard - Most SDCards are working, but if you the 'waiting for SDCard' message, you should try one of these fixes (and please let us know if it works)
Fix 1: Format your card with this tool http://www.sdcard.org/consumers/formatter/
Fix 2: Edit your startup.txt file and add these entries to your cmdline:
set cmdline "lcd.density=240 msmts_calib=0x395.0x3c9.0x79.0x77 clock-7x00.a11=500 msmvkeyb_toggle=off pmem.extra=1 gsensor_axis=-2,-1,3
msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave"
Fix 3: Tell your wife / girlfriend that you are about to make some modifications to her phone... change the ringtone and steal her old Class 2 SD Card to use with Android. She will never discover what you have done, and if she does, you'll be able to use Android to send texts to your former girlfriends ;-)
Camera - Not working
GPS - Should be working, but it's only just been enabled (so could be buggy)
Battery Status - Highly problematic for most users (don't trust the capacity Android tells you, it's simply up and down a lot, and highly inaccurate)
WiFi - Working for most people, suspected to cause slight heat, definitely drains the battery faster than WinMo. Some users have reported freezes when switching WiFi off
Audio - Speaker working for most people, microphone can have issues
Deep Sleep - Working for most people, but can have issues waking up (sometimes, it will not wake up)
GPRS - Working
3G - Working for most
PIN Code - Not working
GSensor - Working (Screen only handles 0 and 270 degrees)
Bluetooth - Experimentally working (don't expect too much, but it's working for a number of users)
OpenGL ES - Not working
USB - Supported, but will NOT operate in mass storage mode. You can charge via USB and you can debug, but forget accessing your files by it.
Headphone Socket - Semi working (see FAQ for details on how to make it work)
Application Errors: It's very common to see 'Application (xxxxxx) is not responding: Force Close or Wait'. Click wait. I do not know the precise reason for this, but from what I can gather, it COULD be related to the slow speed of the SD Card causing the app response times to JUST be a little too slow for Android's liking, thus causing the message. This seems to happen more after bootup or wakeup when the device is busy doing stuff in the background.
Cannot choose ringtones: This is believed to be caused by the media scanner failing (due to discovering some filenames with none English characters). The best option of all is to use a CLEAN SD Card. But, if you insist on hosting other files on the same SD Card, you MUST make sure they have English character filenames.
Frequently Asked Questions
Where can I download a release?
There are a number of Android releases (all at varying stages of development). Use the search function to locate one, or try these:
http://forum.xda-developers.com/showthread.php?t=621498 (Standard XDAndroid for ALL Devices)
http://forum.xda-developers.com/showthread.php?t=624808 (Customised Android UI for Blackstone)
Both come with very clear instructions on how to install
What features are in a release?
Generally, it's very difficult to detail them, unless there is a significant new feature (in which case, that will be very well advertised!). Usually it's minor speed improvements, bug fixes etc... and sometimes, new bugs are introduced (so bear that in mind)
My SD Card doesn't seem to work, why?
Most SD Cards are working, but if you the 'waiting for SDCard' message, you should try one of these fixes (and please let us know if it works)
Fix 1: Format your card with this tool http://www.sdcard.org/consumers/formatter/
Fix 2: Edit your startup.txt file and add these red entries to your cmdline:
set cmdline "lcd.density=240 msmts_calib=0x395.0x3c9.0x79.0x77 clock-7x00.a11=500 msmvkeyb_toggle=off pmem.extra=1 gsensor_axis=-2,-1,3
msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave"
Fix 3: Tell your wife / girlfriend that you are about to make some modifications to her phone... change the ringtone and steal her old Class 2 SD Card to use with Android. She will never discover what you have done, and if she does, you'll be able to use Android to send texts to your former girlfriends ;-)
How do I turn off, or reboot Android?
You pull the battery, or press the reset button. When a better solution is found, it will be announced.
Q. My phone just went from 50% to 20% in next to no time!
A. OK, this is the MOST important thing to know before you read on....
Currently, you just can't trust the 'battery capacity' being reported in Android. The developers are aware of this and will get it working properly soon, but at the moment, Android is very likely to get the battery capacity very mixed up, and so it's quite hard to prove how long the usage is. Remember, Android can shut down when it THINKS there's low battery, so just leaving your phone and not touching it can still cause a shutdown with plenty of battery left.
If you REALLY need to know the capacity, boot into WinMo (although even this MIGHT be the wrong value if Android has messed up some charging history)... that said, WinMo is definitely reporting much more accurate values, and after a few charges of only using WinMo, the capacity reporting should get very accurate again.
Q. My phone doesn't seem to last very long using these Android builds...why?
A. Firstly, the developers are aware of this, and are working on it. Yes, we all know WinMo holds the power for a lot longer, but that's because they knew the hardware inside out and could get the system to sleep in well behaved ways.
Q. So why can't you just copy what WinMo does?
A. Well, in theory most of what WinMo does CAN be replicated, but the developers have to track down all the chipset information they can, and figure out what WinMo is actually doing to get long life from the battery. Also, Linux isn't Windows, and there ARE differences in how things behave, in some cases WinMo might be slightly better and in others, Linux slightly better, but overall, there shouldn't be too much difference once everything is ironed out.
Q. So what the heck could be eating all the power right now?
A. Well, there's a whole bunch of hardware inside your phone, like CPU, Radio chips (for phone), WiFi chips, GPS chips, accelerometer, light sensor, LCD and Backlight, FM radio, audio chips etc. They all take power if left running, or if the usage isn't optimised.
Slowly but surely many of these components are being supported fully, but at the moment, some of them are 'working' but perhaps not optimally. Meaning they MIGHT be working harder than they need to, or simply not being switched off properly etc.
In addition to this, it's possible that some processes (system, or user apps) might be running all the time and causing a lot of battery use. E.g. animated wallpaper, clock animations, google sync communication, wifi searching etc etc.
Q. My phone seems to get rather warm, why?
A. This has been noticed by many and seems related to WiFi and charging. When both are used together, it would seem that Androids high power consumption and heat generated from charging combine to make the device quite warm.
It hasn't yet been fully established why this is happening, and there doesn't seem to be any serious issue with it (yes it's warmer, but it's not red hot).
If you're worried, avoid using Android with WiFi and charging at the same time, and stick with WinMo for charging, or just avoid Android altogether until you hear about a fix. However, hundreds of users are using the current builds and no failures have occurred, so it would seem 'reasonably safe' to still play around with the builds... and your help and feedback will help to improve the situation a lot quicker!... the choice is yours.
Q. Will the situation EVER be fixed?
A. Yes, I am confident the devs will find a solution. This really isn't a 'can never be solved' issue, it's purely down to time and effort, so don't panic!
Q. How do I make my GPRS / 3G data connection work?
A. For some operators/carriers, you need to run Android, then go into settings, and locate the APN settings. You need to complete the APN settings for your Operator/Carrier/MVNO. You need to find these settings for yourself I'm afraid, it's out of scope for this thread. You might look here http://www.modmygphone.com/wiki/index.php/Carrier_APN_Settings, but Google is your friend.
Q. Are the Android releases available in a ROM?
No, Android is not yet available in a ROM format.
Currently Android is installed by using a clean SD Card, and booted from there.
It is booted by running a special application called 'Haret.exe' residing on your SD Card which will terminate the Windows kernel and boot into Linux/Android.
When will it be available in a ROM?
No time soon. Folks are working on it, but you'll need a lot of patience before it (if ever) arrives
How do I suggest features?
Before you even think about it... ask yourself ONE question... "Do I really think I'm the first to have suggested my idea?" and then ask yourself "And what are the chances of it being read and implemented before all the other issues are fixed?".
If you still feel it wise to ask for a feature.... go ahead. Don't say you weren't warned.
My question starts with the words "When will..." or "When is..." etc
See above, the same applies. Stuff will appear when it appears. Do you really think you're the only person dying to have GPS support, or power off, or stability etc?
Why doesn't the camera work?
It's not yet supported. When it is, it will be announced.
Why isn't GPS working?
GPS has only just been enabled (May 2010), so might still be problematic, however, it's working well for many users.
My battery doesn't seem to last long, why?
There are many reasons... first Android is not yet fully optimised for power management (so it's not YET as good as WinMo), secondly, the battery status is highly problematic for most users (don't trust the capacity Android tells you, it's simply up and down a lot, and highly inaccurate)
Does WiFi work?
Yes, it's working for most people, suspected to cause slight heat, definitely drains the battery faster than WinMo. Some users have reported freezes when switching WiFi off (quite common problem)
Does Audio work?
Yes, speaker working for most people, microphone can have issues.
I keep hearing 'popping/clicking' sounds from the speaker?
This is a known annoyance on some devices, believed to be related to power management switching the speaker on and off (not confirmed), it actually seems worse in silent mode (ironically). If you experience this, you're not alone... most users do. When a fix is ready, it will be announced here.
I can't wake up my device, why?
Deep Sleep is an issue for most people. Sometimes the device WILL wake up from a deep sleep, but sometimes it will not. If you can't wake it up, reset.
Is GPRS supported?
Yes, it works (but you MAY have to input your operator/carrier APN
Is 3G working?
Yes, works for most, although some users are having trouble with Vodafone Netherlands.
Is SIM PIN Code working?
In recent releases, it should be supported for most devices, however, if you have any difficulties with it please DISABLE SIM PIN in WinMo (SIM PIN works on the SIM, but you need WinMo UI to disable it)
Is GSensor working?
Yes, screen only handles 0 and 270 degrees though (so far)
Is Bluetooth working?
No, it's not yet implemented. As soon as it is, it will be announced.
Is 3D Supported?
OpenGL ES is not supported yet. 3D GPU support IS currently being developed and available for some devices, but it's still a bit buggy... so beware.
Can I connect via USB?
Yes you can, but will NOT operate in mass storage mode. You can charge via USB and you can debug, but forget accessing your files by it.
Is the Headphone Socket working?
This is being worked on, with mixed results, so the situation can change very often.
Initially, you should just try and see, but if you have no success, try to activate it with a special command:
For USB headset, add the following line to startup.txt...
snd.force_headset=1
For 3.5mm headset, add the following line to startup.txt...
snd.force_headset=2
You MAY have to make a call for the settings to actually be activated (a real pain), but that's how it is so far!
'Application (xxxxxx) is not responding: Force Close or Wait' keep appearing on my screen!
Click wait. I do not know the precise reason for this, but from what I can gather, it COULD be related to the slow speed of the SD Card causing the app response times to JUST be a little too slow for Android's liking, thus causing the message. This seems to happen more after bootup or wakeup when the device is busy doing stuff in the background.
I am having trouble with ringtones, why?
This is believed to be caused by the media scanner failing (due to discovering some filenames with none English characters). The best option of all is to use a CLEAN SD Card. But, if you insist on hosting other files on the same SD Card, you MUST make sure they have English character filenames.
I seem to be able to boot Android, but then get a black screen after all the white text, why?
This is a recent issue with the 3D hardware support... sadly it's a little complicated... SOME devices need to be put in 3D mode BEFORE you launch Android, and some devices need precisely the opposite.. NO 3D access before you launch Haret.... So...
To avoid using 3D...
1) Turn off Sense/TouchFlo in WinMo.
2) Reboot
3) Launch Android again
4) At the black screen.... WAIT for 2 mins, it should boot
To use 3D...
1) Run any 3D app / game (I THINK Teeter will work, need to be confirmed)
2) Launch Android
3) You will need to do this EVERY time you launch Android
Reserved for future use
Reserved for future use
Reserved for future use
The first Eclair thread mentioned that it would be better to change the lcd.density in the startup.txt from lcd.density=210 to lcd.density=240 though both work fine on my phone.
bakkiethee said:
The first Eclair thread mentioned that it would be better to change the lcd.density in the startup.txt from lcd.density=210 to lcd.density=240 though both work fine on my phone.
Click to expand...
Click to collapse
Hadn't got around to adding that bit, but have now!... 240 works best, since some apps don't use the full screen as they should.
Thank you very much. Just what was needed.
H
Thanks for this Thread!!
Great work!
I tried the version from the other thread (http://forum.xda-developers.com/showthread.php?t=603813) a week ago and there is a special startup.txt where you have to put your WIFI-MAC-adress in.
Isn't it required in this version?
Do you only have to put this 7 lines in it you postes below?
Greetz Rodix
Rodix85 said:
Thanks for this Thread!!
Great work!
I tried the version from the other thread (http://forum.xda-developers.com/showthread.php?t=603813) a week ago and there is a special startup.txt where you have to put your WIFI-MAC-adress in.
Isn't it required in this version?
Do you only have to put this 7 lines in it you postes below?
Greetz Rodix
Click to expand...
Click to collapse
no longer required.
The 3.5 mm jack still does not work propperly. Previous thread had a few cuestions about that. you may want to ad that to the list.
Maybe you haven't noticed. But it's 2010 now.
It's hard to get used to... I know... xD
Zailynne said:
Maybe you haven't noticed. But it's 2010 now.
It's hard to get used to... I know... xD
Click to expand...
Click to collapse
OMG! lol I'm still hungover from Xmas ;-)
TheBrilliantMistake said:
OMG! lol I'm still hungover from Xmas ;-)
Click to expand...
Click to collapse
Hahaha, well now you know!
Weird thing
been using a while from previous posts, fine but a bit jittery. Decided to change the startup text to yours as looked simple and might make it smoother as not sure if one I was using was designed for Blackstone.
Cant get off the lock up screen as the screen seems to think my finger is in the oposite corner that it is!!!!!! ie the touch sensor is a mirror image but the screen isnt
hmm somehow its ****ed up, if i need to press the lower right corner on my touch screen i have to press on the upper left cornor, somehow the touchscreen isnt working right, any ideas?
Kryston said:
hmm somehow its ****ed up, if i need to press the lower right corner on my touch screen i have to press on the upper left cornor, somehow the touchscreen isnt working right, any ideas?
Click to expand...
Click to collapse
Yeah, try reading the post above yours
Thanks for this thread!
A small bug report:
When disabling that app's are allowed to synchronize while roaming, they're supposed to "ask" whether they can use the internet or not. This popup dialogue never appears, but is hidden in the background. This seems to be a problem with other popups too.
Oh, and adding
Code:
mddi.width=480 mddi.height=800
to startup.txt made the touch screen (much) more accurate for me.
EDIT: in the "set cmdline"
got my screen working, just use the startupfile which is in the .rar data.
but i got a question, is it possible to import your contacts?
somehowe i cant import from sim card, it says importing.... but if its done there are no contacts.
Kryston said:
but i got a question, is it possible to import your contacts?
somehowe i cant import from sim card, it says importing.... but if its done there are no contacts.
Click to expand...
Click to collapse
If you mean to import your contacts from WindowsMobile to Android, than (probably) the most convenient way is to use Google sync facility.
From WindowsMobile you do as described here:
http://www.google.com/support/mobile/bin/answer.py?answer=138636&topic=14299
And from Android you just activate your Google account - it will sync contacts (and calendar) automatically.
PS: Un-check Tasks synchronisation (as in the instructions screenshot) - it usually results in error message and synchronisation stops.
Seriously, actual technical discussion this time.
Continued from the other thread:
READ THIS FIRST:
ace42588 said:
If the phrase "I don't know if anyone has tried this..." appears in your post, stop. Read both threads. Reconsider your post. Your post should no longer have that phrase and wont waste space.
If the phrase "I don't know, but..." appears in your post, stop. Find out. The interwebz is amazingly useful for learning things. Reconsider your post. Your post should no long have that phrase and you will sound knowledgable and educated.
If you don't have any idea how an exploit is supposed to work, please don't suggest it. Look it up. If it sounds applicable to the G2, proceed to share.
Click to expand...
Click to collapse
What we know now:
- The eMMC supports setting a range of blocks temporarily or permanently read-only. That seems to be the case for the bootloader, /system and recovery.
(From the datasheet: Specific segments of the iNAND may be permanently, power-on or temporarily write protected. Segment size can be programmed via the EXT_CSD register.)
- The reason we can write to /system using "temproot" is that it is getting cached by linux. (Write-through, so the card is accepting and discarding writes but we are seeing the cached version only.) Flushing the cache removes all changes from system and upsets the kernel.
- Because no changes are making it to the actual flash, rebooting removes all updates. It is not being magically reflashed.
- It is not a rootkit. It is the OPPOSITE of a rootkit. Rooting it is much much more like a rootkit. Seriously.
- OTA isn't an answer. It isn't even helpful. The way it works: update.zip is downladed, and the key checked. saved to /cache, and an update script is written. it reboots to recovery. recovery checks the keys again, then runs the script to install it. there's no exploitable action there. It doesn't unlock the emmc, etc.
The eMMC security standard (pdf) and specifically, the parts applying to write protection
And the SanDisk part manual/datasheet
Some pieces of the current state are accessible from fastboot, or by mounting debugfs.
Status Blocks:
CSD and decode
Decode of EXT_CSD (via "fastboot oem get_ext_csd_emmc")
EXT_CSD (raw) while the phone is running
Some notes concerning the above
Useful flags in the security standard, specifically relating to temporarily and permanently write protecting regions of flash.
CMD29 is clear write protect. Hmmmm...
Or we might permanently writeprotect it. Or permanently -block- write protection.
Can a kernel module just reset the WP blocks? maybe (more info here) and the value should be "d00f00320f5903fffffffde0124040c8"
If we have to reset the controller, here is how
Examinations of the cache behavior, rmt_storage, etc.
If you have other updates, stick the links in the replies. Also, there is a wiki being set up.
Currently (10/9) we're looking at either resetting the part (and then reconfiguring it to get it out of boot mode - page 38 in the spec) or chewing up the bootloader.
Alternate approach by lbcoder - apply the leaked engineering bootloader as an update, convincing the system via misc that it has already passed signature validation:
Kinda unrelated, but here is HTC's response to their gpl violation. And finally, here is their possibly-accidental source code release.
Edit: What I posted is now in the above post. Just trying to help. I have faith in you guys to get root.
CHANGELOG:
- 10-08 18:32 wiki link fixed
- 10-08 22:07 added the cache examinations
- 10-09 13:45 added the disclaimer and the currently-trying
- 10-13 10:11 add CSD decode
- 10-14 09:37 add kernel source
mrozzeh said:
rmt_storage was basically just proof to me that there was a write-back issue in place.
Part of the bootloader's preboot sequence is a call to mpu_emmc_protection(I believe that is what its called off the top of my head), followed by a call that sets up the physical nand protection that we're already used to. Setting superCID or S-OFF would disable those calls, which would kill the ramfs and allow physical access.
Click to expand...
Click to collapse
Ah, ok this makes sense to me. Basically you are changing the time of the attack to earlier on in the life-cycle. I agree that disabling write-protection while the phone is operational (after boot) could be problematic (because we seem to have cached writes).
So what you're suggesting is that we turn off protection earlier on (in the bootloader)?
Oh by the way, there's no point writing that value (that I mentioned earlier) to the CSD register since those bits are RO.
vi5in said:
Ah, ok this makes sense to me. Basically you are changing the time of the attack to earlier on in the life-cycle. I agree that disabling write-protection while the phone is operational (after boot) could be problematic (because we seem to have cached writes).
So what you're suggesting is that we turn off protection earlier on (in the bootloader)?
Click to expand...
Click to collapse
It may be that it can't be turned off at all once it is turned on (eg if we can't get the chip back into a sane state after a reset), so it is possible that the only time we can turn it off (or rather, not turn it on) is bootloader.
The cached writes issue is easy to deal with - there is no reason to ever remount it read/write, so there are no cached writes pending. (There is a red herring from earlier - htc didn't set it up read/write, that is a side-effect of a typo in the 'root' script from the directions thread. The last line attempts to put it back to read-only, but fails because it uses android mount instead of busybox mount.)
The wiki link is broken.
Maqr said:
The wiki link is broken.
Click to expand...
Click to collapse
Wiki is now here.
Now im not a dev by any means.
let me see if i have this right:there is a read only file that contains the "primary" android system files and we cant modify that and it gets re applied everytime the phone is restarted.henchforth makeing the phone unrootable. now logically speaking the area had to at one point been writable, and has since been locked by a command, of which we cant find. and the mmc has a little todo with the whole process. so its safe to say that it might be one of the "key" components. just looking at the design of the phone and with what looks like a back cover sensor on the lower of the hinges on the back cover. Now the command to read the read only part of the phone is looking like what we have to get too to change where it is looking for the sys info to allow us perm root. i have a g2 and am excited on the amount of skill comming to gether to get this done.
Always willing to donate for a good cause, let me know if we need to get a pot going to buy someone a G2 like JesusFrekee.
Maybe HTC wants to force use inside the G2 so we void warranties. Jtag adapter, or a hardware related jumper/mod.
Someones gonna need a G2 bought by the community that they are not going to mind tearing apart
jeagoss has already torn one apart and JTAGed it and has been poking around
Sorry to dig up old info from the other thread, but I couldn't help but notice a few things here:
Disconn3ct said:
Where do you think the ramfs is coming from, as opposed to a write-through cache? It certainly behaves like a cache. (Not disagreeing that it gets set early. And if we can't get the bootloader, replacing recovery might be enough - it has to be r/w when starting recovery for OTAs to work, so the bootloader can behave 'as designed'.)
rmt_storage_client_txt (and the source)
this post shows changes disappearing after a cache flush (easily verifiable) and memory use going up as data is 'written'.
changes disappear "randomly" over time - ramdisk maintains data.
Where is the info that got you thinking rmt_storage creates a ramdisk? I saw something about that a couple days (and dozens of pages) back, but it didn't pan out. Did we miss something?
Click to expand...
Click to collapse
I think there is an interaction between rmt_storage and the actions of the radio/mmc interfering with the temp root. rmt_storage is certainly being used as a proxy to communicate with the storage in some way. Not as a ram-disk, but as an overlay to the visible partitions that are on lock-down. Your observations of free memory being clobbered by big writes to protected partitions could very well be linux caching the writes - because there's simply nothing better to do with that memory at that moment in time. However, as rmt_storage continues to communicate with other parts of the system, the trigger to flush cache as it sees fit may very well be sent through the RPC mechanism. It does not exactly explain the cache flush scenario, unless rmt_storage sends a message to clear all volatile blocks at that time. Any way you slice it, rmt_storage has a lot to do with the overlay, and probably nothing to do with the lockout.
mrozzeh said:
rmt_storage was basically just proof to me that there was a write-back issue in place.
Part of the bootloader's preboot sequence is a call to mpu_emmc_protection(I believe that is what its called off the top of my head), followed by a call that sets up the physical nand protection that we're already used to. Setting superCID or S-OFF would disable those calls, which would kill the ramfs and allow physical access.
Click to expand...
Click to collapse
This makes sense to me. Coming from a N1, I did the locked bootloader root via SDcard trick a few months back. This explains why HTC has blocked adb from communicating with the device while in recovery mode. The same trick would presumably work if they left it open.
So....
It seems we have some evidence that the lock happens during the early stage of the boot sequence. From here, it is likely that rmt_storage plays a role in how the overlay/cache/whatever is reverting writes over a period of time. But it does not appear to have anything to do with the security lock-out.
With no recovery vector to exploit, this leaves us with few options. I would put my money on exploiting the pre-boot process (possibly with a race condition exploit similar to what we have seen with other recent HTC devices) and either preventing the partitions from being write protected *or* disabling the security outright. I have yet to see any evidence that we can disable the write lock from userspace *or* kernelspace - only speculation.
Re-read rmt_storage_client.txt - it seems likely that this is what we are observing with the rooted units degrading over time. rmt_storage sends RPC calls, stuff happens, filesystem overlay changes disappear. Once the kernel is up, this is *the only* interface to restricted parts of the storage system.
Based on the rmt_storage_client.txt you linked, rmt_storage provides storage access to the radio / modem processor via RPC since it doesn't have any direct way to access emmc, rmt_storage doesn't sound like it's doing anything for the application (the one android runs on, we root, etc) processor.
It's not impossible that it might somehow be exploitable in some fashion but I glanced through the code and nothing jumped out at me as doing anything interesting.
HamNCheese said:
This explains why HTC has blocked adb from communicating with the device while in recovery mode.
Click to expand...
Click to collapse
But wait- don't you remember the part when T-Mobile said that the inability to save changes is a mere side effect of HTC's security measure intended only to prevent "key operating software from becoming corrupted and rendering the device inoperable"?
And their 90-120 day delays are totally "within the requirements of the open source community", no matter what the GPL might say.
I'll keep looking here.
W
biosehnsucht said:
Based on the rmt_storage_client.txt you linked, rmt_storage provides storage access to the radio / modem processor via RPC since it doesn't have any direct way to access emmc, rmt_storage doesn't sound like it's doing anything for the application (the one android runs on, we root, etc) processor.
It's not impossible that it might somehow be exploitable in some fashion but I glanced through the code and nothing jumped out at me as doing anything interesting.
Click to expand...
Click to collapse
My understanding is that the eMMC is abstracted since it is not yet directly supported by linux. Therefore, the radio would be the next logical choice for accessing it.
rmt_storage = remote storage. Keep in mind that we're dealing with a new SOC - it's perfectly reasonable to assume it has the ability to access eMMC on its own. RPC via rmt_storage is a likely suspect. It would also explain where the missing space went.
You have it backwards. Read the beginning of the rmt_storage doc. The radio can't access it so it makes rpc calls to linux so that linux can handle read/write for it. It is well documented. Seriously people. Stop guessing and do a little reading..
Subbed for updates. I'm not good at this stuff. So I'm reading trying to learn.
Sent from my T-Mobile G2 using XDA App
HamNCheese said:
My understanding is that the eMMC is abstracted since it is not yet directly supported by linux. Therefore, the radio would be the next logical choice for accessing it.
rmt_storage = remote storage. Keep in mind that we're dealing with a new SOC - it's perfectly reasonable to assume it has the ability to access eMMC on its own. RPC via rmt_storage is a likely suspect. It would also explain where the missing space went.
Click to expand...
Click to collapse
the emmc is very directly supported by linux.
the radio does not have the ability to talk to the controller, that is why its storage must be proxied through one of its mailboxes to the kernel, and then to the userspace client.
i don't believe it's related to our root issues.
I own a Droid X and I hope you guys have more success with the G2 than the X community has had unlocking our bootloader. In the long run though, the manufacturers will win the battle of locking devices. The answer to this problem is really to stop buying locked devices. Not much chance of that happening either. A pretty depressing picture for the time being and short term future.
burpootus said:
I own a Droid X and I hope you guys have more success with the G2 than the X community has had unlocking our bootloader. In the long run though, the manufacturers will win the battle of locking devices. The answer to this problem is really to stop buying locked devices. Not much chance of that happening either. A pretty depressing picture for the time being and short term future.
Click to expand...
Click to collapse
Its truly my belief that they do these things to prevent having to fix peoples rooted phones... android, with its open market and cross-hardware nature, are already a big risk for manufacturers but fortunately they have given it a shot (and we have rewarded that)
If you were truly passionate about having an unlocked phone, vote with your dollar and buy a dev phone like the new nexus one dev phone.
Otherwise.. pay less and work for root.
Sent from my T-Mobile G2 using XDA App
Hah web2go is 'key operating software' ? I call BS
VValdo said:
But wait- don't you remember the part when T-Mobile said that the inability to save changes is a mere side effect of HTC's security measure intended only to prevent "key operating software from becoming corrupted and rendering the device inoperable"?
And their 90-120 day delays are totally "within the requirements of the open source community", no matter what the GPL might say.
I'll keep looking here.
W
Click to expand...
Click to collapse
Sent from my T-Mobile G2 using XDA App
Hey everyone, I've been a lurker for quite sometime, so I'm finally posting something. This is isn't in any of the dev sections because this is my first post.
When I first got my GNex (toroplus) was very annoyed with the capabilities of the gsd4t gps chip. Static navigation makes it really hard to use the chip for telemetry projects and the 1Hz position update doesn't give me enough sample data for the things I'm working on. I decided to do some investigation to see if it was limited to the hardware itself or the driver.
I scoured the forum, and tried a bunch of apps, found datasheets and the what not and nothing really improved my situation. I decided to take matters into my own hands and poke around lib_gsd4t.so (stock).
With verbose logging turned on, I noticed an interesting looking entry.
Code:
Hello EE downloder !!!.
{sgee.samsung.csr.com, instantfix.csr.com}, port : 80
Y3Nyc2xsOmROTkw5NnN1, /diff/packedDifference.f2p3enc.ee, format 2
EE_DOWNLOAD: EE_Download_Init done.
EE_Download_Init - returned 0 !!!.
EE_DOWNLOAD: EE_Download_Start successful.
EE_DOWNLOAD:EE_Download_Scheduler started; server_address=(sgee.samsung.csr.com,instantfix.csr.com), port=80, file=/diff/packedDifference.f2p3enc.ee
...
The string Y3Nyc2xsOmROTkw5NnN1 really stuck out to me. The character set fit in the base64 space which for some reason or another, developers seem to think base64 encoded text is somehow a good way to make things more secure. I have seen this numerous times. To me, it just makes it more noticeable that someone is trying to hide something.
So I went ahead and decoded the string and got
Code:
csrsll:dNNL96su
Just to be sure it wasn't some string unique to my phone, I checked where it most likely came from, which is the lib_gsd4t.so and it is indeed there (@offset 0x1b7429).
What's so special about that string?
I'm almost 100% sure that it is the username : password combo for downloading the SGEE data. I'm guessing it is using a post request (anyone wanting to use wireshark to packet sniff this can confirm) because there are extra parameters being used to retrieve the data.
Have I tried to access the file with those credentials?
No.
Why am I posting this?
I thought it was funny that the username and password are hardcoded in the driver and written to the logs. What's the point of having it password protected if you're just going to tell everyone the account credentials?
My actual job involves application security and I used this as an example for the other programmers on my team as to why we shouldn't ever mistake encoding for encryption and if you try to hide something, chances are you are actually drawing attention to it.
Oh also, is anyone interested in knowing more about the library. I have figured out quite a bit
How odd!
If you've figured out the gps drivers maybe you know how to make an updated file to disable static navigation? I op'd this thread http://forum.xda-developers.com/showthread.php?p=38684789 based on the ics version, but would love an android 422 based mod.
I posted my modded drivers. It may also require new configs.
afrotronics said:
I posted my modded drivers. It may also require new configs.
Click to expand...
Click to collapse
Did you ever figure out the proper request? (curl or wget?)
I am trying to write a module that hooks (first off all, later only specific) in/output streams and readers/writers to analyze the content.
First try was to hook java.io.Reader.read with all 3 read method signatures - this didn't show very much, so I guess it only hooks real java.io.Reader, and every method who overrides the specific method without calling super will not get hooked.
So I tried to just get all classes and look, if they are java.io.Reader.class.isAssignableFrom(every_single_class) //all classes that extend Reader, or a check if Reader r = new c();
- it turned out it is harder than i thought to get all loaded classes from a classloader.
Tried so far:
1. In desktop-oracle-java you could, via reflection, make the classes-field of a classloader (from the LoadPackageParam lpparam) visible, and it would contain an array of all classes. Android Java does not have this - this field simply doesn't exist.
2. Digging deeper into the android source, it seems like the VMClassLoader inside the normal classloader handles this, but it internally it calls a native loadclass method, so I can't access this data here.
3. My next try was to use the reflections.org lib (pulled via maven) - and every suggested method like getSubTypesOf(Object.class) and many others.
4. Now i tried to hook loadClass of classLoader, but this seemed to lead to an stackoverflow or something like that, i think.
5. I also tried to hook findClass of classLoader, but it seemingly never gets called?
So, what is the correct way to get all subclasses of java.io.Reader (inside a specific classloader) in XPosed framework? To me, it doesn't seem to be a too weird feature to have.
Also: Is there a way that I don't have to restart my phone after every new app version? Or to at least disable the "optimizing 100 apps" on every third boot. (Carbon rom, Android 5.1)
bump. im also interested in this
Very interestd topic!
I found a github project that should be able to do this, and I think I also found the according class.
github.com/baer-devl/DAMN/blob/master/src/at/fhooe/mcm14/damn/xposed/XHookAll.java (i'm currently not allowed to post real links because <10 posts)
There is also a 90-pages master thesis with about ~10 pages about hooking. If someone is interested, I can ask if the author allows to publish/upload it.