Android में SystemUI कैसे काम करता है

इस लेख में, मैं मुख्य एंड्रॉइड एप्लिकेशन - SystemUI के संचालन के वास्तुकला और सिद्धांत का विश्लेषण करूंगा। मुझे इस विषय में दिलचस्पी थी, क्योंकि मुझे आश्चर्य है कि सिस्टम कैसे काम करता है, जो इतनी बड़ी संख्या में उपयोगकर्ताओं द्वारा उपयोग किया जाता है और जिसके लिए हर दिन या इंटरनेट पर बस Google Play पर हजारों एप्लिकेशन डाउनलोड किए जाते हैं। इसके अलावा, मुझे एंड्रॉइड की सूचना सुरक्षा और इसके लिए बनाए गए एप्लिकेशन के मुद्दे में दिलचस्पी है।

Android पर, SystemUI एक ऐसा अनुप्रयोग है जिसका स्रोत कोड पथ platform_frameworks_base / package / SystemUI / में है , डिवाइस पर यह सिस्टम / निजी-ऐप / -SystemUI में है।

निजी-ऐप वह निर्देशिका है जहां विशेषाधिकार प्राप्त एप्लिकेशन संग्रहीत हैं। वैसे, सिस्टम / ऐप पथ पर पहले से इंस्टॉल किए गए एप्लिकेशन हैं, और साधारण एप्लिकेशन जो हम अपने डिवाइस पर इंस्टॉल करते हैं, वे डेटा या ऐप में संग्रहीत होते हैं।

यह तुरंत प्रश्न उठाता है: सभी पूर्वस्थापित और विशेषाधिकार प्राप्त अनुप्रयोगों को एक निर्देशिका में क्यों नहीं धकेला जा सकता, यह अलगाव क्यों आवश्यक है?

तथ्य यह है कि कुछ एप्लिकेशन दूसरों की तुलना में अधिक प्रणालीगत हैं :) और यह अलगाव आवश्यक है ताकि सिस्टम अनुप्रयोगों के शोषण कवरेज को कम किया जा सके ताकि सुरक्षित संचालन तक पहुंच बनाई जा सके। आप एक एप्लिकेशन बना सकते हैं जिसमें एक विशेष ApplicationInfo.FLAG_SYSTEM होगा और सिस्टम में अधिक अधिकार प्राप्त करेगा, हालांकि, इस अनुमति के साथ एक एपीके फाइल सिस्टम सेक्शन में रखी जाएगी।

तो, SystemUI एक एपीके फाइल है, जो अनिवार्य रूप से एक सामान्य एप्लिकेशन है। हालाँकि, यदि आप जटिल SystemUI डिवाइस को देखते हैं, तो यह प्रतीत होता है कि यह सिर्फ एक साधारण अनुप्रयोग है, है ना?

यह एप्लिकेशन बहुत महत्वपूर्ण कार्य करता है:

• नेविगेशन
• हाल के अनुप्रयोग
• त्वरित सेटिंग्स
• अधिसूचना बार
• लॉक स्क्रीन
• मात्रा पर नियंत्रण
• होम स्क्रीन
• ...

SystemUI लॉन्च करें

जैसा कि मैंने ऊपर कहा, सिस्टमयूआई एक नियमित अनुप्रयोग की तरह नहीं है, इसलिए इसका लॉन्च गतिविधि के लॉन्च के साथ नहीं है, जैसा कि अधिकांश अनुप्रयोगों के लिए होता है। SystemUI एक वैश्विक उपयोगकर्ता इंटरफ़ेस है जो सिस्टम बूट प्रक्रिया के दौरान शुरू होता है और पूरा नहीं किया जा सकता है।

<application android:name=".SystemUIApplication" android:persistent="true" android:allowClearUserData="false" android:allowBackup="false" android:hardwareAccelerated="true" android:label="@string/app_label" android:icon="@drawable/icon" android:process="com.android.systemui" android:supportsRtl="true" android:theme="@style/Theme.SystemUI" android:defaultToDeviceProtectedStorage="true" android:directBootAware="true" android:appComponentFactory="androidx.core.app.CoreComponentFactory"> 

