VPN ਉੱਤੇ ਨਿਰਭਰ ਹੋਣ ਤੋਂ ਬਿਨਾਂ Android ਐਪਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਟੈਕਸਟ ਬਲੌਕ ਕਰੋ

Android ਵਿੱਚ ਸਪਸ਼ਟ ਟੈਕਸਟ ਬਲੌਕ ਕਰਨਾ ਦੋ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਐਪ ਦੇ ਅੰਦਰ ਦੀ ਨੀਤੀ ਹੈ ਜੋ ਆਪਣੇ ਹੀ ਨੈੱਟਵਰਕਿੰਗ ਸਟੈਕ ਨੂੰ ਸਾਧਾਰਨ HTTP ਮਨ੍ਹਾ ਕਰਨ ਦਾ ਹੁਕਮ ਦਿੰਦੀ ਹੈ। ਦੂਜੀ ਡਿਵਾਈਸ-ਪੱਧਰ ਦੀ ਵਿਵਸਥਾ ਹੈ ਜੋ ਫ਼ੋਨ ਉੱਤੇ ਸਭ ਕੁਝ ਇਕੱਠਾ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ VPN ਰਾਹੀਂ ਭੇਜ ਕੇ। ਇਹ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਦੂਜੀ ਪਹਿਲੀ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ: ਟਨਲ ਫ਼ੋਨ ਅਤੇ ਨਿਕਾਸ ਵਿਚਕਾਰਲੇ ਹਿੱਸੇ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ, ਜਦਕਿ HTTP ਬੋਲਣ ਵਾਲੀ ਐਪ ਉਸ ਨਿਕਾਸ ਤੋਂ ਪਾਰ ਜੋ ਵੀ ਹੈ ਉਸ ਨਾਲ ਅਜੇ ਵੀ HTTP ਹੀ ਬੋਲਦੀ ਹੈ।

ਇੱਕ ਨਾਮ ਹੇਠ ਦੋ ਸਮੱਸਿਆਵਾਂ

ਪਹਿਲੀ ਸਮੱਸਿਆ ਪੇਲੋਡ ਹੈ: ਐਪ ਪਹਿਚਾਣ ਪੱਤਰ ਜਾਂ ਟੋਕਨ ਅਜਿਹੀ ਬੇਨਤੀ ਵਿੱਚ ਲਿਖਦੀ ਹੈ ਜੋ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਹਰ ਉਹ ਹੌਪ ਜੋ ਇਸ ਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ, ਪੜ੍ਹ ਵੀ ਸਕਦਾ ਹੈ। ਦੂਜੀ ਮਾਰਗ ਹੈ: ਐਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹੀ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਫਿਰ ਵੀ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸਥਾਨਕ Wi-Fi ਆਪਰੇਟਰ ਨੂੰ ਇਸ ਬਾਰੇ ਕੁਝ ਪਤਾ ਨਾ ਲੱਗੇ ਕਿ ਇਹ ਕਿੱਥੇ ਜੁੜਦੀ ਹੈ। VPN ਦੂਜੀ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਦੂਜੀ ਨੂੰ।

ਇਹ ਫ਼ਰਕ ਹੀ ਠੀਕ ਕਰਨ ਦਾ ਮਾਲਕ ਤੈਅ ਕਰਦਾ ਹੈ। ਪੇਲੋਡ ਉਸ ਦਾ ਹੈ ਜੋ ਐਪ ਪਹੁੰਚਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਉਹੀ ਕੋਡ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ URL ਕਾਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਮਾਰਗ ਡਿਵਾਈਸ ਜਾਂ ਨੈੱਟਵਰਕ ਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਪੈਕੇਟ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ, ਇਹ ਨਹੀਂ ਕਿ ਉਹਨਾਂ ਵਿੱਚ ਕੀ ਹੈ।

ਪਹਿਲਾ ਮਾਰਗ: ਉਹ ਐਪ ਜੋ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ

