Hey there! Let’s dive into your questions and address your core requirements, since you’ve already tried several common (now deprecated or limited) approaches.

1. Is there a cross-platform method to get the current foreground app/package? #

Short answer: No, there’s no universal method that works across all operating systems and devices. Each platform has strict privacy and security restrictions that block cross-app visibility by default. Here’s the breakdown per major OS:

• Android:
  • The old GET_TASKS permission is long deprecated, and UsageStatsManager requires users to manually grant access to "Usage Data Access" in system settings.
  • Device Owner mode can grant more access, but as you noted, it can’t be set programmatically—users have to go through a manual setup process (like NFC provisioning) which isn’t feasible for consumer apps.
  • Knox SDK is limited to Samsung devices only, so it’s not a universal solution.
• iOS/iPadOS:
  • Apple’s sandbox model strictly blocks apps from accessing information about other running apps. Even with permissions, you can’t directly get the foreground app’s package name. The only official way is via the Screen Time/Family Controls API, which lets you restrict app usage but doesn’t expose raw foreground app data.
• Windows:
  • You can use Win32 APIs like GetForegroundWindow() combined with GetWindowThreadProcessId() to get the foreground process name, but this requires appropriate permissions (and may be restricted in modern Windows versions for UWP apps).
• macOS:
  • NSWorkspace provides notifications like NSWorkspaceDidActivateApplicationNotification to detect foreground app changes, but this is limited to macOS-specific apps and requires user approval for accessibility permissions in some cases.

2. How does AppLock work (detecting app launches)? #

AppLock-style apps rely on platform-specific mechanisms, since there’s no cross-platform standard. Here’s how they work on the two main mobile platforms:

Android #

The most reliable modern method uses AccessibilityService:

• Apps request users to enable accessibility permissions (a system-level setting). Once enabled, the service can listen to system-wide window events.
• When a new window is created (indicating an app launch) or the foreground window changes, the service checks the app’s package name against its blacklist.
• If a blacklisted app is detected, the AppLock launches its own lock screen Activity and brings it to the foreground, intercepting the user’s access to the blocked app.
• Some older apps used UsageStatsManager with periodic polling, but this is less real-time than AccessibilityService.

iOS #

Non-jailbroken iOS apps have limited options, so most AppLock tools use:

• Screen Time API (Family Controls Framework): This official Apple API lets apps act as a "screen time manager." Users grant permission to the app, which can then set app usage restrictions. When a blocked app is opened, the system shows a restriction screen (which can be customized to an extent by the managing app).
• Jailbroken apps can use hooks (via tools like Cydia Substrate) to listen to SpringBoard events that signal app launches, but this only works on jailbroken devices and violates Apple’s terms of service.

Solutions for Your Core Requirements #

Since you need a programmable, free, and device-agnostic solution (as much as possible), here’s what to implement per platform:

Android (Most Flexible) #

Implement an AccessibilityService—this is the only viable, programmable method that works across most devices (excluding some heavily customized skins, but it’s the closest to universal):

1. Create a subclass of AccessibilityService and override onAccessibilityEvent:

   @Override
   public void onAccessibilityEvent(AccessibilityEvent event) {
       if (event.getEventType() == AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) {
           String packageName = event.getPackageName().toString();
           // Check if packageName is in your blacklist
           if (isBlacklisted(packageName)) {
               // Launch your lock screen Activity
               Intent intent = new Intent(this, LockScreenActivity.class);
               intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
               startActivity(intent);
           }
       }
   }
   

2. Declare the service in your AndroidManifest.xml with the required permissions:

   <service
       android:name=".MyAccessibilityService"
       android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
       <intent-filter>
           <action android:name="android.accessibilityservice.AccessibilityService" />
       </intent-filter>
       <meta-data
           android:name="android.accessibilityservice"
           android:resource="@xml/accessibility_service_config" />
   </service>
   

3. Create an accessibility config XML file to specify the events you want to listen to.
4. On first launch, guide users to enable the accessibility service via system settings (you can open the settings page with Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS)).

iOS #

Use the Family Controls Framework (part of Screen Time):

1. Request authorization from the user to manage screen time.
2. Define a set of allowed apps (your whitelist) and block all others.
3. When a blocked app is opened, the system will show a restriction screen—you can customize this experience by providing your own UI within the framework’s limits.
   Note: This requires users to go through a setup process to grant your app screen time management permissions, but it’s the only official, non-jailbroken way to achieve this.

Windows/macOS #

• Windows: Use Win32 APIs to poll for the foreground process, or register for window change events. When a blacklisted app is detected, launch your lock window and set it as foreground with SetForegroundWindow().
• macOS: Use NSWorkspace to listen for app activation notifications. When a blocked app is activated, bring your lock window to the front using NSApplication.shared.activate(ignoringOtherApps: true).

Important note: There’s no 100% universal solution across all OSes and devices—each platform has its own security barriers, so you’ll need to build platform-specific implementations. All legitimate methods require user consent (permissions), as modern OSes prioritize user privacy and security.

内容的提问来源于stack exchange，提问作者Dhruv Patel