I had to perform a simple task recently: set up the Battery Swap application on out TC51 as a Device Administrator, so that it can do its battery swapping preparations correctly (for some reason it’s not set up as such by default). MX and StageNow allow this via the DevMgr CSP. But that CSP requires Package Name and Class Name. Let’s find out and do some more package dumping for fun and profit!
In quite a few situations we need the user to input specific data during device Staging. For instance, I have been doing a job for a customer, requiring a PIN code pre-set on the device, when it comes back from repairs. This PIN code can only be set programmatically by Device Administrator class app (or MDM agent, which usually registers as one). Given the circumstances, this was not an option.
Normally, this means that you’d have to provide instruction containing lots of “tap this” and “skip that” as well as lots of screenshots to ensure that there is no way the user will be lost. However, this approach is error prone and time consuming. And for repair loop operations this means $$$. Wouldn’t it be better to just scan a barcode? But how?
Each page of the Settings app in an Activity. Thus, we can write an intent to pop it up. StageNow (via MX) allows us to run intents. The question is, how do we find, which data to populate the intent with? Let’s find out!
TL:DR – RIP SOTI PocketController, does not work with M+ and the official SOTI reply is “not supported anymore”. Anyone knows another stable tool?
There is a significant number of posts on the internet regarding how people hate bloatware that comes bundled with their devices, how it eats at their precious internal storage space and how they would want to uninstall it (which is impossible w/o rooting your device). While I agree with one’s right to hate the bloatware, everything else is a delusion. Let’s take a look.
Ever wondered how Android decides how many bars to show in the WLAN indicator? (Well, the “bars” are gone, but there’s still exactly the same number of levels) While going through Android source code I’ve found this:
* RSSI levels as used by notification icon
* Level 4 -55 <= RSSI
* Level 3 -66 <= RSSI < -55
* Level 2 -77 <= RSSI < -67
* Level 1 -88 <= RSSI < -78
* Level 0 RSSI < -88
/** Anything worse than or equal to this will show 0 bars. */
private static final int MIN_RSSI = -100;
/** Anything better than or equal to this will show the max bars. */
private static final int MAX_RSSI = -55;
So, now you know! Of course, vendors may change these values, but let’s hope they don’t! 🙂
Why is this important? This the basis of Android’s Poor Link Detection Watchdog – the thing that causes your WLAN clients to switch to another WLAN profile or to WWAN entirely when you least expect it. But I haven’t grok’d all the code yet. Stay tuned…
Yesterday marked the end of support for WEH6.5 (based on WM6.5). Essentially, the support matrix for MS mobile OSes now looks like this:
In my recent Android trainings and the Android security talk I gave at AppForum 2014 I was asked to provide a sort of a demo that can be easily replicated to explain the importance of maintaining a proper security posture. So I created a script that ‘recovers’ PSKs from the device and displays them.
Before moving on, a brief disclaimer: Android (or iOS, or Windows) are pretty secure, it is up to the user how much of this security is traded for convenience (or ignorance).