ਜੇ ਤੁਸੀਂ ਐਪ ਪਹੁੰਚਾਉਂਦੇ ਹੋ, ਤਾਂ ਠੀਕ ਕਰਨਾ ਇੱਕ ਟ੍ਰਾਂਸਪੋਰਟ ਫ਼ੈਸਲਾ ਅਤੇ ਉਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਹੈ। ਹਰ ਐਂਡਪੌਇੰਟ ਨੂੰ HTTPS ਵੱਲ ਮੋੜੋ, ਹੋਸਟਨਾਮ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਚਾਲੂ ਰੱਖੋ, ਅਤੇ ਸਾਧਾਰਨ HTTP ਦੇ ਬੈਕਅੱਪ ਨੂੰ ਇੱਕ ਕਨਫਿਗਰੇਸ਼ਨ ਫਲੈਗ ਦੂਰ ਰੱਖਣ ਦੀ ਥਾਂ ਹਟਾ ਦਿਓ। ਰੀਡਾਇਰੈਕਟ ਇੱਥੇ ਮਦਦ ਨਹੀਂ ਕਰਦਾ: 301 ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ HTTP ਬੇਨਤੀ ਆਪਣੇ ਹੈਡਰ ਅਤੇ ਬਾਡੀ ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹੇ ਵਿੱਚ ਭੇਜ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਪਹਿਚਾਣ ਪੱਤਰ ਕਦੇ ਵੀ ਇਸ ਧਾਰਨਾ ਉੱਤੇ ਨਹੀਂ ਚੱਲਣੇ ਚਾਹੀਦੇ ਕਿ ਰੀਡਾਇਰੈਕਟ ਉਹਨਾਂ ਦੀ ਰੱਖਿਆ ਕਰੇਗਾ।

Android 7.0 ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ Network Security Configuration ਨੀਤੀ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਫ਼ਾਈਲ ਸਭ ਤੋਂ ਛੋਟਾ ਲਾਭਦਾਇਕ ਸੰਸਕਰਣ ਹੈ: ਇਹ ਹਰ ਥਾਂ ਸਪਸ਼ਟ ਟੈਕਸਟ ਮਨ੍ਹਾ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਕੋਈ ਡੋਮੇਨ-ਖਾਸ ਛੋਟ ਕੁਝ ਹੋਰ ਨਾ ਕਹੇ।

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

ਮੈਨਿਫੈਸਟ ਤੋਂ ਉਸ ਸਰੋਤ ਦਾ ਹਵਾਲਾ ਦਿਓ, ਫਿਰ ਪਹੁੰਚਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਛੋਟਾਂ ਪੜ੍ਹੋ। ਕੋਈ ਪੁਰਾਣਾ ਡੀਬੱਗ ਡੋਮੇਨ ਜਾਂ ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਦੀ SDK ਐਂਟਰੀ ਉਸ ਹੋਸਟ ਲਈ ਚੁੱਪਚਾਪ ਦੁਬਾਰਾ ਸਪਸ਼ਟ ਟੈਕਸਟ ਦੀ ਆਗਿਆ ਦੇ ਸਕਦੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ।

ਸੰਸਕਰਣ ਦੀਆਂ ਦੋ ਗੱਲਾਂ ਜਾਣਨ ਯੋਗ ਹਨ। API 28 ਜਾਂ ਨਵੇਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀਆਂ ਐਪਾਂ ਪਹਿਲਾਂ ਹੀ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਸਪਸ਼ਟ ਟੈਕਸਟ ਮਨ੍ਹਾ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਜੋ ਐਪ ਅਜੇ ਵੀ ਸਾਧਾਰਨ HTTP ਬੋਲਦੀ ਹੈ ਉਹ ਜਾਂ ਤਾਂ ਪੁਰਾਣੇ API ਪੱਧਰ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ ਜਾਂ ਕਿਤੇ ਛੋਟ ਰੱਖਦੀ ਹੈ। ਅਤੇ ਜਦੋਂ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਕਨਫਿਗ ਮੌਜੂਦ ਹੋਵੇ, ਪੁਰਾਣਾ android:usesCleartextTraffic ਮੈਨਿਫੈਸਟ ਗੁਣ ਹੁਣ ਇਹ ਸਵਾਲ ਤੈਅ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਉਸ ਫਲੈਗ ਨੂੰ ਬਦਲਣ ਨਾਲ ਕਈ ਵਾਰ ਕੁਝ ਨਾ ਹੋਣਾ ਜਿਹਾ ਲੱਗਦਾ ਹੈ।

ਦੂਜਾ ਮਾਰਗ: ਉਹ ਐਪ ਜੋ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ

ਸਥਾਪਿਤ ਤੀਜੀ-ਧਿਰ ਦੀ ਐਪ ਲਈ ਤੁਸੀਂ ਵਰਤੋਂਕਾਰ ਸੈਟਿੰਗ ਰਾਹੀਂ ਉਸ ਦੀ ਸੁਰੱਖਿਆ ਕਨਫਿਗਰੇਸ਼ਨ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖ ਸਕਦੇ। ਵਾਸਤਵਿਕ ਵਿਕਲਪ ਹਨ ਉਤਪਾਦ ਦੇ ਆਪਣੇ ਸੁਰੱਖਿਅਤ-ਕਨੈਕਸ਼ਨ ਨਿਯੰਤਰਣ, ਪਹਿਲਾਂ ਹੀ TLS ਵਰਤਦਾ ਇੱਕ ਸੰਭਾਲਿਆ ਵਿਕਲਪ, ਜਾਂ ਪ੍ਰਬੰਧਿਤ-ਡਿਵਾਈਸ ਨੀਤੀ ਜੋ ਸੀਮਿਤ ਕਰਦੀ ਹੈ ਕਿ ਡਿਵਾਈਸ ਕੀ ਚਲਾ ਸਕਦਾ ਹੈ। ਇਹ ਵੱਖਰੀਆਂ ਵਚਨਬੱਧਤਾਵਾਂ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਤੀਜੀ ਹੀ ਡਿਵਾਈਸ ਸਮੂਹ ਤੱਕ ਫੈਲਦੀ ਹੈ।

ਨੈੱਟਵਰਕ ਨਿਯਮ ਦਿਖਣ ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਬਦਲ ਹਨ। ਸਿਰਫ਼ ਪੋਰਟ 443 ਦੀ ਆਗਿਆ ਪ੍ਰਮਾਣਿਤ TLS ਲਾਗੂ ਨਹੀਂ ਕਰਦੀ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਸਪਸ਼ਟ-ਟੈਕਸਟ ਪ੍ਰੋਟੋਕਾਲ ਉਸ ਪੋਰਟ ਉੱਤੇ ਭੇਜੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਪੋਰਟ 80 ਬਲੌਕ ਕਰਨਾ ਹੋਰ ਪੋਰਟਾਂ ਦੇ ਸਪਸ਼ਟ ਟੈਕਸਟ ਨੂੰ ਨਹੀਂ ਢਕਦਾ। ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਸਿਰਫ਼-HTTPS ਮੋਡ ਵੀ ਉਸੇ ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਸੀਮਿਤ ਹੈ, ਉਸੇ ਫ਼ੋਨ ਦੀ ਵੱਖਰੀ ਮੇਲ ਜਾਂ ਚੈਟ ਐਪ ਤੱਕ ਨਹੀਂ।

ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਐਨਕ੍ਰਿਪਟਿਡ ਦਿਖਾਉਣ ਲਈ ਇੰਟਰਸੈਪਸ਼ਨ ਸਰਟੀਫਿਕੇਟ ਸਥਾਪਿਤ ਕਰਨਾ ਭਰੋਸੇ ਦੀ ਤਬਦੀਲੀ ਹੈ, ਠੀਕ ਕਰਨਾ ਨਹੀਂ। ਇਹ ਐਪ ਦੀ ਸਰਵਰ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਤੁਹਾਡੇ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਜੋ ਐਪ ਸ਼ੁਰੂ ਤੋਂ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦੀ ਸੀ ਉਹ ਇਸ ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ; ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਬਦਲਿਆ ਹੈ ਕਿ ਸਟ੍ਰੀਮ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

VPN ਕਿੱਥੇ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ

ਟਨਲ ਸਹੀ ਸਾਧਨ ਹੈ ਜਦੋਂ ਲੋੜ ਇਹ ਹੋਵੇ ਕਿ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਨੂੰ ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਕੁਝ ਪਤਾ ਨਾ ਲੱਗੇ, ਜਾਂ ਐਪ ਉਸ ਨਿੱਜੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚੇ ਜਿੱਥੇ ਉਹ ਹੋਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ। HTTP ਕਲਾਇੰਟ ਨੂੰ HTTPS ਬੁਲਵਾਉਣ ਲਈ ਇਹ ਗ਼ਲਤ ਸਾਧਨ ਹੈ, ਕਿਉਂਕਿ ਬੇਨਤੀ ਟਨਲ ਵਿੱਚੋਂ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਨਿਕਲਦੀ ਹੈ ਜਿਵੇਂ ਉਹ ਵੜੀ ਸੀ।

Android ਇੱਕ ਵਿਹਾਰਕ ਰੁਕਾਵਟ ਜੋੜਦਾ ਹੈ: ਪਲੇਟਫ਼ਾਰਮ ਇੱਕ ਸਮੇਂ ਇੱਕੋ VPN ਸੇਵਾ ਚਲਾਉਂਦਾ ਹੈ. ਉਹ ਥਾਂ ਲੈਣ ਵਾਲੀ ਸਥਾਨਕ ਫਿਲਟਰਿੰਗ ਐਪ ਉਸ ਦੂਰਲੀ ਟਨਲ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦੀ ਹੈ, ਅਤੇ ਦੋਹਾਂ ਵਿਚਕਾਰ ਬਦਲਣਾ ਐਪ-ਪੱਧਰ ਦੀ ਨਹੀਂ, ਡਿਵਾਈਸ-ਪੱਧਰ ਦੀ ਕਾਰਵਾਈ ਹੈ। ਉਹ ਇੱਕੋ ਥਾਂ ਪੇਲੋਡ ਨੀਤੀ ਨੂੰ ਐਪ ਵਿੱਚ ਰੱਖਣ ਅਤੇ ਟਨਲ ਨੂੰ ਮਾਰਗ ਲਈ ਰੱਖਣ ਦਾ ਚੰਗਾ ਕਾਰਨ ਹੈ।