यदि हम SystemServer में आते हैं, जो एंड्रॉइड की दुनिया के दो स्तंभों में से एक है (दूसरा Zygote है, लेकिन मैं इसके बारे में कुछ और समय पर बात करूंगा), तो हम उस जगह को पा सकते हैं जहां SystemUI शुरू होता है जब सिस्टम बूट होता है।

  static final void startSystemUi(Context context, WindowManagerService windowManager) { Intent intent = new Intent(); intent.setComponent(new ComponentName("com.android.systemui", "com.android.systemui.SystemUIService")); intent.addFlags(Intent.FLAG_DEBUG_TRIAGED_MISSING); //Slog.d(TAG, "Starting service: " + intent); context.startServiceAsUser(intent, UserHandle.SYSTEM); windowManager.onSystemUiStarted(); } 

यहां हम देखते हैं कि कैसे SystemUI सेवा गैर-सार्वजनिक API startServiceAsUser का उपयोग करना शुरू करती है। यदि आप इसका उपयोग करना चाहते हैं, तो आपको प्रतिबिंब का सहारा लेना होगा। लेकिन अगर आप एंड्रॉइड में प्रतिबिंब एपीआई का उपयोग करने का निर्णय लेते हैं, तो इसके लायक होने पर कुछ बार सोचें। सौ बार सोचो :)

इसलिए, यहां हम आवेदन के लिए एक अलग प्रक्रिया बनाते हैं और वास्तव में, सिस्टमयूआई का प्रत्येक खंड एक अलग सेवा या एक स्वतंत्र मॉड्यूल है।

 public abstract class SystemUI implements SysUiServiceProvider { public Context mContext; public Map<Class<?>, Object> mComponents; public abstract void start(); protected void onConfigurationChanged(Configuration newConfig) { } public void dump(FileDescriptor fd, PrintWriter pw, String[] args) { } protected void onBootCompleted() { } @SuppressWarnings("unchecked") public <T> T getComponent(Class<T> interfaceType) { return (T) (mComponents != null ? mComponents.get(interfaceType) : null); } public <T, C extends T> void putComponent(Class<T> interfaceType, C component) { if (mComponents != null) { mComponents.put(interfaceType, component); } } public static void overrideNotificationAppName(Context context, Notification.Builder n, boolean system) { final Bundle extras = new Bundle(); String appName = system ? context.getString(com.android.internal.R.string.notification_app_name_system) : context.getString(com.android.internal.R.string.notification_app_name_settings); extras.putString(Notification.EXTRA_SUBSTITUTE_APP_NAME, appName); n.addExtras(extras); } } 

प्रत्येक सेवा को शुरू करने के लिए स्टार्ट () विधि को कहा जाता है, जो नीचे सूचीबद्ध हैं।

 <string-array name="config_systemUIServiceComponents" translatable="false"> <item>com.android.systemui.Dependency</item> <item>com.android.systemui.util.NotificationChannels</item> <item>com.android.systemui.statusbar.CommandQueue$CommandQueueStart</item> <item>com.android.systemui.keyguard.KeyguardViewMediator</item> <item>com.android.systemui.recents.Recents</item> <item>com.android.systemui.volume.VolumeUI</item> <item>com.android.systemui.stackdivider.Divider</item> <item>com.android.systemui.SystemBars</item> <item>com.android.systemui.usb.StorageNotification</item> <item>com.android.systemui.power.PowerUI</item> <item>com.android.systemui.media.RingtonePlayer</item> <item>com.android.systemui.keyboard.KeyboardUI</item> <item>com.android.systemui.pip.PipUI</item> <item>com.android.systemui.shortcut.ShortcutKeyDispatcher</item> <item>@string/config_systemUIVendorServiceComponent</item> <item>com.android.systemui.util.leak.GarbageMonitor$Service</item> <item>com.android.systemui.LatencyTester</item> <item>com.android.systemui.globalactions.GlobalActionsComponent</item> <item>com.android.systemui.ScreenDecorations</item> <item>com.android.systemui.fingerprint.FingerprintDialogImpl</item> <item>com.android.systemui.SliceBroadcastRelayHandler</item> </string-array> 

