A couple of years ago I gave up developing Android apps because Samsung stopped persisting foreground services. This move by the leading Android platform killed all of my apps.
I'm familiar with dontkillmyapp.com but using all of those suggested interventions don't do the job.
Any time the phone user uses the "close all" option my foreground service gets killed immediately along with all the running apps. This is a common operation that I often use when poorly written stubborn apps won't quit. This happens regardless of any battery settings.
This posting is sort of a last check to see if anyone has come up with a solution to this problem.
I still don't understand why Samsung would do such a thing unless they are trying to push Android off their phones in favor of some new operating system they may be working on.
Related
Upon upgrading to Big Sur (macOS 11.0.1), our app is now asking the user to grant permission to use Bluetooth. However, we are not running any bluetooth code to my knowledge. We do link to CoreBluetooth, but it's been like that for a long time, and this prompt has not appeared.
When running in Xcode 12.2 it does crash with this message:
2020-11-13 13:21:58.685610-0800 Fuze[31049:200367] [access] This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key with a string value explaining to the user how the app uses this data.
But to my knowledge, NSBluetoothAlwaysUsageDescription is only applicable for iOS devices.
I suspect this is something new with Big Sur, because the System Preferences UI for Security & Privacy -> Privacy, did not have a Bluetooth section in Catalina, and it does in Bug Sur. But the Apple documentation does not make mention of this key being applicable for macOS.
https://developer.apple.com/documentation/bundleresources/information_property_list/nsbluetoothalwaysusagedescription
So my questions are:
Is this key now applicable for macOS and we should have it, even though the documentation says it's only for other platforms, or is there a different key for bluetooth for macOS? I haven't found one.
Is there a way to control this prompting or not, because we aren't actually using the bluetooth code. We need the framework for a particular feature, but it's not applicable for many users, so it's confusing to ask permission for it right when the app launches.
Thank you!
I'm not confident about this, but I've been running into some Bluetooth on Big Sur strangeness today as well. In my case, I run a Bluetooth peripheral from the Terminal, and I was also recently prompted to provide the Terminal with Bluetooth permission (which I'd never seen before).
For testing purposes, you can try the "Privacy — Bluetooth Peripheral Usage Description" or "Privacy - Bluetooth Always Usage Description" - and see whether that resolves the crash (I assume it would). It's strange, as I didn't think either of these were required in the past - but it looks like Big Sur is definitely cracking down on permissions.
When you go to "Signing and Capabilities", if there is an option to enable "Hardware -> Bluetooth" in the "App Sandbox" - I would try that out too (you may also need to enable Location, but I can't recall). I'm curious if modifying that flag would change anything regarding permissions.
When you link to CoreBluetooth, are you using the API at all? Because the permission check should happen on the first API call. But, Bluetooth is weird, so it might kick in as soon as the app launches...
In thinking about it, I've actually never optionally used Bluetooth in an app - it's always initialized from app start, so I can't say when the permission check occurs.
We've created a Windows 10 application that runs on tablets in Windows 10 kiosk mode. It works just fine, however, the wifi connection gets lost sometimes since the locations are very remote. We tried fixing the issue from the networking side, but when the devices lose and regain internet access the application will still hang as if it doesn't have internet access displaying a blank page. Where these devices are used, they are bolted into the wall to prevent theft. Which means if we want to reboot its very time consuming as we have to unscrew the cases off the wall and then open the cases to gain access to the power button, and the only way to get the application to run successfully again is to do a reboot on the device.
It was suggested that we have a way to perform a reboot from the application, however, every code example I've tried doesn't work in Windows 10 UWP. Here is the most common one I've found:
System.Diagnostics.Process.Start("restart", "/r");
I have access to the namespace
System.Diagnostics
but the Process class does not exist. Anyone have suggestions on rebooting via code on Win 10 UWP? Or a better solution to our issue? Thanks in advance.
It's also worth mentioning I tried execute a Powershell command too and the dll I need to reference for the Powershell class is not compatible with UWP.
What you require is not possible with the APIs available to UWP apps. This was a security decision. An app distributed through the store shouldn't be able to do things like restart machines.
Based on your scenario though you shouldn't need to go through the store. This means that you could PInvoke native code to do whatever you want. This would still need to be initiated on the actual device.
Yes you can do that!
You should add IoT System Administration in App capability declarations:
<Capabilities><iot:Capability Name="systemManagement"/></Capabilities>
and also You need to have "Windows IoT Extension for UWP" added to your project
using this for Shutdown
Windows.System.ShutdownManager.BeginShutdown(Windows.System.ShutdownKind.Shutdown, TimeSpan.FromSeconds(1)); //Delay is not relevant to shutdown
or for Restart
Windows.System.ShutdownManager.BeginShutdown(Windows.System.ShutdownKind.Restart, TimeSpan.FromSeconds(1)); //Delay before restart after shutdown
You can get more information in this Link
I acquired a batch of WT0490 wearable pdas with detachable scan head, so converted an application originally made for Windows Mobile (which has been running perfectly for several years) to run on the WT4090s. The devices use these versions:
Windows CE 5.0
EMDK 2.6
ASP.net CF 2.0
Since rollout I've seen some very frustrating behaviour, which seems to start happening after the devices have been operating a few days. Users are reporting the following error:
Unexpected error in application
SCAN_Enable
There doesnt seem to be any noticeable pattern, several devices will be working perfectly for a few days then suddenly this error will show. THen a few days and a few reboots later they work again.
All devices were taken right back to stock settings then our cabs deployed to them. All identical models. We've tried altering memory allocation, swapping scanner headers etc but there is no pattern.
The error seems to occur on load of the first form after login, the login screen displays a list of users in a dropdown with a password box so that part of the app works ok, it seems to be when the scanner is initialised that this failure happens.
I had 40 devices, now 30+ have gone down with this same issue so my gut is telling me its a software issue but as yet ive not been able to find out why.
We've tried warm boots, cold boots, complete reprovisionings as well. We have a couple of dev units that don't show the problem although they are not in regular use so maybe we just haven't seen the problem 'yet'.
I hope someone out there has had this issue and knows how to fix it.
Thanks in advance.
WT4090 was built by Motorola Solution enterprise business, now part of Zebra Technologies. The WT4090 is currently in EOS (End Of Sales) but is still supported by Zebra if you've a maintenance contract.
You can check if you've the latest OS version and fixes installed on the device looking on Zebra Technologies support website.
For question on how to develop for Zebra Technologies devices you can take a look at Launchpad, Zebra's developer community website.
It's Worth noting that these devices have detachable barcode scanners - so if the scanner is not correctly attached, you get a SCAN_Enable error.
If you don't release the scanner, you can also see this error as a previous form could have the scanner blocked.
You may also find you have the ScanWedge app running - this will also block the scanner so you cannot get it enabled. The EMDK needs exclusive access to the scanner to enable it.
I was looking into OWASP Top 10 Mobile Risks for security issues to be kept in mind while developing mobile applications. They have given very good information pertaining to Android and iOS platforms. Some notable ones include Client Side Injections, iOS Abusing URL Schemes, Android-Abusing Intents, Keystroke logging, Screenshots/iOS Backgrounding, Logs etc.
These were very useful and now I want to know if there are any new vulnerabilities that exist in Windows Phone 7 , which were not present in Apple iOS and Google Android.
My requirement is, I need to build somewhat like a Damn Vulnerable WP7 App to educate the WP7 developers in my project to build secure applications for our clients.
OWASP has already built iGoat (iOS application) and DroidGoat (Android application) for the sake of iOS and Android developers. I dont see any such application for Windows Phone 7.
Currently WP7 appears to be a very secure OS. Whilst I am sure it has vulnerabilities, these have not been exploited yet. Interestingly AVG released an anti-virus / malware app for WP7. This was pulled from the marketplace because it didn't actually do anything since there are no viruses for the phone yet!
http://www.winrumors.com/microsoft-pulls-avg-antivirus-windows-phone-app-from-the-marketplace/
There has been a recent SMS flaw discovered:
http://nakedsecurity.sophos.com/2011/12/14/windows-phone-7-5-susceptible-to-sms-hack/
Having said that, there is still a need to educate developers about security. You can of course build an application which has its own security vulnerabilities by failing to protect the users data for example.
if there are any new vulnerabilities that exist in Windows Phone 7
Actually, I dare say there ain't any old ones either. Most of the security issues on Android is caused by the ability to change the system 110%. Windows Phone don't have intents, don't allow process inspection, or access to the raw file-system.
As Colin said, the security issues there can occur is related to data handling. For instance, the isolated storage can be inspected by jailbreaking the device, and as such you can read out unencrypted passwords (or other personal data) from the isolated storage.
However, to jailbreak a device, you need physical access to it. And you can't remote install a application for inspecting the isolated storage, even if the device was jailbreak'd. It can only be done by USB.
I am a .NET programmer who needs to port one good Desktop OTP system already at work to be used into cell phones. As far I know J2ME is the correct answer to do it. I'll appreciate any good advice about IDE, first steps, books or any other information.
Well, Eclipse IDE have good J2ME support, or so I've heard.
For api, read the javadocs:
http://java.sun.com/javame/reference/apis.jsp
You'll have to figure out which device you want to target, and grab its emulator.
Then, proceed making a hello world app with the aid of tutorials.
I would give NetBeans a try as well. Eclipse and NetBeans are very similar, but the differences can be night and day depending on your personal preferences. NetBeans also has great J2ME project support, and it is plug and play for any emulator of a device you may need to target, though I recommend sticking to the default or SonyEricsson's. Motorola's was always buggy and never reflected the device at all, and Nokia's was always sloooow.
Also, there are a ton of devices out there. Before you jump head first into this you should define a scope of exactly which devices you will need to target. This will have a huge impact on scheduling as porting is no small task.
Finally, just get your hands on the actual devices you need to target. Emulator is a good way to start, but there are always so many nuances and problems that pop up once you throw the app on the device that it's best to have your target devices from day one.