Develop Reference

Android DeviceAdminReceiver: onNetworkLogsAvailable intent never received

UPDATE
I'm noticing that I actually am receiving the NETWORK_LOGS_AVAILABLE intent! The problem is, it's taking a very long time (over an hour?) to receive it.
Is there any known way to increase the frequency of receiving these events?
Original Question
I am trying to process DNS events that can now be read after receiving the onNetworkLogsAvailable intent in a DeviceAdminReceiver application. This functionality was made available as of Android 8.0.
For some reason, I am never receiving this intent, even though I am successfully calling the setNetworkLoggingEnabled method. Upon admin being enabled, I am receiving the ACTION_DEVICE_ADMIN_ENABLED event, but nothing else after that.
Here's where I enable network logging:
public class NetworkAdminReceiver extends DeviceAdminReceiver {
#Override
public void onEnabled(Context context, Intent intent) {
DevicePolicyManager manager =
(DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE);
if ( manager == null )
{
throw new IllegalStateException("Unable to get DevicePolicyManager");
}
if (manager.isDeviceOwnerApp(context.getPackageName())) {
manager.setNetworkLoggingEnabled(getWho(context), true);
}
else
{
Toast.makeText(context, "This application is not device owner. DNS logging only works" +
" when this application is setup as the Device Owner", Toast.LENGTH_LONG).show();
}
}
// *snip* rest of class
}
Although I am not sure whether it's required (cannot find in documentation), I've also added the NETWORK_LOGS_AVAILABLE intent action to the receiver's filter:
<receiver android:name=".admin.NetworkAdminReceiver"
android:label="#string/device_admin"
android:description="#string/device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<meta-data android:name="android.app.device_admin"
android:resource="#xml/device_admin" />
<intent-filter>
<action android:name="android.app.action.DEVICE_ADMIN_ENABLED"/>
<action android:name="android.app.action.NETWORK_LOGS_AVAILABLE"/>
</intent-filter>
</receiver>
The application is marked as the device owner, network logging is enabled, and yet I never receive the intent. The only explanation I could think of is that network logs do not become available very frequently, but I could find no documentation supporting this theory.
I am also currently only testing this in the emulator. I am unsure if that would have an effect on this, though I cannot see how it would.
Is there anything that I am missing in order to properly receive the network logs via the DeviceAdminReceiver?

I'm afraid there's no elegant solution.
This limitation looks like it was made intentionally. As you can see in the sources, the event is triggered when hard-coded thresholds are reached. It's either 1200 events or 1.5H timeout, whichever comes first. I did not manage to find any usable hooks in the NetworkLogger. They definitely did not want users to meddle with it.
The only option I see is to use reflection to get access to the hidden API.
The most straightforward, IMHO, is to get a handle to the IIpConnectivityMetrics service and use it to subscribe to the network events. I did not test this solution myself, though.

It seems like you can now force retrieve log for debugging purposes as described here: https://developer.android.com/work/dpc/logging#development_and_testing
Quote from the documentation:
While you’re developing and testing, you might want to receive onNetworkLogsAvailable() callbacks without having to browse hundreds of web pages. In Android 9.0 (API level 28) or higher, you can make a few sample network requests and force the system to send a logs-available callback. Run the following Android Debug Bridge (adb) command in your terminal:
adb shell dpm force-network-logs
The system limits how frequently you can use the tool and reports any intentional slowing in the terminal output. If there aren’t any logs to retrieve, your DPC doesn’t receive a callback.

Can a third-party app implement CallScreeningService in android 7?

Android API level 24 introduces a new Service called the CallScreeningService. The documentation says that the service can by implemented by the default dialer to screen incoming calls. I would like to implement this service in my own app, preferably without creating an entire dialer app, but a simple naive implementation seems to be ignored by the OS when an incoming call happens.
AndroidManifest.xml snippet:
<service android:name="com.example.callbouncer.CallService" android:permission="android.permission.BIND_SCREENING_SERVICE">
<intent-filter>
<action android:name="android.telecom.CallScreeningService"/>
</intent-filter>
</service>
CallService.java:
// imports...
public class CallService extends CallScreeningService {
#Override
public void onScreenCall(Call.Details callDetails) {
CallResponse.Builder response = new CallResponse.Builder();
Log.e("CallBouncer", "Call screening service triggered");
respondToCall(callDetails, response.build() );
}
}
There are no errors while building or installing this program, but the screening doesn't seem to be taking place. Have I done something wrong (like the manifest or missing implementations/overrides in the service) or is it just not possible? If it's not possible in a small app like this, will it be possible if I implement an entire dialing app and set it as the default dialer? Finally, if that's the case, is there anything preventing me from just forking the dialer out of the AOSP and adding my features to it?