ਦੋਵੇਂ ਇੱਕਠੇ ਹੋਣ ਦਾ ਇੱਕੋ ਇੱਕ ਮਾਮਲਾ ਤੁਹਾਡਾ ਆਪਣਾ ਚਲਾਇਆ ਨਿੱਜੀ ਸਰਵਰ ਹੈ। ਉੱਥੇ ਪ੍ਰੋਟੋਕਾਲ ਅਜੇ ਵੀ ਸਪਸ਼ਟ ਟੈਕਸਟ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਟਨਲ ਮਾਰਗ ਨੂੰ ਨਿੱਜੀ ਬਣਾ ਸਕਦੀ ਹੈ, ਜੋ ਖੁੱਲ੍ਹ ਘਟਾਉਂਦੀ ਹੈ ਪਰ ਇਹ ਨਹੀਂ ਬਦਲਦੀ ਕਿ ਪੇਲੋਡ ਕੀ ਹੈ। ਇਸ ਨੂੰ ਜੋਖਮ ਘਟਾਉਣਾ ਸਮਝੋ, ਡੇਟਾ ਦਾ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ।

ਬਲੌਕ ਕਿਹਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਟੈਸਟ ਕਰੀਏ

ਉਸ ਡਿਫ਼ਾਲਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ: API 28 ਜਾਂ ਨਵੇਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀ ਐਪ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਪਸ਼ਟ ਟੈਕਸਟ ਮਨ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਡਿਫ਼ਾਲਟ ਦੀ ਨਕਲ ਕਰਨ ਵਾਲੀ ਕਨਫਿਗਰੇਸ਼ਨ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਸ਼ਾਨਾ ਪੱਧਰ ਦੇਖੋ। ਫਿਰ ਅਸਫ਼ਲਤਾ ਦਾ ਮਾਮਲਾ ਜਾਣਬੁੱਝ ਕੇ ਟੈਸਟ ਕਰੋ: ਸਾਧਾਰਨ HTTP ਹੋਸਟ ਉੱਤੇ ਬੇਨਤੀ ਬੈਕਅੱਪ ਰਾਹੀਂ ਚੁੱਪਚਾਪ ਸਫਲ ਹੋਣ ਦੀ ਥਾਂ ਅਸਫਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

ਸਫਲਤਾ ਦੇ ਮਾਮਲੇ ਲਈ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ HTTPS ਕਾਲ ਅਸਲ ਸਰਟੀਫਿਕੇਟ ਲੜੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ ਅਤੇ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੇ ਸਰਟੀਫਿਕੇਟ ਵਾਲਾ ਪ੍ਰੌਕਸੀ ਸਹਿਣ ਦੀ ਥਾਂ ਅਸਵੀਕਾਰ ਹੁੰਦਾ ਹੈ। ਜੋ ਹੈਂਡਸ਼ੇਕ ਕਿਸੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਸਫਲ ਹੋਵੇ ਉਹ ਟ੍ਰਾਂਸਪੋਰਟ ਸੁਰੱਖਿਆ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ਤੀਜੀ-ਧਿਰ ਦੀ ਐਪ ਲਈ ਉਹ ਸੀਮਾ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਭਾਵੇਂ ਉਹ ਪ੍ਰਬੰਧਿਤ-ਡਿਵਾਈਸ ਨੀਤੀ ਹੋਵੇ, ਨੈੱਟਵਰਕ ਨਿਯਮ ਹੋਵੇ ਜਾਂ ਕੁਝ ਨਾ ਹੋਵੇ, ਅਤੇ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡਾਂ ਵਿੱਚ ਇਹ ਕਹੋ। Android ਸੁਰੱਖਿਆ ਕਨਫਿਗਰੇਸ਼ਨ ਗਾਈਡ ਪਲੇਟਫ਼ਾਰਮ ਦੇ ਡਿਫ਼ਾਲਟ ਅਤੇ ਇਹ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਕਨਫਿਗਰੇਸ਼ਨ ਬਿਲਕੁਲ ਕੁਝ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹੀ ਹਿੱਸਾ ਤੈਅ ਕਰਦਾ ਹੈ।