I'm an iOS dev currently working on a android app (so very inexperienced with Android).
If I leave my android emulator instance open it sends huge amounts of data, 10's of GB's per minute slowing down my network. I just left it running for a couple of hours and it has send 11TB of data (yes that "T" is correct) (for context the next item in activity monitor has sent 300mb in the same period). (All according to Mac Activity Monitor anyway).
The activity monitor item is qemu-system-aarch64. I understand this to be emulator, as soon as I close emulator this data sending stops and if I force stop this process emulator quits.
I have deleted devices and created news ones running a variety of android versions and all seem to have the same issue.
I'm confident the data is not sent by my app.
Restarting Android Studio/Emulator/the Mac doesn't change anything
I can't see any large amounts of data being send via Proxyman or Little Snitch so I have no idea what's actually being sent or how to stop it.
My next move is to re-install Android Studio from scratch but would ideally like to know what's going on to prevent it in the future if this does solve it.
Does anyone have any experience with this problem or ideas as to what causes it? Any ideas on how to see what's being sent?
Any general nudges in the right direction would be greatly appreciated!
Thanks!
Related
I have been using my antique pc with a bit of stress at times and full of gratefulness at other times, but starting from yesterday, my old pc began stressing me out, and, most importantly, I couldn't fix it just by following a few tutorials on the internet.
Yesterday, when I wanted to draft some emails on Gmail from MS Edge, which I have been using since it is considered the most RAM-friendly, it crashed, and the crash continued no matter how many times I refreshed the page or restarted the pc. It says the error code: Out of memory
Sure enough, opening the task manager tab, I saw that MS Edge was using about 3000000k or 300 Mb, and it also displayed roughly 90% of memory was being used when the Gmail tab is only open and no other activity was going on. For a different person, the result may seem obvious, but my pc has been working somewhat ok, at least it wouldn't crash for just opening a Gmail tab and drafting an email. Therefore, it is not a normal occurrence from my perspective.
Do you know what is the strangest thing? My PC's performance has gotten better; for example, while asking this question, nothing happened, and it is responding extremely quickly as if I am working on the latest laptop haha. Then, what happens when entering Gmail?
Ok, here are a few pictures that may be useful.
When my Windows 10 app runs, it causes a process called Runtime Broker to execute, which takes up a lot of Memory space.
I know my app isn't "Memory-hungry" and it hardly takes 80 MB of RAM to execute. But from the time it starts, the Memory used by Runtime Broker keeps in increasing until the PC gets stuck.
Upon killing that process, the app is force closed by Windows.
I would have posted my source code here, if only I knew which part of the code is causing this to happen.
What are the possible technical reasons for this problem to happen, and what are the possible fixes in my code to prevent this?
Is there something wrong with my code, or is it some API that I am calling?
You can easily delete RuntimeBroker.exe and any other file. I deleted RuntimeBroker.exe and Livecomm.exe by booting a live Linux Dvd and after loading go and mount the c: drive then simply navigate to the file and delete it. Done!
Runtimebroker seems to hold about 60k per file held via StorageFile objects. It's still a bad problem and the only solution is to not hold on to very many of these.
Microsoft just never does anything about this.
Update: Microsoft seems to have quietly ditched UWP. The replacement has "WinUI" and is probably called the Windows App SDK at the moment. No more runtimebroker.exe.
I've been playing around with this for days now and the only conclusion I can come to is that CoreLocation is pretty buggy for this setup in iOS 8.1.
I had code that was correctly monitoring for a region (using UUID only, no major/minor) and the delegate methods didEnterRegion and didExitRegion were being called correctly, while the device was locked and the app had been terminated, which is what I want. These even worked after a reboot without issue.
I modified the code to pull some more UUIDs from a server and to start monitoring for those regions (only two more). They're working, but only while the device is awake and unlocked, the moment the screen is powered off then I get no hits on the delegate methods at all. The first UUID I used continued to work while these didn't, so I removed the app from the device to stop it from counting (I'm not calling stopMonitoring anywhere right now).... the two new regions still don't work when locked though.
Every version of iOS I've tried has exhibited different behaviour with beacons, and this is the most annoying one yet because when it was working it was being very responsive—powering up a beacon with the beacon with the first UUID would trigger delegate calls within a couple of seconds—but now it's just refusing to work.
Does anyone have any ideas around what's going on internally in CoreLocation and what I might be able to do to make this more reliable? Capabilities etc. are all present and correct as evidenced by the fact that it was working fine with the one region.
I'm in need of help. The situation is the following:
We have a software that runs on Windows Mobile 5 and 6. It is deployed in around 15 cities on different devices (Motorola MC35, MC55, MC65, MC75, MC75A, ES400). It works perfectly fine everywhere except in one city. They have MC75A devices and every once in a while we get a helpdesk about our software disappearing from the device.
The most interesting part is when we log in to check the device, all we can see is a damaged/corrupted file system and the OS, which is set back to default.
We tried to reconstruct the problem here at our company, but we find it impossible. I'm wondering if anyone has ever bumped into this.
I'm gonna attach two images of the corrupted file system.
We use custom windows settings and AppCenter to protect the operating system from our customers. (They shouldn't be able to modify any settings on their own).
In general such corruption happens when the driver is interupted saving changes to the file system.
That can happen, for example, when a high priority thread consumes all cpu times.
It may also happen, when the device is hard reset, for example by taking the battery out during thed river is writing to the file system.
A low battery normally cannot result in that corruption:
a) as the device shuts down itslef with critcal battery power
and
b) the file system is in flash RAM (in contrast to Windows Mobile 2003 and before) and does not need battery power to hold data.
It is also possible that there is a bad behaving process doing these corruptions.
As you say you see this only in one city: What is the main difference with the devices there?
Are others also using the same device? Maybe the device series itslef or there firmware is faulty (contact symbol/motorola for new firmware or patches to the 'disk' driver)
Are the users in that area doing special things to the devices that others do not? For example remove the battery when they mean the device does not react?
Is the MC75A used in other areas and there it does not show the corruption?
You see, you have some more items to examine a rule for the corruption?
I have a problem with my Windows Phone app.
The app uses all the device sensors: gps, accelerometer and compass
When I run it in the emulator it's fine and when I debug it on the phone it's fine.
But when I remove the USB cable from the device and start the app again it crashes very soon and I dont know how to find out why because the debugger is not attached.
How can I debug such a problem?
There are a number of reasons that this can happen. It's hard to pinpoint precisely what's going on without some debug output, but here is a brief run down of the likely culprits:
Most Likely...
The most likely thing that's causing your app to crash in non-debug mode is poor start up time. I suspect you may be encountering what this S.O. question is all about. When the debugger is attached, the runtime bypasses the operating system's function of killing any app that takes longer than 10 seconds to load. This is an easy thing to test for, simply remove all the code that's being executed when the app starts up (I'm assuming you're hooking into GPS stuff at that moment, just comment that stuff out).
But Additionally...
While the above might solve your problem, you have to be wary of a few other issues you may also encounter:
When you access the GPS / Accelerometer / Compass you must check first to see if those sensors are actually accessible and provided by the phone. Not all windows phones are required to provide the compass. Take a look at the Hardware Specifications for Windows Phone. If you are trying to access the compass, and your device does not support the compass, then that could be your problem right there. More details on this here. The following code is an example of how you might check for the presence of the Compass on the device (note that the IsSupported will return true even if your device has the compass off).
using Microsoft.Device.Sensors;
public partial class MainPage : PhoneApplicationPage
{
Compass compass;
public MainPage()
{
if (Compass.IsSupported)
{
// awesome. you have a compass
}
else
{
// uh oh… you have a crappy phone, no compass for you :(
}
}
}
Have You Tried Turning It On And Off Again?
One of the other things you have to consider is that the device you are using has the GPS turned off (greater developers than you I am certain have made more foolish mistakes). If your GPS is turned off, or disabled, or the user (you, there, holding the device) has not authorized the app to use GPS data. See this article for dealing with the location considerations alone (a must-read if you're developing GPS enabled WP7 apps anyways).
Declare Your Intentions Sir
Lastly, there can be issues if you don't declare the things you're accessing from the device in the application manifest file. Basically, if you don't declare those as items your app uses, you can run into problems. The reason you need to declare what you're app uses is so that Microsoft can appropriately filter/warn/inform users who are downloading your app from the marketplace of the information your app requires to operate.
Battery Saver Mode
When a Windows Phone is in battery saver mode some of the sensors will be turned off to save battery life (things like... GPS, Compass, and Accelerometer). This could easily happen if your device isn't actually charging when it's plugged into your dev machine.
In Summary:
Check to see if your app is taking longer than 10 seconds to load
Make sure the device actually supports the sensors you are trying to access
Make sure that the data returned by the sensors is not causing your code to crash (for instance GPS may be on, but give a lat/long that is, according to your code errant, causing it to crash).
Make sure you declare usages in the application manifest file
Make sure your sensors are ON and you're not in battery saver mode
Hopefully one or all of the above helps you diagnose your problem. Lemme know if you find out that it's something else, would be curious to know what else could be causing this problem.
Have you considered adding MessageBox.Show method calls in any exception handling code you may have to display the particular exception message and even the stack trace? Also consider doing the same for the Application_UnhandledException event handler in the App.xaml.cs.
What you can do is to write all Debug-Informations like the Stacktrace and the Message into the IsolatedStorage which then you can display on a seperate Page.
The Problem may arise because the Phone uses the Internet of the PC if plugged in (Had the same Problem for quite a time)
It's worth using the Little Watson technique described by Andy Pennell in his blog here. This saves the exception details to Isolated Storage and will email it out from the app when the application next starts. There's full code in the blog.
The code is easy to adapt if you want to remove the emailing part and just want to manually pull the crash details from Isolated Storage from your development PC.