As of Android 10 (API 29+), you can have a CallScreeningService without the requirement of also implementing an entire dialer app. Until Android 10, only the default dialer app's call CallScreeningService would be invoked.
https://developer.android.com/about/versions/10/features#call-screening
Don't get too excited though, because it's very buggy and does not work as the documentation says it does:
CallScreeningService#onScreenCall is called for known contacts
CallScreeningService#setSkipCallLog doesn't show blocked calls in the call log
My workaround for getting called for known contacts was to ask the user for contact access and check if the incoming caller was in the user's contacts. There is no workaround for the other issues at the moment.
I made a very basic screening app that declines all calls from numbers not in the user's contacts you can use an an example if you like: https://github.com/joshfriend/gofccyourself

Looking at the docs you linked to:
This service can be implemented by the default dialer (see
getDefaultDialerPackage()) to allow or disallow incoming calls before
they are shown to a user.
Don't think you can do this in a separate app (at least with the current interface: I'd expect in the not too distant feature it will be exposed).

"Too many Calendar deletes" error by Android calendar provider

I am using calendar provider to create and delete events.
The problem occurs in some devices when I try to remove events. Android OS shows a notification saying:
"Too many Calendar deletes"
with options to proceed.
I couldn't find an answer to fix it in Android, only read about calendar API limitation. But it's unacceptable to offer a feature to clientes with this notification.
I am running the following line to remove an event:
context.getContentResolver().delete(eventUri, null, null);
Thanks!

I'm afraid, there is no "correct" way to bypass this message and you also shouldn't even try. This is shown because the sync adapter has set the tooManyDeletions flag in the SyncResult object to true after trying to sync.
The sync manager will always show this message if the flag is set to true.
The number of allowed deletions is defined by the respective sync adapter or by the API it's syncing to. So if you see the message depends on the account type and maybe even on the version of the sync adapter.
This is a mechanism to protect the user's data from being deleted due to a mistake (either by himself or by broken software).
You could try to trick the SyncManager and the sync adapter by triggering a sync on the respective account with the SYNC_EXTRAS_OVERRIDE_TOO_MANY_DELETIONS flag being set by your code, but you really shouldn't do that. Actually I would consider this a bug in Android if it works.
You should communicate this to the user and sell it as a feature.
Update:
To trigger a sync with SYNC_EXTRAS_OVERRIDE_TOO_MANY_DELETIONS call this:
Bundle extras = new Bundle();
extras.putBoolean(ContentResolver.SYNC_EXTRAS_MANUAL, true);
extras.putBoolean(ContentResolver.SYNC_EXTRAS_OVERRIDE_TOO_MANY_DELETIONS, true);
ContentResolver.requestSync(accountOfCalendar, CalendarContract.Authority, extras);
accountOfCalendar is the account of the calendar that you deleted the events from.
Use it with care.

Register ContentProvider only if authority does not exist

I'm developing a custom home screen launcher. As part of its functionality I would like to be able to show unread notification badges.
Instead of implementing my own API for this, I would like to hook onto existing standards. The most widely used is the one for Samsung's TouchWiz launcher.
It works through a ContentProvider with the authority com.sec.badge. Now, on Samsung devices, I can easily use a ContentObserver to observe changes to Samsung's ContentProvider and it works perfectly. However, on devices without an existing ContentProvider (i.e. non-Samsung devices) I would like to provide my own ContentProvider for this purpose. This also works perfectly to capture inserts from other apps.
However, when I roll my own ContentProvider I naturally get an INSTALL_FAILED_CONFLICTING_PROVIDER error when trying to install on Samsung devices.
I fully understand why this is happening since Android wants to avoid having conflicts in the providers.
What I would want help with is a workaround. Is it possible to somehow register my ContentProvider dynamically instead of declaring it in AndroidManifest.xml? That way, I could first check if the authority is already taken, and if so go with an Observer. Otherwise, register my own ContentProvider and go with that.
I realize that this might be bad practice but I don't really see any other way. Some apps (such as Facebook) also implement Sony's badge API that works through Broadcasts which avoids conflict, but not nearly as many existing apps use this process.
I've tried this:
ContentProvider test = new SamsungContentProviderSpoof();
ProviderInfo providerInfo = new ProviderInfo();
providerInfo.authority = "com.sec.badge";
providerInfo.enabled = true;
providerInfo.exported = true;
test.attachInfo(this, providerInfo);
but that obviously fails. I guess I need to somehow access some system ContentResolver and register myself there, but I don't know how.

