I recently refactored my package structure for an Android project and moved a BroadcastReceiver class to a different package. However, I forgot to update the receiver tag's android:name field in the AndroidManifest.xml.
This BroadcastReceiver was used to send notifications to the client and this serious error simply meant that no notifications were sent. Unfortunately there is no compile time validation of this file or, it seems, any runtime error thrown to indicate a misconfiguration here.
Is there anything I can do from my side to validate these types of configurations? Perhaps this information can be accessed in a unit test and verified? Or, perhaps there is more verbose output I can configure to make sure error like this don't go unnoticed in the future?
or, it seems, any runtime error thrown to indicate a misconfiguration here
A warning might have shown up in LogCat, but probably not, as having zero receivers for a broadcast is a perfectly normal condition.
Is there anything I can do from my side to validate these types of configurations?
You can file a feature request to have Lint validate this portion of the manifest. Or, you can write your own script to analyze your source tree and manifest and include this as part of a customized Ant build script.
Perhaps this information can be accessed in a unit test and verified?
You can use PackageManager and queryBroadcastReceivers() to confirm that the Intent you use for broadcasts will resolve to 1+ receivers.
Related
I have encapsulated permission check into utility method and now I am receiving
Call requires permission which may be rejected by user: code should
explicitly check to see if permission is available (with
checkPermission) or explicitly handle a potential
SecurityException
error.
Like this:
Is it possible to smart control this error, for example, by adding some annotation (not just completely disable checking)?
Is it possible to smart control this error
This is not error per se but warning generated by static code analyser, most likely by bundled Lint. If that is so, you can suppress it by using #SuppressWarnings() annotation. See official docs on that: Suppressing Lint Warnings
I'm preparing my app to target Android 6.0 Marshmallow.
When setting the target api to 23, the app immediately crashes upon launch. There is no useful information in the logcat output. (It gives a "Requested window does not exist" IllegalStateException, but still, nothing actually useful like class name or line number.)
This is fine (not really), I eventually narrowed it down to my launch activity where I get the user's device IMEI code (TelephonyManager.getDeviceId()). There needs to be a runtime permission request added. I understand this.
However, the app has something like 60 classes across numerous activities, so there is a lot of code to sort through. How can I possibly search through the code to find all of the cases where runtime permissions are required?
Surely Google must have thought of an easy way for developers to track down where the permission requests are required? I thought perhaps commenting out the permissions in the manifest would trigger a compile-time error where the permissions are used, or something of the sort, but nope.
My current method is by going through the app and when it crashes, do like the above with my launch activity and very slowly narrow down where it is. This is extremely inefficient and time-consuming. I'm tempted to just leave it at API 22 for now, but I know sooner or later this will have to be done.
Delete all AndroidManifest.xml permission.
Analyze -> Run Inspection by Name ->Constant and Resource Type Mismatches in Android Studio.
You can detect permission.
But this detection is not perfect...
Because this detects only method that contains this xmls files.
https://android.googlesource.com/platform/tools/adt/idea/+/master/android/annotations/android
https://android.googlesource.com/platform/tools/adt/idea/+/master/android/annotations/android/accounts/annotations.xml#118
What worked for me is this :
Analyze -> Run Inspection by Name -> Missing Permissions
I had earlier written a standalone daemon to access a custom device (/dev/mydev0). Looking at AOSP source, I figured I needed setup policies in following files to make it work:
new file device.te containing:
type mydev_device, dev_type;
new file mydevsrvc.te containing
# service flash_recovery in init.rc
type mydevsrvc_type, domain;
type mydevsrvc_type_exec, exec_type, file_type;
init_daemon_domain(mydevsrvc_type)
allow mydevsrvc_type mydev_device:chr_file rw_file_perms;
edited file_contexts to add:
/dev/mydev[0-9]* u:object_r:mydev_device:s0
edited service_contexts to add:
mydevsrvc u:object_r:mydevsrvc_type:s0
And started the daemon by editing init.flo.rc to include these lines:
service mydevsrvc /system/bin/mydevsrvc
class main
user system
group system
seclabel u:r:mydevsrvc_type:s0
oneshot
Now, I need to access the device in android apps, so I must change the daemon into an android system service.
I can startup the service (thread) using BOOT_COMPLETED intent as explained in a previous question
I am not able to figure out how to setup SELinux policies so that this java service is also able to access the dev file.
[Update] I have continued using privileged daemon for this purpose. My java service connects to daemon through sockets. I don't have a better solution.
I finally figured out the answer. Posting it here, because there sure will be SEPolicy noobs like me looking for similar answers.
For this work, I needed to be able to access my device file from my java app that implements my service.
I needed to add following rule in my sepolicy directory, in a new file:
allow system_app mydev_device:chr_file rw_file_perms;
Also, needed to make my service app run in system_app domain. For this, I need to:
Install in priv_app during Android build.
Sign it with platform key
Declare shared user id in manifest: android.uid.system. I found that without this, app runs in platform-app domain and wasn't able to access my device file even with corresponding change in SEPolicy rule. Not sure why though, I didn't bother to debug.
It might also be possible to run my Service app in mydevsrvc_type domain. I didn't find out how to do that, or whether that will work.
Here is a brief summary of the steps needed to implement SELinux on your Android device:
Add SELinux support in the kernel and configuration.
Grant each service (process or daemon) started from init its own domain.
Identify these services by:
Reviewing the init..rc file and finding all services.
Examining warnings of the form init: Warning! Service name needs a SELinux domain defined; please fix! in dmesg output.
Checking ps -Z | grep init output to see which services are running in the init domain.
Label all new processes, drivers, sockets, etc. All objects need to be labeled properly to ensure they interact properly with the policies you apply. See the labels used in AOSP for examples to follow in label name creation.
Institute security policies that fully cover all labels and restrict permissions to their absolute minimum.
Ideally, OEMs start with the policies in the AOSP and then build upon them for their own customizations.
for more https://source.android.com/security/selinux/implement.html
In response of your question to start service from init rc
you can just write one rc file like below. Where it will start your service on receiving of boot_completed
on property:sys.boot_completed=1
start mydevsrvc
for reference http://androidxref.com/9.0.0_r3/xref/device/generic/qemu/init.ranchu.rc#60
Possibly add a line in your ueventd.rc file or project specific to give the permission
I am having trouble testing native applications (such as Contacts and Settings) using Cucumber-JVM for Android with JUnit. Initially, I got the following message:
"Test run failed: Permission Denial: starting instrumentation ComponentInfo???{com.test.contacts/android.test.InstrumentationTestRunner???} from pid=673, uid=673 not allowed because package com.test.contacts does not have a signature matching the target com.android.contacts"
To solve this problem, I signed the test application with the same keys of the Contacts native android application (shared.x509.pem and shared.pk8) and I also added the following line to the AndroidManifest.xml file (as suggested in How can I sign my application with the system signature key?):
“android:sharedUserId="android.uid.shared"
This seemed to solve the problem.
However, after this change, I only manage to run the first test from a test suite. When the second test is running, it gets lost in the getActivity() method from the class ActivityInstrumentationTestCase2, which my steps definitions class extends. More precisely, it doesn't get out of the mSync.wait() call in the method startActivitySync(Intent intent) from Instrumentation.java. The call to getActivity() calls launchActivityWithIntent(), from InstrumentationTestCase.java, which calls startActivitySync(Intent intent).
I found a similar issue on Why does getActivity() block during JUnit test when custom ImageView calls startAnimation(Animation)?, but the workaround described there doesn’t solve my problem.
My test application is really simple and it only checks the content of the buttons in the activity. I don’t have this problem if I use the same test application to test my own apps, only with native android applications such as Contacts and Settings.
Does anyone know something about this issue and could give me a light on how could I solve it?
Thanks in advance
I want to clean up log entries that appear logcat as well as other tools that report calls to Log.x(), such as Crashlytics.
There are quite a few entries appearing that I did not explicitly create, that have my application's unique identifier (e.g. com.example.myapp). Some examples are tags like: Adreno-EGL, MediaPlayer, jdwp, dalvikcm, Zygote, Crashlytics, OpenGLRenderer.
Can I intercept and filter these? Or disable invocations outside of my code altogether?
add a filter on the top field of your logcat like app:. you can also filter by tag (tag: or even by anything you want to find within the messages (just type a phrase you want o filter by). There are also pid: that corresponds to process id (its helpful when youre filtering app which is already released / not in debug mode as there is no application tag visible).PS You just can't disable the logs permanently