Database Develop

[Q] Android development capabilities

Hey guys,
I'm in the very very early stages of my masters work and I was toying around with the idea of using an Android tablet for part of it. I want to ask you devs what can be done when modifying the Android OS itself specifically in terms of a few things.
1. Logins - I would like to implement a classic user/password combination with levels of access for user, administrator, and some sort of superuser.
2. Restriction of User account - I would like to lock the user into one particular application. It must be relaunched when the device is booted and if the application crashes (hopefully not!) it must be restarted. Additionally, no market access, web access, etc.
3. Remote management if possible
4. Data encryption if possible
5. Prevent anything from being introduced from USB ports, SD slot, etc if unwanted.
I guess this brings me around to - is Android even the most suitable platform for such an endeavor. I'm not sure, to be honest, but I would love to get into development myself and this seems like a great way to learn. This is all just one part of a much larger project that I don't want to discuss just yet so sorry for being lax on details.
Thanks guys!

Android runs a virtual machine system called dalvik, in which each application gets it's own insuranceof the machine. It's implemented in such a way that each application gets assigned a user id, which unfortunately for you means each app is a different user, at least to the system. That's going to be a major wrench in the multi user plans. taking that into consideration, to have the same level of control over your tablet you'd have to give even the most basic user level "root" access or else the apps will start crapping their collective pants. As far as unwanted usb, there are a few apps that implement this functionality freely available through the market. Same with remote management. What I haven't seen yet is total encryption and I don't know enough about it to say it's possible or not. Seems feasible though.
My advice: write a custom login screen widget and then bake all these features into a pretty rom.

Xposed API changelog / developer news

This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.

This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).

Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.

Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.

IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.

2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.

In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.

I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse

Accessing features in Windows phone 8(.1) development

When developing an application for desktop windows, there's always a way to access functionality - sometimes through back doors like the registry, etc... I'm developing an application for Windows Phone 8.1, but there are certain pieces of functionality that aren't exposed in the PRT APIset that is available to me. For example, we want to ensure that the user has password protection on the lock screen when using the application. There doesn't seem to be any associated APIs to readily use. So my question is, are there back door ways to do such things? How? Is there a way to access ALL system settings - like a registry or something of the like?

proch said:
When developing an application for desktop windows, there's always a way to access functionality - sometimes through back doors like the registry, etc... I'm developing an application for Windows Phone 8.1, but there are certain pieces of functionality that aren't exposed in the PRT APIset that is available to me. For example, we want to ensure that the user has password protection on the lock screen when using the application. There doesn't seem to be any associated APIs to readily use. So my question is, are there back door ways to do such things? How? Is there a way to access ALL system settings - like a registry or something of the like?
Click to expand...
Click to collapse
Another question would be - if something like intune can enforce lock screen password policies, shouldn't I be able to do it the same way that intune does it? If so, how? If not - why not?

It's not possible to check if user enabled lock screen password or not as far as I know
but if you want to made your app secure (because it may include important data)
you can create a password for your own application !
I did it in a little notepad app my password page allow user to set a password with all English and Persian Characters , numbers and special Chars like [email protected]#$ and etc.

Sent from my RM-994_eu_poland_1183 using Tapatalk

It's pretty easy to check, using the registry, but at least in 8.0 that's not allowed at all for store apps (your app would get rejected). I don't know if the rules changed for 8.1. There are ways to sneak past the store checks, but they could pull your app from the store if they ever found out. I know of at least three ways to access the registry APIs (4 in WP8.1) and two of them are pretty hard to detect unless somebody checks for them specifically... but they're the kind of technique that malware uses, so such checks may be in place.
I don't know what InTune is doing, specifically - I'd need to pull the app apart to see - but there are special application capabilities (not normally available to third-party developers) that can query and even set policies. Apps without those capabilities will get Access Denied if they try to use the same methods though, and normally you can't add those capabilities to your app.

GoodDayToDie said:
It's pretty easy to check, using the registry, but at least in 8.0 that's not allowed at all for store apps (your app would get rejected). I don't know if the rules changed for 8.1. There are ways to sneak past the store checks, but they could pull your app from the store if they ever found out. I know of at least three ways to access the registry APIs (4 in WP8.1) and two of them are pretty hard to detect unless somebody checks for them specifically... but they're the kind of technique that malware uses, so such checks may be in place.
I don't know what InTune is doing, specifically - I'd need to pull the app apart to see - but there are special application capabilities (not normally available to third-party developers) that can query and even set policies. Apps without those capabilities will get Access Denied if they try to use the same methods though, and normally you can't add those capabilities to your app.
Click to expand...
Click to collapse
Thanks for this great and detailed information. See, that's exactly what I'd do if I were developing a desktop app - since i know that intune does it, I'd figure out how intune does it and voila. I'm finally getting over the idea that the same methodologies apply to windows phone development.
For my own educational purposes (since I want to understand this platform better), I would really like to know specifically how you go about accessing the registry APIs (for example). If there's any way for you to describe any number of these methods, I'd greatly appreciate it. Thanks again!

My NativeAccess libraries (check my signature, or search on the forum or on Codeplex) contain an example of one way to access the registry. The code is open-source; you may use the libraries as-is (don't expect to get them into the store, though I won't stop you from trying), use the source code as a reference, or modify/build them yourself; the license is very liberal (MS Permissive). The functions I use are generally documented on MSDN, in the desktop APIs section; the phone has the same functions, although the DLL names are changed and the header files hide them.

tag organization system

let me start off by saying that the xposed framework is absolutely awesome but if you've noticed recently just the amount of modules have just gotten a bit unruly I suggest adding some sort of tag system to help organize all the modules
for example some the tags could be device specific modules, type of module, android version etc.
ie. I would disable any tags with sense or touchwiz because I do not on that device and those modules wouldn't work on my device

This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.

rovo89 said:
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
Click to expand...
Click to collapse
For the Xposed modules index thread, I'm using 9 categories to separate modules by their function, and additional tags for modules that are specific to an Android version or vendor.
If you find that that makes sense and if you'd like to use it, I can share a CSV file (which is easily usable with Python, which is why I picked it) that should have the necessary info to easily add it to your server's data "automatically" (by writing a hopefully short script) (fields include, among others: tags and package name for each module).
I realize this needs discussion and will take a good amount of time and effort, but I'm just offering the index right now should you want to take a look at it. Also, if you think I/the community can make your life easier by categorizing modules with additional tags, I'm sure many will step up to help.

That is so kind of you! Thats awesome
I will also say that I wasn't very clear. (What it became is way awesome)
I meant only like an automatic way to get ones that won't work with my device to be hidden
My scenario for this was I have an aosp gpe tablet. And when I'm brousing modules I don't want to scroll past 6 experia mods that don't apply to me.

Appeal to rovo89

I am currently undertaking a research masters that involves the use of the Xposed framework. The research is into security on Android devices and in particular monitoring applications for malicious activity. For the dissertation I need to write a background section on the Xposed framework - who the autors are, when the work started, an explaination of how it works to some degree, etc. This writing needs to be factually correct. I would like to contact rovo89 to ask if he can fact check this writing.
I have not discovered an email address or any way to privately message a user.
Could rovo89 be kind enough to contact me at [email protected]?
Thanks