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.)
Related
I'm using the app DevOptsHide to make other apps think the developer mode is disabled. To summarize, we are hooking into Settings.Global.getInt() and Settings.Secure.getInt(), and override values of Settings.Global/Secure.ADB_ENABLED and Settings.Global/Secure.DEVELOPMENT_SETTINGS_ENABLED constants.
I found some points of interest, but I'm not an Android developer, and the app author isn't willing to spend much time working on the app anymore, thus I'm asking the questions here in hope to find some insights.
The originating discussion can be found on DevOptsHide issue #17. The main code is at HideDevOpts.kt.
My questions are:
I am right when I spotted that when hooking into Settings.Secure.getInt(), in the hook param equals Settings.Secure.* thus detection of access to the desired constants fails, as currently the only checked names are Settings.Global.*?
I am right when I pointed out that as handleLoadPackage() is executed for each and every package loaded, Settings.Global.getInt() and Settings.Secure.getInt() end up with a huge stack of registered hooks?
But maybe there is some singleton mechanism?
On the other hand, if you confirm there is an issue, how could it be fixed? Could initZygote() be used instead (maybe it runs too soon)?
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.
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.
There are some parts of the framework which are not quite clear to me yet. I am well known with the flow of an input event (Kernel -> Eventhub -> InputReader -> InputDispatcher -> ...).
Situation
(Requirements: Handle input keys without changing the Android Framework.)
I want to handle key events coming from a device (keyboard/gamepad/controller/...) but there are some requirements. For one, I don't want to change the Android framework. This means, I don't want to extends the WindowManagerPolicy and its functions like interceptKeyBeforeDispatching where the home-key is being handled. This would result in the key event being dispatched into the application layer which is fine. The downside is, I have another tricky requirement here.
Example: When I am playing Angry Birds and I press my GoToAlpha-button on my connected input device, the Alpha-application has to start. Angry Birds has no clue which button GoToAlpha is, will not handle/recognize it and there will be for example no intent broadcasted to start my Alpha-application.
Question
Is there a way to handle my (custom) key event after it is being dispatched, knowing that the application in the foreground can not handle the key?
My (failed) solutions
Create a service which will handle the key events. This is not possible because an application like Angry Birds will not bind to my service and the key event will not be caught inside my service. If I am wrong, please provide more information :).
Create an external library where I allow my application's activities to inherit from my own ActivityBase. All the key events and there default behavior can be handled here. Downside, existing applications will not support my custom key events because they don't use the library.
Extend the framework would be in my eyes the cleanest solution but that will result in not meeting my requirement.
Any help or useful information would be appreciated
Extra
If the first question could be solved on one way or another.. I want
to customize my Intent behind the GoToAlpha-button. This means.. By
default the Alpha-application will be started but after the user has
customized it, the Beta-application will be started from now on.. Any
thoughts?
Thanks
Thanks for the comment Victor.
Using the InputMethodService will not provide me with enough freedom and functionality to handle my problems.
My Solution / Compromise
Within the Android Framework, there is a PhoneWindowManager which is responsible for handling InputEvents. The WindowManagerService which is started by the SystemServer, is owner of this manager and creates an instance.
By creating my own custom WindowManager and let it inherit from Android's PhoneWindowManager, I don't lose any default functionality and this allows me to add my own implementation within this class. This results is adding a new file to the framework and changing only one line inside the Android Framework: The WindowManagerService will not create a PhoneWindowManager, but will create a CustomPhoneWindowManager (extends PhoneWindowManager).
If anyone sees a better solution or has any specific thoughts about my compromis, don't hesitate to comment. :)
I doubt that it's possible with public API's (Boy and Martijn pointed out security concerns).
Most like your best bets (if you don't want to customize Android) would be
a) Try to use InputMethodService (http://developer.android.com/reference/android/inputmethodservice/InputMethodService.html)
It doesn't give that kind of control which you wish, but it could be enough for some needs.
b) Try to go through whole stack (from Kernel to Application) and find some vulnerabilities to use.
This definitely will take a lot of time and doesn't guarantee to bring any fruits.
Firstly, I'm not looking for time spent on a given application. There is already "an app for that", com.android.settings/.UsageStats, and a good deal of supporting code in the AOSP frameworks/base/services/java/com/android/server/am/UsageStatsService.java, etc.
The code that I've examined so far does not seem to record elapsed time spent on particular <activity>s. I have thought to get this information two ways, but feel there must be something cleaner and simpler, that leverages more existing code. The ideas have been:
Instrument the base Activity class onPause() and onResume(), to hack in a timestamp, and log the info some place (probably a SQLite database.)
Instrument the Context class, to make note whenever startActivity() and friends are called.
So what do you think -- anything better than those options? Thank you in advance!
So what do you think -- anything better than those options?
Anything is better than #2, which requires custom firmware.
#1 is your only option within the SDK for API Level 13 on down AFAIK.
API Level 14 (a.k.a., Android 4.0) added in Application.ActivityLifecycleCallbacks, which you can register via registerActivityLifecycleCallbacks() called on your Application (e.g., getApplicationContext()). I haven't used these yet, but it would appear that you can arrange for a single listener to be notified of activities coming and going, avoiding forcing you to extend some common base Activity class with your desired logging.