मात्रा पर नियंत्रण

हम नियमित रूप से अपने उपकरणों पर वॉल्यूम बटन का उपयोग करते हैं, लेकिन हम इस बारे में नहीं सोचते हैं कि सिस्टम में क्या प्रक्रियाएं होनी चाहिए ताकि हम ध्वनि को बढ़ा या कम कर सकें। ऑपरेशन शब्दों में काफी सरल लगता है, लेकिन अगर आप वॉल्यूम यूआई को देखते हैं, जो सिस्टेनयूआई / वॉल्यूम के सबफ़ोल्डर में स्थित है, तो इंटरफ़ेस की अलग-अलग मोड में अपनी भिन्नता है।


मैंने पहले ही कहा है कि SystemUI सेवाएं स्टार्ट () विधि द्वारा शुरू की जाती हैं। यदि हम वॉल्यूमयूआई वर्ग को देखते हैं , तो यह सिस्टमयूआई से भी प्राप्त होता है।

 public class VolumeUI extends SystemUI { private static final String TAG = "VolumeUI"; private static boolean LOGD = Log.isLoggable(TAG, Log.DEBUG); private final Handler mHandler = new Handler(); private boolean mEnabled; private VolumeDialogComponent mVolumeComponent; @Override public void start() { boolean enableVolumeUi = mContext.getResources().getBoolean(R.bool.enable_volume_ui); boolean enableSafetyWarning = mContext.getResources().getBoolean(R.bool.enable_safety_warning); mEnabled = enableVolumeUi || enableSafetyWarning; if (!mEnabled) return; mVolumeComponent = new VolumeDialogComponent(this, mContext, null); mVolumeComponent.setEnableDialogs(enableVolumeUi, enableSafetyWarning); putComponent(VolumeComponent.class, getVolumeComponent()); setDefaultVolumeController(); } … 

यहां हम देखते हैं कि mEnabled के साथ हम यह निर्धारित करते हैं कि हमें ध्वनि सेटिंग वाला पैनल दिखाना है या नहीं। और VolumeDialogComponent द्वारा देखते हुए, VolumeUI साउंडबार को एक संवाद के रूप में प्रदर्शित करता है। लेकिन वॉल्यूम कुंजियों को दबाने के संबंध में सभी क्रियाएं फोनविंडो में संसाधित की जाती हैं ।

  protected boolean onKeyDown(int featureId, int keyCode, KeyEvent event) { ... switch (keyCode) { case KeyEvent.KEYCODE_VOLUME_UP: case KeyEvent.KEYCODE_VOLUME_DOWN: case KeyEvent.KEYCODE_VOLUME_MUTE: { // If we have a session send it the volume command, otherwise // use the suggested stream. if (mMediaController != null) { mMediaController.dispatchVolumeButtonEventAsSystemService(event); } else { getMediaSessionManager().dispatchVolumeKeyEventAsSystemService(event, mVolumeControlStreamType); } return true; } ... protected boolean onKeyUp(int featureId, int keyCode, KeyEvent event) { final KeyEvent.DispatcherState dispatcher = mDecor != null ? mDecor.getKeyDispatcherState() : null; if (dispatcher != null) { dispatcher.handleUpEvent(event); } //Log.i(TAG, "Key up: repeat=" + event.getRepeatCount() // + " flags=0x" + Integer.toHexString(event.getFlags())); switch (keyCode) { case KeyEvent.KEYCODE_VOLUME_UP: case KeyEvent.KEYCODE_VOLUME_DOWN: { // If we have a session send it the volume command, otherwise // use the suggested stream. if (mMediaController != null) { mMediaController.dispatchVolumeButtonEventAsSystemService(event); } else { getMediaSessionManager().dispatchVolumeKeyEventAsSystemService( event, mVolumeControlStreamType); } return true; } … 

जहाँ तक हम देख सकते हैं, KEYCODE_VOLUME_UP (+) संसाधित नहीं है और KEYCODE_VOLUME_DOWN (-) प्रसंस्करण में जाएगा। दोनों घटनाओं में, onKeyDown और onKeyUp दोनों पर, डिस्पैचवॉल्मबूटनएवेंटएवेंटसिस्टम्स सर्विस विधि कहा जाता है।

  public void dispatchVolumeButtonEventAsSystemService(@NonNull KeyEvent keyEvent) { switch (keyEvent.getAction()) { case KeyEvent.ACTION_DOWN: { int direction = 0; switch (keyEvent.getKeyCode()) { case KeyEvent.KEYCODE_VOLUME_UP: direction = AudioManager.ADJUST_RAISE; break; ... mSessionBinder.adjustVolume(mContext.getPackageName(), mCbStub, true, direction, ... } 

इसलिए, यहां हम एडजस्टवोल्यूम विधि कहते हैं, ताकि हम अपनी दिशा की जांच कर सकें कि कौन सा इवेंट पैरामीटर सौंपा जाएगा।

परिणामस्वरूप, जब हम AudioService में पहुंचते हैं , जहां sendVolumeUpdate को कॉल किया जाएगा, जहां पोस्टवॉल्यूमचेंज विधि को कॉल करने के अलावा, एचडीएमआई इंटरफ़ेस स्थापित किया जाएगा।

  // UI update and Broadcast Intent protected void sendVolumeUpdate(int streamType, int oldIndex, int index, int flags) { ... mVolumeController.postVolumeChanged(streamType, flags); } private int updateFlagsForSystemAudio(int flags) { ... if (mHdmiSystemAudioSupported && ((flags & AudioManager.FLAG_HDMI_SYSTEM_AUDIO_VOLUME) == 0)) { flags &= ~AudioManager.FLAG_SHOW_UI; } ... } return flags; } public void postVolumeChanged(int streamType, int flags) { ... mController.volumeChanged(streamType, flags); ... } 

RingtonePlayer

Android में RingtonePlayer एक खिलाड़ी के रूप में कार्य करता है। यह SystemUI से भी आरंभ होता है और प्रारंभ () विधि में हम देखते हैं:

  @Override public void start() { ... mAudioService.setRingtonePlayer(mCallback); ... } 

यहां हम mCallback स्थापित करते हैं, जो अनिवार्य रूप से IRingtonePlayer का एक उदाहरण है।

 private IRingtonePlayer mCallback = new IRingtonePlayer.Stub() { @Override public void play(IBinder token, Uri uri, AudioAttributes aa, float volume, boolean looping) throws RemoteException { ... } @Override public void stop(IBinder token) { ... } @Override public boolean isPlaying(IBinder token) { ... } @Override public void setPlaybackProperties(IBinder token, float volume, boolean looping) { ... } @Override public void playAsync(Uri uri, UserHandle user, boolean looping, AudioAttributes aa) { ... } @Override public void stopAsync() { ... } @Override public String getTitle(Uri uri) { ... } @Override public ParcelFileDescriptor openRingtone(Uri uri) { ... } }; 

अंत में, आप ध्वनि फ़ाइलों को चलाने के लिए Binder का उपयोग करके RingtonePlayerService को नियंत्रित कर सकते हैं।

PowerUI

पावर प्रबंधन और सूचनाओं के लिए पावरयूआई जिम्मेदार है। यह इसी तरह SystemUI से विरासत में मिला है और इसमें एक स्टार्ट () विधि है।

 public void start() { mPowerManager = (PowerManager) mContext.getSystemService(Context.POWER_SERVICE); mHardwarePropertiesManager = (HardwarePropertiesManager) mContext.getSystemService(Context.HARDWARE_PROPERTIES_SERVICE); mScreenOffTime = mPowerManager.isScreenOn() ? -1 : SystemClock.elapsedRealtime(); mWarnings = Dependency.get(WarningsUI.class); mEnhancedEstimates = Dependency.get(EnhancedEstimates.class); mLastConfiguration.setTo(mContext.getResources().getConfiguration()); ContentObserver obs = new ContentObserver(mHandler) { @Override public void onChange(boolean selfChange) { updateBatteryWarningLevels(); } }; final ContentResolver resolver = mContext.getContentResolver(); resolver.registerContentObserver(Settings.Global.getUriFor( Settings.Global.LOW_POWER_MODE_TRIGGER_LEVEL), false, obs, UserHandle.USER_ALL); updateBatteryWarningLevels(); mReceiver.init(); showThermalShutdownDialog(); initTemperatureWarning(); } 

जैसा कि हम उपरोक्त कोड से देख सकते हैं, Settings.Global.LOW_POWER_MODE_TRIGGER_LEVEL परिवर्तन सब्सक्राइब किए गए हैं, और फिर mReceiver.init () कहा जाता है।

  public void init() { // Register for Intent broadcasts for... IntentFilter filter = new IntentFilter(); filter.addAction(PowerManager.ACTION_POWER_SAVE_MODE_CHANGED); filter.addAction(Intent.ACTION_BATTERY_CHANGED); filter.addAction(Intent.ACTION_SCREEN_OFF); filter.addAction(Intent.ACTION_SCREEN_ON); filter.addAction(Intent.ACTION_USER_SWITCHED); mContext.registerReceiver(this, filter, null, mHandler); } 

यहां प्रसारण रिसीवर पंजीकृत है, जिसकी मदद से परिवर्तन ट्रैकिंग की जाती है।

कार्य

Recents Android मोबाइल उपकरणों में एक प्राथमिक और अक्सर उपयोग की जाने वाली सुविधा है।

मुख्य कार्य:

• सभी कार्य प्रदर्शित करें
• कार्यों के बीच स्विच करें
• कार्य हटाना

इसके अलावा, Recents भी SystemUI से विरासत में मिला है। RecentsActivity नवीनतम कार्यों को बनाता है और अपडेट करता है ताकि हम उन्हें अपनी स्क्रीन पर देख सकें।


और हाल ही के इनटैस्कफो का उपयोग करके हम एक विशिष्ट कार्य के बारे में जानकारी प्राप्त कर सकते हैं।

 public static class RecentTaskInfo implements Parcelable { public int id; public int persistentId; public Intent baseIntent; public ComponentName origActivity; public ComponentName realActivity; public CharSequence description; public int stackId; ... 

सामान्य तौर पर, रनिंग कार्यों को एक अलग विषय में रखा जा सकता है। मैंने सभी पक्षों से इसका अध्ययन किया, क्योंकि मैं एप्लिकेशन को पृष्ठभूमि पर स्विच करने से पहले एप्लिकेशन स्क्रीन को धुंधला करना चाहता था, ताकि स्नैपशॉट का एक अपठनीय संस्करण RecentsTask में प्रदर्शित हो। हालाँकि, समस्या यह है कि आवेदन स्नैपशॉट onPause () कहा जाता है से पहले लिया जाता है। इस समस्या को कई तरीकों से हल किया जा सकता है। या झंडा सेट करें ताकि सिस्टम केवल स्क्रीन की सामग्री को छिपाए

 getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE); 

मैंने पिछले लेख में सिर्फ स्नैपशॉट के बारे में बात की थी।

आप आम तौर पर यह सुनिश्चित कर सकते हैं कि आवेदन की विशिष्ट गतिविधि प्रकट में नीचे रखकर कार्यों में प्रकट नहीं होती है

 android:excludeFromRecents = "true" 

या आप के साथ चाल का उपयोग कर सकते हैं

 Intent.FLAG_ACTIVITY_MULTIPLE_TASK 

आप ध्वज के ऊपर मुख्य गतिविधि को सेट कर सकते हैं बाहर करें = सच , ताकि इसकी स्क्रीन चल रहे कार्यों में न हो, लेकिन जब एप्लिकेशन लोड होता है, तो एक अलग कार्य चलाएं जो मुख्य गतिविधि से या तो धुंधली स्क्रीनशॉट, या किसी अन्य छवि को दिखाएगा। अधिक विस्तार से, यह कैसे किया जा सकता है यह Google डिस्क के उदाहरण पर आधिकारिक दस्तावेज में वर्णित है।

लॉक स्क्रीन

उपरोक्त सभी मॉड्यूल की तुलना में कीगार्ड पहले से अधिक जटिल है। यह एक ऐसी सेवा है जो SystemUI में चलती है, और KeyguardViewMediator का उपयोग करके प्रबंधित की जाती है।

 private void setupLocked() { ... // Assume keyguard is showing (unless it's disabled) until we know for sure, unless Keyguard // is disabled. if (mContext.getResources().getBoolean( com.android.keyguard.R.bool.config_enableKeyguardService)) { setShowingLocked(!shouldWaitForProvisioning() && !mLockPatternUtils.isLockScreenDisabled( KeyguardUpdateMonitor.getCurrentUser()), mAodShowing, mSecondaryDisplayShowing, true /* forceCallbacks */); } else { // The system's keyguard is disabled or missing. setShowingLocked(false, mAodShowing, mSecondaryDisplayShowing, true); } ... mLockSounds = new SoundPool(1, AudioManager.STREAM_SYSTEM, 0); String soundPath = Settings.Global.getString(cr, Settings.Global.LOCK_SOUND); if (soundPath != null) { mLockSoundId = mLockSounds.load(soundPath, 1); } ... int lockSoundDefaultAttenuation = mContext.getResources().getInteger( com.android.internal.R.integer.config_lockSoundVolumeDb); mLockSoundVolume = (float)Math.pow(10, (float)lockSoundDefaultAttenuation/20); ... } 

हालांकि, वास्तव में, KeyguardService लॉक स्क्रीन इंटरफेस के साथ स्वतंत्र रूप से काम नहीं करता है, यह केवल स्टेटसबार मॉड्यूल को जानकारी स्थानांतरित करता है, जहां स्क्रीन के दृश्य स्वरूप और सूचना के प्रदर्शन के बारे में पहले से ही कार्रवाई की जाती है।

अधिसूचना बार

SystemBars में एक जटिल उपकरण और संरचना होती है। उनका काम दो चरणों में विभाजित है:

1. सिस्टमबार्स की शुरुआत
2. सूचनाएँ प्रदर्शित करें

अगर आप SystemBars के लॉन्च को देखें

 private void createStatusBarFromConfig() { ... final String clsName = mContext.getString(R.string.config_statusBarComponent); ... cls = mContext.getClassLoader().loadClass(clsName); ... mStatusBar = (SystemUI) cls.newInstance(); ... } 

फिर हम उस संसाधन का लिंक देखते हैं जिसमें से कक्षा का नाम पढ़ा जाता है और एक उदाहरण बनाया जाता है।

 <string name="config_statusBarComponent" translatable="false">com.android.systemui.statusbar.phone.StatusBar</string> 

इस प्रकार, हम देखते हैं कि एक StatusBar यहाँ कहा जाता है, जो सूचना और UI आउटपुट के साथ काम करेगा।

मुझे लगता है कि किसी को संदेह नहीं था कि एंड्रॉइड बहुत जटिल है और इसमें बहुत सारे ट्रिक्स हैं जो कोड की एक बड़ी संख्या में वर्णित हैं। SystemUI इस प्रणाली के सबसे महत्वपूर्ण भागों में से एक है और मुझे इसके बारे में जानने में बहुत मज़ा आया। इस तथ्य के कारण कि इस विषय पर बहुत कम सामग्री है, यदि आपको कोई त्रुटि दिखाई देती है, तो कृपया मुझे सुधारें।

PS मैं हमेशा टेलीग्राम में @paradisecurity पर सामग्री और छोटे लेखों के चयन को उजागर करता हूं।