I've seen some posts elsewhere about very slow file access after "upgrading" a device to Android 11. I'm not having that, but I AM having unbelievably slow performance in a small app that uses sockets. It's a client app that uses a socket to send a request to a server (mine) that monitors my solar installation, to get data back about how it has been performing etc. So the socket interaction is in a separate thread from the UI, and uses runOnUIThread to call a function that updates the UI with the received data. The request data is only a few bytes, maybe 20 or so maximum: the data coming back varies from a few hundred bytes to maybe 50000 bytes or thereabouts.
If I run this app on my phone (Android 8.1) it is fine - it takes 1.5 to 2 seconds to send the request, get the data back, and update the UI. Perfectly fine. It's the same on an older tablet running Android 7.1.2 too. But I have just recently acquired a flash (read expensive) new Samsung tablet running Android 11, and its performance is woeful - the same app doing the same operation takes anything up to 30 seconds, or even more. And it is exactly the same app, exactly the same code. Both devices are running on the same network, so the only significant difference seems to be the Android version. It is repeatable ad nauseum, so it isn't momentary network load either. The app is built to target API level 26 - it has to be so it can run on all the devices it needs to. It is not a commercial app, just something for my own use, but I am totally bewildered by this behaviour.
The other thing I have noted with this new tablet is that it is unable to provide a video stream from a surveillance IP camera I have at home. I use the TinyCam Pro app from Google Play for this. It can connect, but it has never yet managed to give me a picture, regardless of how good my connection is. Again, my phone and the older tablet can do this more often than not, and the new tablet would have far more horsepower than either of them. There is some sort of serious bottleneck in there!
Has anyone else seen this type of thing on Android 11? If so, is there anything that can be done about it, that is usable on earlier versions too? Or do we just have to wait for Android 11.1?
EDIT: I've done some more investigation on this, and I think I have now pinned it down to a 4G network bandwidth issue. I said that the tablet and the phone were doing exactly the same thing, but I have since remembered that they do NOT use the same carrier for their mobile connections. So it's not EXACTLY the same thing. I would actually expect the network capacity for the tablet's carrier to be superior to that of the phone's carrier, but that appears not to be the case where I am at the moment. So I think I have to take back my evil thoughts about the tablet, and maybe even Android 11. Interesting how easy it is to be misled, and how hard it can be to genuinely compare apples with apples when there are so many variables and so many links in the chain. I'll be doing some more tests and comparisons when back in the city, where network capacity should be much more alike for the two carriers.
yes its true. While compare to Android 11 and Android 8 there is a lot of changes updated because of security issue.
May be, If your managing some file in mobile storage mnt/sdcard/ here in this path its speed of access or managing a file in this path its restricted and its becomes less. So, if your using this path please change it like below because it will cause youe app to process slow.
solution - Try to use this file access path is Android/data/data/packageName/
I mean if your using this logic to access file - Environment.getExternalStorageDirectory()
instead of above try this - Context.getExternalFilesDir(null)
refer this link https://developer.android.com/about/versions/11/privacy/storage
I hopes it will help you...
Related
When using a mobile Android Wi-Fi hot spot on macOS Catalina and MenuMeters utility to see total mobile traffic I noticed that every time I launch iOS Simulator (tested on iPhone Pro Max and iPhone SE 2nd generation both with iOS 13.5) it starts downloading huge amounts of data (approx. 450-800 MB) on every launch, so it gets rather expensive. I know that's Simulator because when I quit it traffic stops.
So I'd like to find out what and why Simulator may download maybe to try to block/work around this expensive operations.
I tried to use Charles and Proxyman to detect addresses Simulator could connect to - but with no avail, I cannot see this hundreds of megabytes there. Another option was Wireshark, but I do not know how I could use it to get what I want (as I imagine it should be some addresses from where Simulator could download data).
Could you please give me some advices how to get needed info with these applications or in some other way.
Edit
Thanks to accepted answer and Little Snitch I was able to catch and block "evil" connection
If it's not appearing at all in Charles or Proxyman then it's probably not being sent over HTTP. Wireshark will show the raw TCP & UDP connections, but it's very complicated if you're not familiar with it, and there'll be a lot of info there.
One good option for this is Little Snitch. It does exactly what you want, and can show you exactly who every app is connecting to and how much traffic is sent. It normally costs $30, but they let you try it out for free, and a quick check should be all you need.
I'm using RN-41-APLX bluetooth evaluation board (based on RN-41-APL, very similar to RN-41 but also supports Apple devices) as a member of MFi.
I was able to establish connection and transfer some data to and from dev board with out-of-the-box configuration.
The problem is, in data sheet for RN-41 it is set, that SPP profile supports 240kbps speed, but when I transfer 10kB from iPod touch with Roving test iOS application installed, it takes 5 seconds to transfer.
Since UART speed is 230kbps, I think the bottle neck is the bluetooth link speed, but I can not find any way to change it. Can anybody help with that?
Thanks in advance!
I've run into this problem myself about this chip (well, the RN42 technically) and posted my findings here:
RN42 Bluetooth disconnects on iOS within seconds of streaming data
Short summary:
When the RN42 is used to communicate with an iOS device, it cannot
communicate faster than 2.5-3kB/s... If it's used to communicate with
an Android or computer or anything else, it can transfer at 35kB/s
(over SPP).
Hope it helps!
-SJ
I have been long interested to develop on the platform. I even got the tools installed already on my desktop but I can't upgrade my WDDM from 1.0 to 1.1. To make things simple: my graphics chips are not up to the task of running the emulator.
If I still buy a Windows Phone (e.g. a Nokia Lumia) for development purposes, can I sideload and test my apps there efficiently instead of going against the emulator?
If I still buy a Windows Phone (e.g. a Nokia Lumia) for development purposes, can I sideload and test my apps there efficiently instead of going against the emulator
Yes, of course. It's very easy and convenient. You have debugger and all the goodies. Advantage of the emulator is the test option for 256MB devices.
That's exactly what I used to do prior to upgrading my devstation. The nominal min spec says 3G but with a real phone it worked fine in 2G and as you say this also sorts out graphics limitations.
Note that the setting for whether the emulator or physical device is used is stored in the project, so if you accept a project from someone else you will have to set it once prior to debugging.
Well there are 2 sides of the coin. With the physical device you can test most of the things, but with a few limitations
You will not be able to test internet related test cases - For example, if you have an app which uses internet connectivity then you will not be able to test it on the device easily because
The device does not use the machine internet connectivity
When connected to the PC the device's internet connectivity(Data connection 3G/ wifi/GPRS) is broken.
You will have to purchase an account right from the first day you want to test your app. If you have the emulator working then you could postpone this for atleast few days.
Whenever I disconnect my Windows Phone from PC (connected through USB) and if my application is running, my application hangs for sometime and then application crashes.
Does anyone experienced same behavior? I guess switching for PC connection to Wi-Fi/GPRS is causing the issue.
the windows Phone Requires that you Safely Remove hardware first, after a few times when i started Development on the windows phone i did the same and Ended up getting a new Phone. So plainly put, try to Safely Remove and Make sure it is installing the app to the Device.
Meaning if you Remove the phone, the App is still able to be ran just like a normal downloaded App form the Market place.
if you want more in depth information, i would suggest Reading the WP7 Everything Programming ebook lol
its filled with good information, and Definitely Helped me along my road to Love DEV for WP7.
As gamernb says, if you disconnect the USB from a properly tethered Windows Phone (i.e. connected to Zune, or using the WPConnect utility), the phone's network connection will be reset and your app's connections will be terminated. The phone will then start trying to connect using WiFi or cellular data (if they are on), but this can take quite a while.
You will have to handle this network disconnection in your app - I've found that pulling the USB cable in this way is a good ad-hoc test for WP7 apps: do an action which you know will use the network connection. Then watch if the app crashes, or handles this gracefully.
Actually you aren't guaranteed to always use the PC data connection: if you make sure that the computer has no data connection (i.e. pull the Ethernet cable, turn off WiFi etc ), the WP7 app can then use cellular data or WiFi on the phone instead.
Alas-
you could set perimeters in your application to Check what the connection type is, then Make changes accordingly.
You May have a slight freeze, but that's better then a crash....mainly when the phone switches from PC to WWAN, their would be a slight Pause.
use the Reachability Class and NSLog to Figure out whats going on exactly.
I really hope that helps!
The software in question is a native C++/MFC application that receives a large amount of data over UDP and then processes the data for display, sound output, and writing to disk among other things. I first encountered the problem when the application's CHM help document was launched from its help menu and then I clicked around the help document while gathering data from the hardware. To replicate this, an AutoHotkey script was used to rapidly click around in the help document while the application was running. As soon as any sound occurred on the system, I started getting errors.
If I have the sound card completely disabled, everything processes fine with no errors, though sound output is obviously disabled. However, if I have sound playing (in this application, a different application or even just the beep from a message box) I get thousands of dropped packets (we know this because each packet is timestamped). As a second test, I didn't use my application at all and just used Wireshark to monitor incoming packets from the hardware. Sure enough, whenever a sound played in Windows, we had dropped packets. In fact, sound doesn't even have to be actively playing to cause the error. If I simply create a buffer (using DirectSound8) and never start playing, I still get these errors.
This occurs on multiple PCs with multiple combinations of network cards (both fiber optic and RJ45) and sound cards (both integrated and separate cards). I've also tried different driver versions for each NIC and sound card. All tests have been on Windows 7 32bit. Since my application uses DirectSound for audio, I've tried different CooperativeLevels (normal operation is DSSCL_PRIORITY) with no success.
At this point, I'm pretty convinced it has nothing to do with my application and was wondering if anyone had any idea what could be causing this problem before I started dealing with the hardware vendors and/or Microsoft.
It turns out that this behavior is by design. Windows Vista and later implemented something called the Multimedia Class Scheduler service (MMCSS) that is intended to make all multimedia playback as smooth as possible. Since multimedia playback relies on hardware interrupts to ensure smooth playback, any competing interrupts will cause problems. One of the major hardware interrupt sources is network traffic. Because of this, Microsoft decided to throttle the network traffic when a program was running under MMCSS.
I guess this was a big deal back in 2007 when Vista came out, but I missed it. There was an article by Mark Russinovich (thanks ypnos) describing MMCSS. It seems that the my entire problem boiled down to this:
Because the standard Ethernet frame
size is about 1500 bytes, a limit of
10,000 packets per second equals a
maximum throughput of roughly 15MB/s.
100Mb networks can handle at most
12MB/s, so if your system is on a
100Mb network, you typically won’t see
any slowdown. However, if you have a
1Gb network infrastructure and both
the sending system and your Vista
receiving system have 1Gb network
adapters, you’ll see throughput drop
to roughly 15%. Further, there’s an
unfortunate bug in the NDIS throttling
code that magnifies throttling if you
have multiple NICs. If you have a
system with both wireless and wired
adapters, for instance, NDIS will
process at most 8000 packets per
second, and with three adapters it
will process a maximum of 6000 packets
per second. 6000 packets per second
equals 9MB/s, a limit that’s visible
even on 100Mb networks.
I haven't verified that the multiple adapter bug still exists in Windows 7 or Vista SP1, but it is something to look for if you are running into problems.
From the comments on Russinovich's post, I found that Vista SP1 introduced some registry settings that allowed one to adjust how MMCSS affects Windows. Specifically the NetworkThrottlingIndex key.
The solution to my issue was to completely disable network throttling by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\NetworkThrottlingIndex key to 0xFFFFFFFF and then rebooting. This completely disables the network throttling portion of MMCSS. I had tried simply upping the value to 70, but it didn't stop causing errors until I completely disabled it.
Thus far I have not seen any adverse effects on other multimedia applications (nor the video capture and audio output portions of my own application) from this change. I will report back here if that changes.
It is known that Microsoft built some weird anti-feature into the Windows Vista kernel that will degrade I/O performance preventatively to make sure that multimedia applications (windows media player, directX) get 100% responsiveness. I don't know if that also means packet loss with UDP. Read this lame justification for the method: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
One of the comments there summarizes this quite well: "Seems to me Microsoft tried to 'fix' something that wasn't broken."