Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Zeta0134

Pages: [1]
1
iPhone 3G / Android Corruption, Possible Fixes?
« on: December 09, 2010, 07:25:16 AM »
Inevitably it happens. On the 3rd or 4th APK I try to run today, something doesn't like someone deep in the kernel, they have a fight over it, one process divorces another, and the phone hangs. Waiting doesn't fix it, they've moved out of the country and aren't coming back, and none of the buttons on the phone seem to respond. I'm forced to hard-reset.

Now, there's two possible outcomes here. On the one hand, it could boot, do a quick filesystem check and work just fine on its merry way. That happens about 10% of the time. The rest of the time it boots, complains about 5-7 different processes quitting unexpectedly, and the only way to fix iDroid at that point that I've been able to find is to reinstall it using Bootlace. That's nice, but it undoes all of my work and I have to go reinstall all my apps and reconfigure everything and it's a general pain.

Is there any hope? Is it possible to recover from a hard-reset without doing a full reinstall, or is there some known issue that prevents this from being a fixable problem? What steps might I go through to un-corrupt my poor device in case of these internal conflicts? (part of this is me figuring out what works and what doesn't, I'll be able to avoid the lockups alltogether eventually.) This usually happens when I'm using a new .apk that I'm trying out, or (in today's case) when accessing stuff on the phone that doesn't work yet, like the Gallery.

-Zeta

2
iDroid Development / Status of CPU Standby Progress?
« on: October 28, 2010, 07:01:48 PM »
What's the current development status of CPU standby, as a component of the larger Power Management puzzle?

As I understand it, the iPhone's processor can have its clock adjusted, and iOS will downclock when going into standby to conserve power. There are numerous tutorials on 'overclocking' the device from iOS by manipulating a settings file. Do we currently know how this is done on a hardware level? Like, is it a matter of 'we don't know how to do this' or more a matter of 'we're working on integrating this into the Android kernel'?

Also, side question: is it possible to turn the CPU off completely? Would there be some way to wake it on interrupt, like on keypress or network activity? That would be most ideal, I'd think, but I don't know if the hardware supports it. (I remember from working with ARM in the DS that it could do an interruptable sleep, but I don't know if the ARM in the 2G/3G supports that, or what interrupts the hardware has available.)

-Zeta

EDIT: Some reading on the ARM1176JZF-S datasheet suggests that there is an opcode (Wait for Interrupt, still reading the sheet) for just such a purpose, so I'm going to wager a guess that it's far more complicated than that.

3
General discussion / Touchscreen Issues?
« on: October 28, 2010, 06:24:00 PM »
Is anyone having pretty significant touchscreen issues on MoJo 1.0.3? My touchscreen is 'working', but not consistently: I frequently have to press a button multiple (>10 sometimes) times before it will register, and getting it to register a drag is a pain. I've found that using more pressure than I would normally need to use in iOS is somewhat effective, but it only helps a little bit.

Is this a known issue? Is there possibly a workaround, or is everyone experiencing the same issues?

-Zeta

4
iDroid Development / Ad Hoc wpa_supplicant for iDroid?
« on: October 25, 2010, 03:52:24 PM »
Hello all. I just updated my iDroid installation to MoJo 1.0.3, and I'm loving it. It's much, much more usable than it was previously, and Froyo has enough improvements over 1.6 that it feels like a new project entirely. I know it's not really, but hush and let me compliment the dev team here, sheesh. ^_^

Anyway, I'm having a hard time convincing Android to get on Wifi, because I don't have a traditional Wifi router in my home, and I don't have a wifi card that Linux can use to broadcast an access point. So, I've been looking into patching Android to support Ad Hoc networks, which is where I am now.

Over here: http://szym.net/android/adhoc-wpa-supp.html
someone has made a lovely patch for wpa_supplicant that supposedly causes Android to display and connect to Ad Hoc networks. Why it doesn't do this already is beyond me, but that seems to be a Google vs Vendors thing and I really don't want to get into it.

Anyway, over here: http://forum.xda-developers.com/showthread.php?t=754961
someone else was kind enough to apply that patch to a version of wpa_supplicant extracted from another Android phone. Sadly, when I tried to replace iDroid's wpa_supplicant with this, it crashed violently. Thinking back, that's probably logical, as I have no guarantee that the architecture matched.

Is there anyone out there who can apply that patch to iDroid's version of wpa_supplicant? I don't know the last thing about .patch files. Is it just a source code patch, or does it require a pre-compiled binary? If the latter is true, how would the patch file work on different architectures?

I realize this is an edge case of edge cases, but it would really help me try out Android while I patiently wait for someone far, far more intelligent and persistent than me to get Data working over the 3G connection. If someone can either apply this patch for me, or give me a gentle push in the direction I need to run to get the patch applied myself, that would be great.

-Zeta

PS: Getting the first wpa_supplicant attempt there was hard enough: had to ADB in through USB, which is ridiculously buggy. However, in the process, I discovered that ADB is much more likely to successfully execute a command when using the adb shell "command" syntax, rather than trying to use an interactive shell. It seems that it's crashing on the 'packet?' level somewhere, so bundling the command into a single message rather than using an interactive terminal with a message for every keystroke greatly increases the chances of success. Perhaps this is the root of the issue with the USB driver in the first place?

Pages: [1]