Consider
PackageInfo info1 = pm.getPackageArchiveInfo(apkPath,PackageManager.GET_PERMISSIONS);
In this statement, by using GET_PERMISSIONS I can get the set of all permissions used in the application.
In the same way can i get the API calls?
Thank you. I am new to this android programming if it is a simple question please forgive
No, you cannot get the API calls by any easy method, and arguably not even by a hard method.
If you had access to the application's installed .apk (and at least on older Android versions you did), you could read through it for obvious invocations of platform functions. (This is a form of "Static Analysis")
However, Java (and hence Dalvik) supports a mechanism called "reflection" which allows looking up and calling functions by name - a name that could be constructed at runtime by circuitous means, or user or network input.
Much of the actual functionality used for calling functionality in the system process is also ultimately performed by name, making another place where functionality not present in the static file could be added at runtime.
Finally, the native underlayers of Android (and likely the DVM as well) permit a determined programmer to dynamically designate arbitrary "data" to be "code" and then execute it.
Related
Other questions on this topic have been asked here:
Classes for Permission Checks Android
how are android security permissions checked at run-time?
How does Android enforce permissions?
But none of them answer what I am trying to figure out. I want to know where exactly I can find the functions or methods that literally check the permissions I'm requesting to see if I'm allowed to have that permission. More specifically, I want to find out what happens with Android Instant Apps permissions, since IA allows only a fraction of all Android permissions (the list can be found here https://developer.android.com/topic/google-play-instant/faqs).
For them there has to be a check somewhere, a whitelisting method that takes the permissions I'm requesting, understands that my application is an Instant App (rather than a normal one) and so it knows to check what I requested against that limited list only. That way it ensures I cannot ask permissions that are not even supposed to be allowed.
I want to understand and see where this happens, source code of these checks, especially for Instant Apps. I have started from the checkSelfPermissions() function used when implementing the Android Runtime Permissions. Through the function call trace feature in Android Studio and the xref (http://androidxref.com)
I went back as much as possible until I found the Context.java file (http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/java/android/content/Context.java) which has the prototype declarations with comments for each function.
public abstract int checkPermission(#NonNull String permission, int pid, int uid);
I just don't know where to find the definitions with the actual function body and code for it though. Context.java doesn't have them. And I think I am going more and more down a rabbit hole and a bit too low-level with these:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/java/android/content/pm/PackageManager.java#532
http://androidxref.com/8.1.0_r33/xref/frameworks/native/libs/binder/IPermissionController.cpp#39
http://androidxref.com/8.1.0_r33/xref/frameworks/native/libs/binder/IPermissionController.cpp#39
especially the last two, which not only do I not know if I'm on the right path with them, but I'm trying to figure out that remote()->transact function now and where it's defined, but we're in android native c++ territory now...
Any help or pointers would be immensely appreciated, it shouldn't be that hard to just go through the AOSP source code, right?
For future reference, in the end I have managed to solve it. It took way longer than I thought, but as it happens with most things, the answer was a lot simplier than thought.Turns out that yes, I was definitely going down lots of rabbit holes, but only up to a point. This whole process of search was actually useful in realizing where the answer would lie.
So the first step was successfully finding the actual proper, "low-level" implementations of the permission check or the permission granting action, and the functions are grantRuntimePermission and checkUidPermission, both in the PackageManagerService.java class. Here are the interesting bits, of each function:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java#5655
http://androidxref.com/8.1.0_r33/xref/frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java#5335
That is where the checks are being performed, but the system somehow already "knows" about the permission and that it is runtime or not, instant or not. The crucial bit (which also kinda hinted to me what eventually I found the answer to be) is to look at the BasePermission objects created.
I found that the Android OS treats permissions in a more modular way, where each permission, rather than left as a simple string to do a check against, gets transformed into an independent BasePermission object. This gives it a more defined importance, as these objects now contain, besides the permission name, attributes such as the sourcePackage name, permission type, UID that owns the permission, and most importantly, the protectionLevel, amongst others. Here is the BasePermission.java class:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/services/core/java/com/android/server/pm/BasePermission.java#23
It seemed that the BasePermission objects get created within each application, based on that application. So in the context of an instant app, the Android OS attributes the permissionLevel to each individual permission object accordingly as it learns the application is, in this case, Instant. Here is the important bit of code:
if (isUidInstantApp) {
BasePermission bp = mSettings.mPermissions.get(permName);
if (bp != null && bp.isInstant()) {
return PackageManager.PERMISSION_GRANTED;
}
} else {
return PackageManager.PERMISSION_GRANTED;
}
So it's possible to see how it creates the BasePermission object, based on permName, from a list/array of pre-created permission objects (mSettings.mPermissions) that the System somehow builds for the current application only. This only answers the "where is the permission check made?" question, but now the problem is "how does the system know how to create the BasePermission objects and assign to each of them the correct protectionLevel?". Initially I was completely unable to find where the "mPermissions" list gets populated. Then it hit me: I didn't actually need to know that.
All Android permissions and their names are defined in the global AndroidManifest.xml file. Whenever you use permissions in your application code, you call the Manifest.permission.PERMISSION_NAME string, right? I thought that the manifest would only contains the names of each permission, declared as a string. What I didn't expect was that the only other tiny piece of information the manifest declares is (you guessed it)... a per-permission protectionLevel value. For each permission it would state if it is a "normal" permission as opposed to the "dangerous" ones, as well as if it can be used for instant apps or not. And as expected, only the 10 (at the time of this writing) defined permissions for instant apps from the official docs had the "instant" attribute beside the other available protection levels. Here's one of them:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/res/AndroidManifest.xml#773
That is how the system knows to build the BasePermission objects, wherever it does that. And there was the whitelisting that I was looking for.
Even if I did look at the manifest as first step in my research, I probably wouldn't have known that the answer was right there in front of me. The knowledge of BasePermission objects was crucial to understand how the permission model and checks are implemented.
Next step now would be to actually find where exactly the system creates the base permission object based on these protection level strings in the manifest. I am guessing there should be an association of those strings to a binary integer such as "normal" or "normal|instant", number which is then used by the BasePermission class to construct the objects' protection level and ultimately define if they're instant.
Is there a mechanism for observing changes in system properties from your own app in Android SDK?
For example, I want to be able to detect changes in the system.adb.tcp.port property.
As of API 25 there's no public API for this. You need to dig down into internal functions that only exist to exercise the system.
See __system_property_wait_any() in sys/_system_properties.h. The need to define _REALLY_INCLUDE_SYS__SYSTEM_PROPERTIES_H_ shows that its use is even discouraged internally.
I wouldn't use this in an app. A quick grep of AOSP indicates that it's only used in test code, so there doesn't appear to be a "friendly" API that makes use of it.
I think you're stuck with polling System.getProperty().
I don't think exist a mechanism to do this., but you may be able to retrieve system properties by executing getprop in a Process and retrieve its output.
or try this link : [for System.getProperty()]
http://developer.android.com/reference/java/lang/System.html#getProperty%28java.lang.String,%20java.lang.String%29
For C/C++, please call WaitForProperty defined in "android-base/properties.h" and libbase.
For Java, please call OnPropertyChangedCallback in class Observable.
I'm working on a collage project about security in Android. One part of the project attempts to capture and log all API function called by the selected APK. This can't be done with a external programs so in the project we are working with the Android source code to modify the ROM.
At the present time we only have two possible solutions:
DVM JNI Bridge
The API is Java code so, obviously, the Dalvik Virtual Machine needs a bridge to execute JNI code. The function which handle all cases is dvmCallJNIMethod(const u4* args, JValue* pResult, const Method* method, Thread* self). In this function we can get the name and the class of the called function.
This function can log all the JNI code executed, which includes API calls. But there is no easy way to distinct between private calls and API calls. And, if we wanted to execute some code depending on the risk of the API call executed, we would have to create a huge and inefficient switch.
API Framework
another solution To log all API calls is creating a new interface for the framework. With a new logging class and a simple inheritance should be easy to log all calls and add a risk parameter. But it would mean changing a lot of code. Also, Java code has worst performance than C, so it might not be the most efficient way.
More over, we would like to ask you a few questions about Android DVM and the API.
1.Which is exactly the call flow between DVM and the API?
2.Could be the DVM monitor a good idea to log the calls?
3.Which role have the shared libraries in all of this?
4.Are all API calls really Java code?
Thanks for your time.
I've been trying to figure out how an android app is installed by browsing AOSP.
The PackageManagerService.java has the gids for the corresponding permissions by parsing the platform.xml file.
PackageInstallerActivity parses and checks for any existing packages and then invokes the InstallAppProgress.
I was able to follow the paths where the package is parsed and validated and PackagerManager.installPackage() method is invoked from InstallAppProgress.initView() to install the package. I know this makes a native call to the JNI library. The corresponding .aidl file is IPackageManager.aidl.
What I want to know is where can I find the implementation of the Stub (or Native code if any) related to this aidl mentioned above?
I'm new to aidl so that is the reason I'm not able to understand its nuances completely. Could somebody kindly point me to the right direction?
So AIDL files are there to define how the service and client talk to each other. They are important for system services because they need to handle multi threading, and there are lots of different apps that may want to talk to it. So IPackageManager.aidl is there to allow clients to communicate to PackageManager.
I took a look at InstallAppProgress.initView() and I don't see a specific call to native code. There is a call to PackageManager here:
pm.installPackageWithVerificationAndEncryption(mPackageURI, observer, installFlags,
installerPackageName, verificationParams, null);
So to explain how this chain works, InstallAppProgress gets the PackageManager from context, which if you follow that chain leads to ContextImpl.getPackageManager() which you will see actually returns the ApplicationPackageManager which extends the abstract PackageManager class.
ApplicationPackageManager has a reference to the actual PackageManagerService which it calls through an interface, which is defined by the aidl file IPackageManager. The manager here is just controlling access to the service, and defining what is and is not actually accessible to the outside world. Apps can not normally get a handle to the PackageManagerService, IIRC it is possible to do so but you must have system privilleges.
To get a better explanation on what aidl files actually are, check out the page on the android site here: Android Interface Definition Language
Although not documented in the Notification Documentation, looking at the Notification.java for Jelly Bean there is an extras Bundle with an EXTRA_PEOPLE key defined.
The type is listed as TBD, can anyone from Android provide direction as to what this may look like? Do you expect this to be a list of String names, or maybe Long rawContactIds? Will there be any recommended ordering (such as meeting organizer versus attendees, or a Gmail From versus CC)?
Are there any changes in Android 4.2 that will utilize this, or is this still truly TBD?
Even if it is filled out now, relying on it is risky- if it's labeled TBD then they can change it in any minor release without telling you, any code depending on it is likely to break. I wouldn't risk it for anything I was releasing.
If you want to test it out though, write an app that uses it and use java reflection to get the class name of the object and print out the values. If its a collection class, repeat on whatever object it holds and let us know.
Still truly TBD.
(General rule: Avoid using anything that's marked #hide unless you really know what you're doing.)