I would like to hook onto existing standards
There are no existing standards. A few vendors have done their own thing, and that's it.
The most widely used is the one for Samsung's TouchWiz launcher.
Note that this mechanism is undocumented (AFAICT) and unsupported (outside of select Samsung partners).
Is it possible to somehow register my ContentProvider dynamically instead of declaring it in AndroidManifest.xml? That way, I could first check if the authority is already taken, and if so go with an Observer. Otherwise, register my own ContentProvider and go with that.
You are welcome to say that it is disabled (android:enabled="false") in the manifest, then conditionally enable it later using PackageManager and setComponentEnabledSetting(). You would know that you needed to do this by either trying to communicate with the existing provider (e.g., registering your observer) and getting an expected error, or by interrogating PackageManager to see if the provider exists.
However, not only will you need to claim that you are Samsung in terms of the provider, but also in terms of the custom permissions. That will break on the "L" Developer Preview, and probably going forward, for much the same reason that you ran into with the conflicting provider. At the present time, there is no workaround for this that I am aware of.

Why does ContentResolver.requestSync not trigger a sync?

I am trying to implement the Content-Provider-Sync Adapter pattern as discussed at Google IO - slide 26. My content provider is working, and my sync works when I trigger it from the Dev Tools Sync Tester application, however when I call ContentResolver.requestSync(account, authority, bundle) from my ContentProvider, my sync is never triggered.
ContentResolver.requestSync(
account,
AUTHORITY,
new Bundle());
Edit -- added manifest snippet
My manifest xml contains:
<service
android:name=".sync.SyncService"
android:exported="true">
<intent-filter>
<action
android:name="android.content.SyncAdapter" />
</intent-filter>
<meta-data android:name="android.content.SyncAdapter"
android:resource="#xml/syncadapter" />
</service>
--Edit
My syncadapter.xml associated with my sync service contains:
<?xml version="1.0" encoding="utf-8"?>
<sync-adapter xmlns:android="http://schemas.android.com/apk/res/android"
android:contentAuthority="AUTHORITY"
android:accountType="myaccounttype"
android:supportsUploading="true"
/>
Not sure what other code would be useful. The account passed to requestSync is of "myaccounttype" and the AUTHORITY passed to the call matches my syc adapter xml.
Is ContentResolver.requestSync the correct way to request a sync? It looks like the sync tester tool binds directly to the service and calls start sync, but that seems like it defeats the purpose of integrating with the sync architecture.
If that is the correct way to request a sync then why would the sync tester work, but not my call to ContentResolver.requestSync? Is there something I need to pass in the bundle?
I am testing in the emulator on devices running 2.1 and 2.2.

