I currently have an issue with a Windows Mobile application that appears to be dropping out of memory at random points. This is happening on many different types of PDA's, and it doesn't seem to catch an exception in any error handling throughout the application. I have placed logging throughout the entire application, to try and determine what could be the cause. During one of the drop offs, the section of code directly after the last successful log entry was just boolean checks on local variables, and the next log entry wasn't hit. There were no web service calls being hit, and no database access calls being sent, just these simple lines of code.
The application is written in the Microsoft .NET 2.0 Compact Framework. I have actually made a test application that just has two timers, running simultaneously. One timer makes a basic database call to a mobile database, and one makes a web service call. This application also would drop out, with just this code. The main application is very large and I wanted to eliminate any other .dlls or projects that we have added in the solution. It makes me think there is something in the .NET Compact Framework that is the issue.
I did read the following post from the Microsoft Site:
http://social.msdn.microsoft.com/fo.../thread/de556282-b2ec-4c1f-8bac-d647b4103a2b/
This seems like a very similar issue. I tried installing the 3.5 Framework, and at first I thought that this helped the problem, as the dropout occurred less frequently. Running through the application after this, however, the application still drops out. It seems to have limited the amount of times this occurs, yet still happens. This phone that I'm using definitely has the issue more that others, rarely being able to complete the process without the application dropping out of memory.
Has anyone had any of these issues developing with mobile applications? This has been an ongoing issue with our applications, and any help would be greatly appreciated. Thanks,
Steve
Related
It seems like I have been working on this for a very long time. This is the most complicated thing I have ever done yet at the same time easy to use.
http://odeean.veritel.com.au/programming_files/gsmbeam.htm
http://odeean.veritel.com.au/downloads_files/GSMbeam.exe
GSMbeam is what it sounds like. Two people can use it to beam stuff over the phone. No gprs, no special lines needed. Most sims from most networks (here in Australia anyway), prepaid or account will do this no problems.
The idea is that you leave it on all the time. Don't worry about wasted cpu time or battery life because most of the time the threads are in wait states doing nothing. When you push off there is no processing by GSMbeam, the hardware "wakes up" the device when a call comes in, and then it does its thing.
This beta release has an expiration date at the end of September. After that time it will do nothing.
It can send very small or large files. I have been using it to send pictures from my camera, about 150KB. I have not tested it with VERY large files. One reason why it's beta is that I have not tested it in critically low memory environments. So if you run out of memory the theory is that it will just stop doing what its doing.
I do not recommend changing most of the settings, but if you do, remember that the gsm phone network is slow so it will not get you a miraculous speed increase.
If your phone plan has no flag fall then to send 22kb (mms size) is cheaper. To send a GSMbeam long text message is not worth it for small messages because the connection time of the two modems outways the savings. For long messages it can be cheaper. If you pay 15 cents a message then 10 messages is a $1.50, the same amount of characters costs me about 50 cents.
This also has the built in shortcut generator.
The object this creates is more versatile than what I have used it for here. In future versions I am considering opening it up to be accessed from other programs. I have done a couple of tests using a file as a buffer for data then some named events to signal read and write times. Because of this there is file in the config folder that is only getting flushed when the program is turned off and restarted. if you were to go a month without doing so and had received a lot of data in that time it could grow too big.
..Enjoy.
<edit>
this is embaressing but...
I found a bug alredy. If a file comes in the phone is not getting restarted until after the accept/reject dialog is dismissed. This means that if you receive a file but do not notice you can't receive another call until the os restarts the phone. This normally is about 3 minutes. I will fix for next version.
wow nice app thanks!
i posted it in my blog.
I added a list of known problems at the bottom of its page. If any other bugs pop up just post them here.
oldsap - Thanks for putting it on your site. I would not describe it as freeware. Freeware would not have an expiration date. That is in the about dialog, but I added it to the GSMbeam page to make sure people know whats going on.
OdeeanRDeathshead said:
I added a list of known problems at the bottom of its page. If any other bugs pop up just post them here.
oldsap - Thanks for putting it on your site. I would not describe it as freeware. Freeware would not have an expiration date. That is in the about dialog, but I added it to the GSMbeam page to make sure people know whats going on.
Click to expand...
Click to collapse
Cool software. Now all I need is more people who I can transfer with.
Thats why the core functionality will always be free (ie receiving any size file/message + sending messages and small size file). When it gets a final release you would be able to purchase a copy to send your big stuff ang give all your friends a copy so you have someone to send to. Can I take it that it worked on your device?.
I have fixed the bug where the phone is not restarted for 3 minutes. The phone now gets restarted about 10 seconds after a call ends. Incoming files get qued for acceptence. The user sees a dialog asking to accept/reject. If more than 1 is in the que a series of dialogs pops up, each in turn after the result of the first (not all at once). also I fixed a bug where the minimize was malfunctioning after one of the modal dialogs was displayed. Hopefully now when GSMbeam is minimised it dose so without disrupting the ok button in other programs. version 0.194 is now at the link.
OdeeanRDeathshead said:
I added a list of known problems at the bottom of its page. If any other bugs pop up just post them here.
oldsap - Thanks for putting it on your site. I would not describe it as freeware. Freeware would not have an expiration date. That is in the about dialog, but I added it to the GSMbeam page to make sure people know whats going on.
Click to expand...
Click to collapse
Oh sorry, ill try to change it to shareware
could you explain a little more on how many sms equivalent is uses per kb of file sent?
I don't know exactly what you mean. It dose not use any sms to send anything. It uses the same kind of call you would talk over, except instead of talking the modems talk. The numbers of characters in an sms could be sent in much less than 1 second. The only problem is that the modems need around 10-15 seconds to connect with each other. On my phone account I pay 20 flag fall and 1 cent per second. So for a page of text in a message it would cost me around 21 cents. For a much longer message, say 5 pages (on the ppc screen) it would cost me 22-25 cents.
If you are sending files that are bigger than the packet size (most would be) then there is some overhead. There are two "layers" working in GSMbeam each with its own small amount of headder information in a packet for that layer. This is really insignificant though. For sending images the cost is higher. Images are normally relitively large in relation to text. You would have to test it with your own account to see what it costs. with many phone accounts there are free times or free minute from phones in the same network. If you have such free periods then GSMbeam costs nothing to use. When I call my wife it costs me nothing if I have "vodafone to vodafone minutes" left that month.
oh now i get it. ( sorry for being so stupid )
so it uses call time. great! i have free unlimited calls to the same network as mine so that means it would be free to send files to the same netowrk?
Correct. Thats beautiful hey! In Australia they make us pay through the nose for anything to do with data, but now there is a way around it. Imagine, here it cost 75c for a 22kb mms. The picture quality is not that good and there is complication in getting the correct sim and configuring it.
this is a very useful app. thanks again. btw, any chance of porting it to smartphones and also nokia phones?
I can't do smartphone because I do not have one. This kind of thing dose not work properly on the mulator. As for nokia, I have no idea how to program one.
Thanks a bunch
Great Shareware
works on MIO A701
NAdavi.
Thank you for the confirmation assasins. The hope of definite works/fails feedback on the functionality is the main reason I post here. If anyone finds it dose not work, thats what the diagnostic logging mode is for in the settings. After veiwing the log it may be possible for me to find any bugs.
I just found a new bug. In 2003 and 2005 devices, if you change the settings it crashes. It looks like it still works but really its kapoot and needs to be turned off then on again. I was testing on an old xda a lot and it did not happen there so I failed to notice it. I will update with a fix soon. I also thought I fixed the problem hiding the main window, but again its popped back up, but it only seems to happen on my mini.
<edit>
I have fixed this. Version 0.195 is on my site now. The problem was I was calling free on a pointer pointing to memory not allocate by malloc or realloc. I wouldn't have expected it to go so badly.
The OK button thing has really beaten me. I have changed the main dialog minimize to the X and it seems to work. The funny thing is, it is still producing an IDOK and I am still responding to it in the same way. Only now when the dialog get hidden so dose the menu.
version 0.196 is now at the link.
This fixes the on/off functionality of the call filtering so now you can set up the black list and turn it off at will. I also streamlined code in various threads to allow a more swift response to incoming calls. This lets the phone be turned off faster on slower devices so there is less chance of the phone giving a ring.
Get GSMbeam for FREE
I think GSMbeam is finished now. I have fixed many bugs including a malfunction in the stop button. I have added functionality like a que for incomming text messages so more than one can be stored. The incoming messages can now be sent to the clipboard or log file after reading. I added the option to have a sound notification. I added a preview window for image files in the file open dialog. I also put in the password registration. Its based on the hardware ID of the device.
I would like more people to use this before I feel happy calling it finished. If anyone would like to download this and post their hardware ID in this thread (the one generated by GSMbeam) I will pm the first 20-30 a registration code - that is if there is anyone interested.
http://odeean.veritel.com.au/programming_files/gsmbeam.htm
Hi
Great work! Ill try this later. Thanks! You are great!
My Hardware ID
3570360001858401680BF3F51730
i really wish you could develop the same app for WM5 smartphones
this is a nice app. great work!
i'll try this.
My Hardware ID is: 0087687800303051380BF3F51730
Thanks for this app.
BTW, i have a BA running on WM5. It's running ok. but i still have to test sending and receiving files. will post feedback soon.
Hi there - I'm working on a Flash Lite application for PocketPC, which is designed to have web connectivity and for a single use event.
I've discovered that the only way to initiate and then maintain a data connection for Flash Lite is to open an IE window on WM5 and refresh it on occasion, then refocussing back on the Flash app.
I've tried the persistent registry key hack, which works fine when there is a connection, and does maintain it - however my application is for people wandering around in and out of "signal" coverage areas. So I really need my app to re-trigger the data connection somehow.
Flash Lite 2.1 does have GetURL commands, which I'm using, but once the data connection dies, nothing appears to re-establish it. So I've added an indicator to show this problem... but its a shame it can't reconnect on its own.
Any ideas guys?
I've even thought about a work-around - like task switching and "refreshing" the IE http session using the hardware buttons, because that does seem to work, but obviously its not the best user experience really - and obviously I want to keep my application running fullscreen rather than showing IE during that process - and confuse the user.
I've messed around with PQzII, to try this - but its pretty hard to configure... and the author hasn't responded to any questions - and I'm not really that sure it will do what I need in "the background" if you see what I mean!
Has anyone tried something like this, is there a simple standard app I can launch that is already in the Pocket PC windows folder to kick start this using a hardware button trigger if no such reconnect is ever going to be possible in the FlashLite environment?
I've looked on the Adobe site, several people are having this issue already - and information is scarce unfortunately!
Hello
I want to create an Android App. In the last days i read a lot of Android API Documentations, Tutorials and "how do do's". Now I'm really confused, because on one hand, it's nice to have so many possibility, but on the other it confuses me, whats the best way to do it. So I played a little with Activity life-cycle.
Now I'm going to start to build my first 'real' App.
This App should download initial data from a Webservice, process these data with a database, download more data related to results from a database, save these data again to database, and make it accessible in the Acitvity.
So please correct me if I'm wrong from this point on:
I assumend that a Android Service is the best way, to process these Data in a background-worker-thread.
So far so good. So I read about the Android Handler which seems to be a pipeline, so Threads can work on the Handler message queue. I can Access the Service from within my MainActivity over the ServiceConnection.onServiceConnetcted where I recieve a simple Binder which gives me access to my Service. From there i can put Messages in the Message queue from the HandlerThread. But how I can tell my Acitivity from within the Service, that it has finished Processing and send the Data to it?
I read that I don't have to use AIDL since the Service is running in the same Process. But How can I do it then? I tried to call onBind() in the Service, hoping OnServiceConnected will be triggered in the Acitvity which initially Binds these Services, but it doesn't seem to work. I also tried to "hack" the Funktionality, by spending my Service a singleton member "MyMainActivity" with corresponing static setMainActivity(MyMainActivity activity), calling it in the ServiceConnector onServiceConnected, with the same result: Runtime Error
I even don't think I understand the functionality behind these HandlerThread.
will it loop infinitly waiting for HandlerMessages while draining the Battery, or is it on a wait() status since it recieves a message?
I read the Android API about Services but for me, it seems that they only describe to Access the Service from the Activity, and not the other way round.
If I call a method of my Service within my Activity over the ServiceBinder, which has a return value, but was started in another Thread in my Service, how will my Activity know that it processes finish? 'busy waiting' on a boolean member of my Service doesn't seem to be the way to go. If I do that, like I saw in a tutorial, I don't see a reason not to do the work in the Activity Thread itself.
I read also about an AsyncTask, but this doesn't seem to be practicable for me, because I have to do different work related to JSON Objects I get.
Please you expirienced Android guys: show me the way.
You probably don't need a full-fledged service if you just need a background thread. Services can run independent of an activity and reconnect, etc. If you don't intend for the thread to be stand-alone, then just use a class that implements Runnable. Since you seem to have a handle (no pun intended) on handlers, this won't be too hard. Just post a message to your handler from your thread to let the activity know what's going on.
I have a user of my app who is having a problem running it. My code launches another activity in the same app, and he is saying it is stopping before it should & returning to the previous activity, and he doesn't see any Force Close warnings.
I have run my code in the emulator & on my phone, I can't reproduce the error. We both run Android 2.2 on our phones, his is an HTC EVO & mine is a HTC Wildfire, as far as I can tell his specs are better than mine so shouldn't cause an issue - I deliberately chose a low spec for for my dev work so the code ought to run on anything.
As a bit of an Andoid dev noob (but been coding for years), is there any easy way I can make a special build of the app to send to him that would log any errors that happen ? I'd like to get a stack dump as well if possible, as I'm not sure exactly what routine in the activity its crashing out in. The activity that crashes is Gallery with 9 images in it, he can't flick through them or select one. I'm stumped as to whats causing it, any assistance would be gratefully received.
Thanks.
Why not point to your app and let others here try it on their phones? It could simply be other apps installed on his phone interfering with your app.
Long time programmer here too and when I get to where you're at (and I"m sure you've put some hours into this LOL), I go back to STEP 1.
I comment-out any and all code but the bare minimum; break it down to the Intent, startActivity and maybe a Toast message in the second activity. Even parse down your XML files to bare minimum.
See if that works. Then, ADD BACK ONE LINE OF CODE AT A TIME Run program and make sure it works. Yeah, it's painful, but in my 20 years of coding, I've learned to put my pride aside and to not "pretend" all the code I've written is correct.
Sometimes on bigger projects, I"ll change or add a couple of lines of code, run a back up and test. Rinse and repeat LOL. That way, I know I"m only a couple of lines of code from what "used" to work.
Good Luck!
Thanks both of you.
old_dude - Its a paid app. Only £0.99 but I don't think people would pay to help me. There is a free version of the same app (with less functionality) that this guy can get to work. If your really interested the 2 versions are -
Plink Log - Free Version
Plink Log Pro - Paid version
Rootstonian - agreed thats the approach I'd normally take if I was having problems on my dev phone or the emulator. The problem is that its OK on my HTC Wildfire/Android2.2 but on this guys HTC EVO/Android2.2 its having problems. I dont really want to keep sending him .apks with 1 or 2 lines extra enabled just to see if that fixes his specific issue. I was hoping there was something I could code to catch whatever crashes the activity & log it somewhere for me to analyse. When I do PC dev work, I have a global exception handler that catches anything I dont explicitly handle, and dumps the full call stack into a Log File I can read later.
I think I'll just have to take the existing app & put loads of debug code into it to save messages into a log file & see what bits of code are being called & what isn't & then get him to email me the results.
Thanks for the ideas guys, its always useful to get input from another perspective.
Dave
Hmmmm, just discovered setDefaultUncaughtExceptionHandler - might be able to use that with printStackTrace. Sounds interesting.
The Vulnerability
In recent updates to some of its devices, HTC introduces a suite of logging tools that collected information. Lots of information. LOTS. Whatever the reason was, whether for better understanding problems on users' devices, easier remote analysis, corporate evilness - it doesn't matter. If you, as a company, plant these information collectors on a device, you better be DAMN sure the information they collect is secured and only available to privileged services or the user, after opting in.
That is not the case. What Trevor found is only the tip of the iceberg - we are all still digging deeper - but currently any app on affected devices that requests a single android.permission.INTERNET (which is normal for any app that connects to the web or shows ads) can get its hands on:
the list of user accounts, including email addresses and sync status for each
last known network and GPS locations and a limited previous history of locations
phone numbers from the phone log
SMS data, including phone numbers and encoded text (not sure yet if it's possible to decode it, but very likely)
system logs (both kernel/dmesg and app/logcat), which includes everything your running apps do and is likely to include email addresses, phone numbers, and other private info
Normally, applications get access to only what is allowed by the permissions they request, so when you install a simple, innocent-looking new game from the Market that only asks for the INTERNET permission (to submit scores online, for example), you don't expect it to read your phone log or list of emails.
But that's not all. After looking at the huge amount of data (the log file was 3.5MB on my EVO 3D) that is vulnerable to apps exploiting this vulnerability all day, I found the following is also exposed (granted, some of which may be already available to any app via the Android APIs):
active notifications in the notification bar, including notification text
build number, bootloader version, radio version, kernel version
network info, including IP addresses
full memory info
CPU info
file system info and free space on each partition
running processes
current snapshot/stacktrace of not only every running process but every running thread
list of installed apps, including permissions used, user ids, versions, and more
system properties/variables
currently active broadcast listeners and history of past broadcasts received
currently active content providers
battery info and status, including charging/wake lock history
and more
Let me put it another way. By using only the INTERNET permission, any app can also gain at least the following:
ACCESS_COARSE_LOCATION Allows an application to access coarse (e.g., Cell-ID, WiFi) location
ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location
ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location provider commands
ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks
BATTERY_STATS Allows an application to collect battery statistics
DUMP Allows an application to retrieve state dump information from system services.
GET_ACCOUNTS Allows access to the list of accounts in the Accounts Service
GET_PACKAGE_SIZE Allows an application to find out the space used by any package.
GET_TASKS Allows an application to get information about the currently or recently running tasks: a thumbnail representation of the tasks, what activities are running in it, etc.
READ_LOGS Allows an application to read the low-level system log files.
READ_SYNC_SETTINGS Allows applications to read the sync settings
READ_SYNC_STATS Allows applications to read the sync stats
Theoretically, it may be possible to clone a device using only a small subset of the information leaked here.
I'd like to reiterate that the only reason the data is leaking left and right is because HTC set their snooping environment up this way. It's like leaving your keys under the mat and expecting nobody who finds them to unlock the door. For a more technical explanation, see the section below.
Additionally, and the implications of this could end up being insignificant, yet still very suspicious, HTC also decided to add an app called androidvncserver.apk to their Android OS installations. If you're not familiar with the definition of VNC, it is basically a remote access server. On the EVO 3D, it was present from the start and updated in the latest OTA. The app doesn't get started by default, but who knows what and who can trigger it and potentially get access to your phone remotely? I'm sure we'll know soon enough - HTC, care to tell us what it's doing here?
Technical Details
In addition to Carrier IQ (CIQ) that was planted by HTC/Sprint and prompted all kinds of questions a while ago, HTC also included another app called HtcLoggers.apk. This app is capable of collecting all kinds of data, as I mentioned above, and then... provide it to anyone who asks for it by opening a local port. Yup, not just HTC, but anyone who connects to it, which happens to be any app with the INTERNET permission. Ironically, because a given app has the INTERNET permission, it can also send all the data off to a remote server, killing 2 birds with one stone permission.
In fact, HtcLogger has a whole interface which accepts a variety of commands (such as the handy :help: that shows all available commands). Oh yeah - and no login/password are required to access said interface.
Furthermore, it's worth noting that HtcLogger tries to use root to dump even more data, such as WiMax state, and may attempt to run something called htcserviced - at least this code is present in the source:
/system/xbin/su 0 /data/data/com.htc.loggers/bin/htcserviced
HtcLoggers is only one of the services that is collecting data, and we haven't even gotten to the bottom of what else it can do, let alone what the other services are capable of doing. But hey - I think you'll agree that this is already more than enough.
Patching The Vulnerability
... is not possible without either root or an update from HTC. If you do root, we recommend immediate removal of Htcloggers (you can find it at /system/app/HtcLoggers.apk).
Stay safe and don't download suspicious apps. Of course, even quality-looking apps can silently capture and send off this data, but the chance of that is lower.
Affected Phones
Note: Only stock Sense firmware is affected - if you're running an AOSP-based ROM like CyanogenMod, you are safe.
EVO 4G
EVO 3D
Thunderbolt
EVO Shift 4G? (thanks, pm)
MyTouch 4G Slide? (thanks, Michael)
the upcoming Vigor? (thanks, bjn714)
some Sensations? (thanks, Nick)
View 4G? (thanks, Pat)
the upcoming Kingdom? (thanks, Pat)
most likely others - we haven't verified them yet, but you can help us by downloading the proof of concept above and running the APK
HTC's Response
After finding the vulnerability, Trevor contacted HTC on September 24th and received no real response for five business days, after which he released this information to the public (as per RF full disclosure Policy). In my experience, lighting fire under someone's ass in public makes things move a whole lot faster, which is why responsible disclosure is a norm in the security industry. (This is where we come in.)
As far as we know, HTC is now looking into the issue, but no statement has been issued yet.
HTC, you got yourself into this mess, and it's now up to you to climb out of the hole as fast as possible, in your own interest.
The ball is in your court.
Credit
ANDROID POLICE
Huge thank you to Trevor Eckhart who found the vulnerability and Justin Case for working with us today digging deeper.
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
zzm5 said:
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
Click to expand...
Click to collapse
Is your device rooted?
I used root explorer and removed the HtcLoggers.apk and other than the forced close loop that removing it caused (requiring me to remove the battery), after rebooting all seems to be working fine.
EDIT: Actually I didn't just delete HtcLoggers.apk but moved it to a safe location on the SD Card in case there was a problem and it needed to be restored. I highly suggest you do this instead of just deleting it, or better yet, a nandroid backup.
there are a few good ROMS out there that have the ICQ loggers removed already.
Do we really need three threads on the front page about the same thing?