onPerformSync(...) {
// building status bar notification here
}
<service android:name=".SyncService" android:exported="false"> ...
This works for me (4.4.2 SGN3). Notifications appear. Both requestSync() and addPeriodicSync().
Do anybody has some thoughts about?
Is there need for exporting SyncAdapter service?
What am I actually wanna know is whether any other (enemy) application can start my exported service or not. If they can, I don't need to export the service hoping Android isn't so liberal.
I haven't find any clarifications in the Android dev guide/api. I'm pretty novice and I hope my question is correct and understandable enough :)
I suppose you need to export SyncService for using it from other applications. This is what documentation says:
The attribute android:exported="true" allows processes other than your app (including the system) to access the Service.
If you don't need to share your sync service to other apps, probably you can leave it not exported. But you need to test it on old versions of android, it's logic might has changed.
Related
I'm implementing an alarm application for Android with Flutter. With the android_alarm_manager package, I'm able to create and receive alarms. Furthermore, the package bringtoforeground is useful to bring the application to foreground when using another app. However, I haven't found a way to wake up the phone screen, yet. Does anybody knows how to do that? Also, It should be possible to have the application open without entering a password or something comparable.
Thank you in advance!
I've found an answer to my question. Additionally to the two packages said, there is a modification to be made in the AndroidManifest.xml file. Two more properties are needed in the activity tag as follows:
<activity
android:showWhenLocked="true"
android:turnScreenOn="true">
Background
I just noticed some functions of NotificationManager that handle a class that's called AutomaticZenRule :
https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule(android.app.AutomaticZenRule)
and others...
The problem
Looking at the docs of AutomaticZenRule, it still doesn't tell much about what it is, and what can it be used for:
Rule instance information for zen mode.
What I tried
Searching the Internet, I can see just in a Commonsware blog post, that they wonder what it is:
It is unclear what AutomaticZenRule is ...
There is practically nothing more that I've found about it. Not "zen mode" and not "AutomaticZenRule".
The questions
What is "zen mode" ?
What is "AutomaticZenRule" , and what can I do with it? How is it related to notifications?
Is there anything special on Android N, that this API was added on this version?
Is there a sample for using it?
Zen Mode is just another name for Do Not Disturb (DND) mode. Android can activate DND mode based on rules. These rules can be provided either by the system, or by a third-party app.
In the following screenshot you can see two system-provided rules, together with a "Driving" rule provided by the third-party app "Pixel Ambient Services":
AutomaticZenRule is there to integrate your own rules into the Android system. To integrate your own rules, you have to follow these rough steps:
Make sure that you have sufficient permissions to access the DND policy (android.permission.ACCESS_NOTIFICATION_POLICY). See NotificationManager.isNotificationPolicyAccessGranted() for details.
Add an activity for your rule:
<activity android:name="MyRuleConfigurationActivity">
<meta-data android:name="android.service.zen.automatic.ruleType" android:value="My Rule" />
<intent-filter>
<action android:name="android.app.action.AUTOMATIC_ZEN_RULE"/>
</intent-filter>
</activity>
Android will show your activity whenever the user wants to create or edit a rule of the specified rule type. In the latter case, Android will supply the ID of the existing rule in NotificationManager#EXTRA_AUTOMATIC_RULE_ID. To propagate changes in your activity back to android, you need to construct an AutomaticZenRuleinstance and call NotificationManager.addAutomaticZenRule / updateAutomaticZenRule.
After that, you can tell Android that the conditions for your rule are currently satisfied / not satisfied by calling NotificationManager.setAutomaticZenRuleState.
From digging in into the other documents available, i was able to understand ZenMode to some extent(although it can be my own version and not the correct one).
What my understanding is as follows -
Zen Mode is the Do not Disturb mode which now in latest updates can be enabled automatically which depends on factors such as late time of the day, etc. AutomaticZenrule can be used by applications who want their notifications to not be masked or suppressed when in do not disturb mode.
For this your application should make request to policy access by sending the user to the activity that matches the system intent action ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS.
If user has granted access to notification policy for your app, then you will be able to set a priority notification even in do not disturb mode. AutomaticZenrule thus plays a vital role to state the system that the application's notifications not be suppressed.
Although, i dont have a running sample code for it, i guess it should be on similar lines like the enabling device admin code or requesting a permission use case.
Thanks to you i got to read something new :)
I've implemented a WearableListenerService in both my main app and the companion Wear app. In the manifests, the service needs to be declared as android:exported="true" (or not declared at all and left to default to true) since it's started by Google Play Services. An exported service with no permissions can be called by any app on the system, but I can't find the correct permission to add to the service declaration to secure it. I've looked through the permissions on both the phone and the Wear device with pm list permissions but I don't see anything that looks like what I need.
Is there a permission that I can/should add to secure my services?
If not, is it a good idea to manually secure the service by checking the package name of the caller?
The best way to see how to implement a WearableListenerService on Android Wear is to look at one of the existing samples provided by the SDK. If you look at the DataLayer sample included at $SDK/samples/android-20/wearable/DataLayer it has a full implementation of what you are wanting to do.
If you look in the AndroidManifest.xml for the wearable side, you can see it has the following:
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
<service
android:name=".DataLayerListenerService" >
<intent-filter>
<action android:name="com.google.android.gms.wearable.BIND_LISTENER" />
</intent-filter>
</service>
For your security concerns ... When we declare a service in manifest and add a filter to it, it automatically becomes an exported service. So in general, other apps can bind to that service. In case of WearableListenerService, there is a security check that happens in the framework to make sure that the agent binding to that is Google Play Services so no one else can really bind to that service, unless the app developer exposes other intent filters in which case the intention is for others to access it.
So if you implement your code in the same way as the Wear SDK samples, your app should be secure and you do not need to worry about any extra permissions, etc.
Is there a permission that I can/should add to secure my services?
If not, is it a good idea to manually secure the service by checking the package name of the caller?
You don't need to worry about securing your WearableListenerService implementation with permissions or caller package checks. As #Wayne pointed in his answer: there is a security check that happens in the framework. This check is done in the WearableListenerService base class. You can find further security analysis of the Wearable SDK in the following article:
https://labs.mwrinfosecurity.com/blog/android-wear-security-analysis. Here is the quote from it:
The method pr() first checks if com.google.android.gms is Google
signed and then calls cU() to check if the calling process UID is for
the package com.google.android.gms (the Google Play Service package).
If the class is further decompiled, it can be seen that this security
check happens in each method exposed in WearableListenerService.
Unfortunately currently Lint checker produces false positive warning for the wearable listener service declaration whenever it doesn't contain BIND_LISTENER filter (which inclusion produces other warning since it's now deprecated and should be avoided):
Exported services should define a permission that an entity must have in order to launch the service or bind to it. Without this, any application can use this service.
This is certainly a bug in the security detector code (it just wasn't updated when BIND_LISTENER intent became deprecated). I've opened an issue regarding this on the Android bug tracker. Meanwhile to get rid of the warning one needs to add tools:ignore="ExportedService" to its wearable listener service declaration.
I want to implement a service which should be running like standard system service on boot up, this service should not be kill-able and should be able to perform action on receiving notification from another process.
Can anyone help me which is the best methodology (AIDL) to create such service,if any example for reference ?
You can't do this unless you are creating your own system ROM.
If creating your own ROM, you can start by modifying the AndroidManifest of the apk containing your service. You need to add an attribute to your manifest node: android:sharedUserId="android.uid.system". That will cause your APK to hold the system ID (which requires the APK to be signed with your platform signing key -- this is why you need to be creating your own system ROM.
That will allow your application to be considered special by the system, and (at least on 4.x, I haven't tested on older Android versions) your application will be auto-started. The application being auto-started doesn't mean much on its own though; either you need to implement a BOOT_COMPLETED receiver as #febinkk suggests, or you can provide a custom Application override (by adding the attribute android:name="your.package.ApplicationSuperClass" to your application node in your AndroidManifest.xml). In your application super class, you can overload onCreate() and have it start your service or whatever else is required.
Additionally, as a system application, I believe (though have not fully tested) you will not be able to be killed through normal means.
You are not able to create non-killable, immune service without creating your own ROM
You could register a BroadcastReciever with filter for android.intent.action.BOOT_COMPLETED for your service and after starting call startForeground(). This may not be what exactly you were looking, but this is probably the only thing that comes near, if you don't want to create ROM.
I'm looking at the description for the Plan B app here: https://play.google.com/store/apps/details?id=com.lookout.labs.planb. It says it will start automatically after installation. How do you configure an app to do this?
Register to receive common intents. One especially suitable for your purpose is:
"android.intent.action.PACKAGE_ADDED"
You might also listen for other intents such as BOOT_COMPLETED, etc.
Edit: According to another Stack Overflow answer, You can't run your own application immediately after it's installed. You must register for other intents as I suggested. Something to note is that you app will require user permission to receive the BOOT_COMPLETED intent.
Update: As pointed out by zapl, post 4.0 you cannot do anything after install now until the user explicitly launches your app.