Calling requestSync() will only work on an {Account, ContentAuthority} pair that is known to the system. Your app needs to go through a number of steps to tell Android that you are capable of synchronizing a specific kind of content using a specific kind of account. It does this in the AndroidManifest.
1. Notify Android that your application package provides syncing
First off, in AndroidManifest.xml, you have to declare that you have a Sync Service:
<service android:name=".sync.mySyncService" android:exported="true">
<intent-filter>
<action android:name="android.content.SyncAdapter" />
</intent-filter>
<meta-data
android:name="android.content.SyncAdapter"
android:resource="#xml/sync_myapp" />
</service>
The name attribute of the <service> tag is the name of your class to connect up sync... I'll talk to that in a second.
Setting exported true makes it visible to other components (needed so ContentResolver can call it).
The intent filter lets it catch an intent requesting sync. (This Intent comes from ContentResolver when you call ContentResolver.requestSync() or related scheduling methods.)
The <meta-data> tag will be discussed below.
2. Provide Android a service used to find your SyncAdapter
So the class itself... Here's an example:
public class mySyncService extends Service {
private static mySyncAdapter mSyncAdapter = null;
public SyncService() {
super();
}
#Override
public void onCreate() {
super.onCreate();
if (mSyncAdapter == null) {
mSyncAdapter = new mySyncAdapter(getApplicationContext(), true);
}
}
#Override
public IBinder onBind(Intent arg0) {
return mSyncAdapter.getSyncAdapterBinder();
}
}
Your class must extend Service or one of its subclasses, must implement public IBinder onBind(Intent), and must return a SyncAdapterBinder when that's called... You need a variable of type AbstractThreadedSyncAdapter. So as you can see, that's pretty much everything in that class. The only reason it's there is to provide a Service, that offers a standard interface for Android to query your class as to what your SyncAdapter itself is.
3. Provide a class SyncAdapter to actually perform the sync.
mySyncAdapter is where the real sync logic itself is stored. Its onPerformSync() method gets called when it's time to sync. I figure you already have this in place.
4. Establish a binding between an Account-type and a Content Authority
Looking back again at AndroidManifest, that strange <meta-data> tag in our service is the key piece that establishes the binding between a ContentAuthority and an account. It externally references another xml file (call it whatever you like, something relevant to your app.) Let's look at sync_myapp.xml:
<?xml version="1.0" encoding="utf-8" ?>
<sync-adapter
xmlns:android="http://schemas.android.com/apk/res/android"
android:contentAuthority="com.android.contacts"
android:accountType="com.google"
android:userVisible="true" />
Okay, so what does this do? It tells Android that the sync adapter we've defined (the class that was called out in the name element of the <service> tag that includes the <meta-data> tag that references this file...) will sync contacts using a com.google style account.
All your contentAuthority strings have to all match, and match with what you're syncing -- This should be a string you define, if you're creating your own database, or you should use some existing device strings if you're syncing known data types (like contacts or calendar events or what have you.) The above ("com.android.contacts") happens to be the ContentAuthority string for contacts type data (surprise, surprise.)
accountType also has to match one of those known account types that are already entered, or it has to match one you're creating (This involves creating a subclass of AccountAuthenticator to get auth on your server... Worth an article, itself.) Again, "com.google" is the defined string identifying... google.com style account credentials (again, this should not be a surprise.)
5. Enable Sync on a given Account / ContentAuthority pair
Finally, sync has to be enabled. You can do this in the Accounts & Sync page in the control panel by going to your app and setting the checkbox next to your app within the matching account. Alternately, you can do it in some setup code in your app:
ContentResolver.setSyncAutomatically(account, AUTHORITY, true);
For sync to occur, your account/authority pair must be enabled to sync (like above) and the overall global sync flag on the system must be set, and the device must have network connectivity.
If your account/authority sync or the global sync are disabled, calling RequestSync() does have an effect -- It sets a flag that sync has been requested, and will be performed as soon as sync is enabled.
Also, per mgv, setting ContentResolver.SYNC_EXTRAS_MANUAL to true in the extras bundle of your requestSync will ask android to force a sync even if global sync is off (be respectful of your user here!)
Finally, you can setup a periodic scheduled sync, again with ContentResolver functions.
6. Consider implications of multiple accounts
It is possible to have more than one account of the same type (two #gmail.com accounts set up on one device or two facebook accounts, or two twitter accounts, etc...) You should consider the application implications of doing that... If you have two accounts, you probably don't want to try to sync both of them into the same database tables. Maybe you need to specify that only one can be active at a time, and flush the tables and resync if you switch accounts. (through a property page that queries what accounts are present). Maybe you create a different database for each account, maybe different tables, maybe a key column in each table. All application specific and worthy of some thought. ContentResolver.setIsSyncable(Account account, String authority, int syncable) might be of interest here. setSyncAutomatically() controls whether an account/authority pair is checked or unchecked, whereas setIsSyncable() provides a way to uncheck and grey out the line so the user can't turn it on. You might set one account Syncable and the other not Syncable (dsabled).
7. Be aware of ContentResolver.notifyChange()
One tricky thing. ContentResolver.notifyChange() is a function used by ContentProviders to notify Android that the local database has been changed. This serves two functions, first, it will cause cursors following that content uri to update, and in turn requery and invalidate and redraw a ListView, etc... It's very magical, the database changes and your ListView just updates automatically. Awesome. Also, when the database changes, Android will request Sync for you, even outside your normal schedule, so that those changes get taken off the device and synced to the server as rapidly as possible. Also awesome.
There's one edge case though. If you pull from the server, and push an update into the ContentProvider, it will dutifully call notifyChange() and android will go, "Oh, database changes, better put them on the server!" (Doh!) Well-written ContentProviders will have some tests to see if the changes came from the network or from the user, and will set the boolean syncToNetwork flag false if so, to prevent this wasteful double-sync. If you're feeding data into a ContentProvider, it behooves you to figure out how to get this working -- Otherwise you'll end up always performing two syncs when only one is needed.
8. Feel happy!
Once you have all this xml metadata in place, and sync enabled, Android will know how to connect everything up for you, and sync should start working. At this point, a lot of things that are nice will just click into place and it will feel a lot like magic. Enjoy!

I was caling setIsSyncable after AccountManager setAuthToken method. But setAuthToken returned function before setIsSyncable was reached. After order changes everything worked fine!

I noticed the that the requestSync will trigger the sync implementation when there is internet connection