PackageManager$NameNotFoundException no query permission

[Falcosc]

Sometimes, Android losses access to your package names. Maybe because we lose the reason why it is visible automatically in some use cases https://developer.android.com/training/package-visibility/automatic
If it happens, createLocusVersion will fail with PackageManager$NameNotFoundException
And getAvailableVersions will return nothing because all packages run into the ignored NameNotFoundException catch.

Do we need to define all packages in the manifest like this https://developer.android.com/training/package-visibility/declaring? I ask it because your example doesn't do it.

Or do you need to define the queries in your API like in this https://developer.android.com/training/package-visibility/declaring#communicate-host-app library use case?
I don't know if your API structure applies to this concept or if it isn't a library use case.

Unfortunately we don't know how to trigger the issue Falcosc/locus-addon-tasker#38 We only know that a reboot is needed to restore access.

I guess the error will be fixed with adding the query permissions, and that's why I ask how we should add it. Either every app or on library level.

[Falcosc]

After we have fixed the sample, could you re-upload the new one in google? It is not visible for recent devices anymore.
Falcosc/locus-addon-tasker#37 (comment)

[menion]

Hello Falco,
it is an interesting problem. I was quite sure, it is already covered by this record. All Locus apps can handle "Geo" intent, so this should really work.

Are you able to simulate this problem? If so, you may try to add to your manifest following 'queries'.

    <queries>
        <package android:name="menion.android.locus" />
        <package android:name="menion.android.locus.pro" />
    </queries>

[Falcosc]

I can not reproduce it. It happens only once a month or so. And even worse, nobody notice it since it happens only in my SelectVersion context.

So I now have compared the sometimes broken call with the known working call.
And there is a difference, I use different Context

here is the stack which does not tell anything

android.content.pm.PackageManager$NameNotFoundException: menion.android.locus
	at android.app.ApplicationPackageManager.getPackageInfoAsUser(ApplicationPackageManager.java:302)
	at android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:262)
	at android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:256)
	at locus.api.android.utils.LocusUtils.createLocusVersion(LocusUtils.kt:187)
	at falcosc.locus.addon.tasker.intent.handler.AbstractTaskerAction.handle(AbstractTaskerAction.java:42)
	at falcosc.locus.addon.tasker.intent.handler.SelectVersionRequest.handle(SelectVersionRequest.java:15)
	at falcosc.locus.addon.tasker.intent.receiver.TaskerActionFireReceiver.onReceive(TaskerActionFireReceiver.java:40)
	at android.app.ActivityThread.handleReceiver(ActivityThread.java:4894)
	at android.app.ActivityThread.-$$Nest$mhandleReceiver(Unknown Source:0)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2420)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loopOnce(Looper.java:226)
	at android.os.Looper.loop(Looper.java:313)
	at android.app.ActivityThread.main(ActivityThread.java:8762)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:604)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

This is the context source of the function without complaints:
It uses TaskerActionFireReceiver Broadcastreceiver and calls context.getApplicationContext()

public class TaskerActionFireReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(@NonNull Context context, @NonNull Intent intent) {
       call handlercode(context), inside handlerCode: LocusCache getInstanceUnsafe(context)
    }
}

public final class LocusCache {
    public static LocusCache getInstanceUnsafe(@NonNull Context context) throws MissingAppContextException {
        if (mInstance == null) {
            Context appContext = context.getApplicationContext();
            if (appContext instanceof Application) {
                return getInstance((Application) appContext);
            } else {
                throw new MissingAppContextException();
            }
        }
        return mInstance;
    }

    private LocusCache(Application context) {
        mLocusVersion = LocusUtils.INSTANCE.getActiveVersion(context, VersionCode.UPDATE_01);
        ...
    }
}

but the following sometimes does not work:
no call of getApplicationContext(), it just uses the TaskerActionFireReceiver Context directly

public class TaskerActionFireReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(@NonNull Context context, @NonNull Intent intent) {
       call handlercode(context), inside handlerCode: LocusUtils.INSTANCE.createLocusVersion(context, packageName)
    }
}

Keep in mind, this could be a false positive - maybe context.getApplicationContext() is failing as well and I just never got a complaint about it because it happens so rarely.
But on the other hand I don't know how Context works, if there is a difference in query between Tasker Intent sourced activity/receiver Contexts and my global application contexts - then this would explain it more likely.

However, most of the TaskerActionFireReceiver.onReceive(context):context work flawless, only one of many does not see any locus package
And TaskerActionFireReceiver.onReceive(context):context.getApplicationContext() seems to work allways

[Falcosc]

Found a 2nd context which never works if you hit a usecase where package was hidden. Phone Reboot is needed to fix it. So only after phonereboot TaskerActionFireReceiver.onReceive(context):context and SelectVersion.onCreate().this works again.
Both context sources get broken sometimes and stay broken on repeated requests until you reboot the phone. Which feels like a firemware bug.

This is the 2nd broken function context, it uses AppCompatActivity directly as context. It is my own activity but was started in Tasker. So not a broadcastReceiver but an Activity directly startet in Tasker

@Override
public class SelectVersion extends AppCompatActivity {
  public void onCreate(@Nullable Bundle savedInstanceState) {
    LocusUtils.INSTANCE.getAvailableVersions(this)
  }
}

getAvailableVersions does not crash, but return an empty list if all packages are hidden.

So it does not matter if it is activity or receiver, both direct usages of context variables sometimes fail but no fail report from context.getApplicationContext()

        <activity
            android:name=".intent.edit.SelectVersion"
            android:exported="true">
            <intent-filter>
                <action android:name="com.twofortyfouram.locale.intent.action.EDIT_SETTING" />
            </intent-filter>
        </activity>


        <!-- listen tasker action fire -->
        <receiver
            android:name=".intent.receiver.TaskerActionFireReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="com.twofortyfouram.locale.intent.action.FIRE_SETTING" />
            </intent-filter>
        </receiver>

Based on the getApplicationContext() documentation I would say it makes no difference to use context vs context.getApplicationContext() because it only documents differences in lifecycle

[Falcosc]

add to your manifest following 'queries'.

    <queries>
        <package android:name="menion.android.locus" />
        <package android:name="menion.android.locus.pro" />
    </queries>

This version is now in test since 4 days Falcosc/locus-addon-tasker@804efe5
But I keep using the activity/receiver context on the only broken place in my application to test if query definitions solve it or not.
We either get the error again and test switching to getApplicationContext or the error never appears again in the next 30 days and queries was one possible fix, then we would repeat the test with getApplicationContext and no query permission to identify if we could just fix it by requiring type Application instead of Context in the creation version functions