एंड्रॉयड - Whitelabel एप्लिकेशन

Question

नोट: यह एक पुरानी सवाल है, और तदनुसार वर्ष upvoted जवाब प्रासंगिक नहीं हो सकता है - बिल्ड प्रकार (यानी अनुप्रयोग फ्लेवर्स) के बारे में नए जवाब देख।

मेरे पास बाजार में प्रकाशन के बारे में एक प्रश्न है।

कंपनी, एक्स, कंपनियों के लिए समान सेवाएं प्रदान करता है & बी, और दोनों & बी बाजार में एक ऐप चाहते हैं। कंपनी एक्स सिर्फ एक ऐप लिखना चाहता है और उचित लोगो, कॉन्फ़िगरेशन सेटिंग्स, संकलन समय पर भाषा तारों का उपयोग करके उनके बीच अंतर करना चाहता है। हालांकि, जब प्रकाशन की बात आती है, तो ऐप्स में एक ही ऐप पैकेज नाम होता है (साझा कोड आधार का उपयोग करके)। ऐप बनाए रखा जाएगा और

तो, यह देखते हुए कि मैं एक कोड आधार रखना चाहता हूं, यहां सबसे अच्छा अभ्यास क्या है?

Answer 1

इस ब्लॉग पोस्ट को देखें, blog.javia.org/android-package-name/।

[संपादित करें] यदि यह लिंक मर जाता है तो जानकारी के नुकसान से बचने के लिए: यह एप्लिकेशन पैकेज परिभाषा और जावा पैकेज परिभाषा के अंतर के बारे में एक पोस्ट है। स्रोतों के जावा पैकेज को छूए बिना एप्लिकेशन पैकेज (मैनिफेस्ट के अंदर) को बदलना संभव है। [/ संपादित करें]

Answer 2

जहां तक ​​मुझे पता है कि आपके पास उसी पैकेज नाम के साथ बाजार पर दो ऐप्स नहीं हो सकते हैं। साझा कोड, लेआउट, ड्रॉबल्स इत्यादि की कॉपी-पेस्ट से बचने के लिए, मैं इन संसाधनों को लाइब्रेरी प्रोजेक्ट में रखने की सलाह दूंगा और फिर इस प्रोजेक्ट को ऐप ए और बी से संदर्भित करता हूं जिसका उल्लेख आप करते हैं और इन ऐप्स में केवल उन मानों को ओवरराइड करते हैं जिन्हें आप बदलना चाहते हैं ।

the official documentation में लाइब्रेरी परियोजनाओं के बारे में अधिक जानकारी।

Answer 3

जोहान का जवाब सही है। मेरी कंपनी में, हमने अभी एक छोटी सी लिपि बनाई है जो न केवल नए संसाधनों को लागू करने, बल्कि एक कस्टम पैकेज नाम बनाने और उपयुक्त एक्सएमएल फाइलों को पैच करके, 'बेस' एप्लिकेशन से एप्लिकेशन के 'ब्रांड' बनाता है।

Answer 4

मैं रेफ्लॉग के साथ सहमत हूं, मेरी कंपनी ने प्रत्येक ब्रांड के लिए पैकेज नाम बदलने के लिए एक एंटी स्क्रिप्ट का उपयोग किया है, और आवश्यकतानुसार संसाधनों को प्रतिस्थापित करने के लिए भी। मैंने मूल ऐप को डिफ़ॉल्ट व्यवहार के साथ लिखा है, और प्रत्येक अतिरिक्त ब्रांड के लिए फ़ोल्डरों को बनाया है जिसमें केवल उन फ़ाइलों को शामिल किया गया है जो बेस से अलग थे, जैसे कि विभिन्न डीपीआई आकारों ("ड्रॉइंग", "ड्रॉइंग-एचडीपीआई" के साथ कई ड्रॉइंग फ़ोल्डरों की तरह। ..)। अन्य परिवर्तनों में उचित रंग और कानूनी पाठ के लिए प्रत्येक ब्रांड के लिए स्ट्रिंग फ़ाइलों को संशोधित करना शामिल था।

स्थानीयकरण शैली में उन्हें नाम देकर (उदाहरण के लिए "ड्रॉरेबल-एन-आरएए-एचडीपीआई", "लेआउट-एन-आरबीबी" ...), मैं इसे कई अनुकरणकर्ताओं में जल्दी से परीक्षण करने में सक्षम था " कस्टम लोकेल "प्रत्येक एमुलेटर में ऐप, और लोकेल को" en_AA "," en_BB "को आवश्यकतानुसार सेट करना। आधार एवीडी की कई प्रतियों को सहेजकर, मैं उन सेटिंग्स को सहेजने में सक्षम था इसलिए मुझे सभी अंतिम ब्रांडों का परीक्षण करने के लिए एमुलेटर के भीतर स्विच करने की आवश्यकता नहीं थी।

इस दृष्टिकोण के लिए एक चेतावनी है कि ऐप के इस नकली संस्करण में .apk में सभी फ़ाइलें शामिल होंगी, जबकि चींटी स्क्रिप्ट डुप्लीकेट को बाहर निकाल देती है। साथ ही, यह "पूर्ण" .apk डिवाइस पर स्थापित होगा, यह केवल डिफ़ॉल्ट व्यवहार दिखाएगा जबतक कि आप ब्रांड लोकेल से मेल खाने के लिए डिवाइस पर लोकेल सेट नहीं कर सकते। (कस्टम लोकेल मेरे किसी भी भौतिक उपकरणों पर स्थापित नहीं था।) यदि आप जानबूझकर मौजूदा नामित लोकेशंस (en_AU, en_CA, en_GB) का उपयोग करते हैं, तो यह अच्छी तरह से काम करता है, लेकिन कस्टम नामों (en_B1, en_XX) के लिए समस्याग्रस्त हो सकता है।

Answer 5

मैं जानता हूँ कि मैं पार्टी के लिए एक छोटे से देर हो रही है, लेकिन आप ऐसा कर सकते हैं:

1) लाइन manifestmerger.enabled=true

2 जोड़कर अपने project.properties बदले) में अपने पैकेज का नाम बदलें मैनिफेस्ट।

3) अपने संसाधनों, drawables, तारों, जो कुछ भी अद्यतन/बदलें।

4) अपनी मास्टर प्रोजेक्ट को लाइब्रेरी के रूप में चिह्नित करें और इसके लिए अपने श्वेत-लेबल प्रोजेक्ट में निर्भरता सेट करें। वोला, सफेद लेबल!

Answer 6

यह एक बहुत पुराना सवाल है। हालांकि अब मुझे लगता है कि नए ग्रेडल बिल्ड सिस्टम का उपयोग करके एंड्रॉइड के लिए Product Flavours का सबसे अच्छा तरीका उपयोग करना होगा।

• प्रत्येक स्वाद के लिए आप applicationId परिभाषित कर सकते हैं। packageName और applicationId के बीच एक अंतर है। एप्लिकेशन आईडी विशिष्ट रूप से डिवाइस पर और Google Play Store में आपके ऐप की पहचान करता है। उत्तरार्द्ध कोड नामस्थान के लिए है। आप यहां और अधिक पढ़ सकते हैं: https://developer.android.com/studio/build/application-id.html
• प्रत्येक स्वाद के लिए, स्वाद के लिए विशिष्ट फ़ोल्डर का उपयोग करके आप एक अलग ड्रॉबल्स, स्ट्रिंग्स, अन्य एक्सएमएल फ़ाइल प्राप्त कर सकते हैं। आपको केवल उन संपत्तियों को नई फाइलों में रखना होगा, जो main फ़ोल्डर में संपत्तियों से अलग हैं। फिर buildConfigField है आप build.gradle में प्रत्येक स्वाद के लिए परिभाषित कर सकते हैं जिसे जावा फाइलों से प्रत्येक श्वेतसूची के लिए आपकी कॉन्फ़िगरेशन के रूप में एक्सेस किया जा सकता है।
• इसके अलावा आप वहां से प्रत्येक स्वाद के लिए resValue परिभाषित कर सकते हैं।
• आप manifestPlaceholders का उपयोग कर AndroidManifest.xml कुंजी के लिए कॉन्फ़िगर करने योग्य आदि भी बना सकते हैं।

Answer 7

आपको बिल्ड वेरिएंट (ए.के.ए. ऐप फ्लेवर्स) की आवश्यकता है।

आप यहाँ https://developer.android.com/studio/build/build-variants.html

संक्षेप में यह पर पढ़ सकते हैं, यह आपको लगता है कि साझा कोड और संसाधनों का हिस्सा अपने ऐप के विभिन्न प्रकार हैं, लेकिन साथ ही अपने स्वयं के प्रतिस्थापन हो सकता है की अनुमति देता है। आप प्रत्येक संस्करण के लिए अलग-अलग पैकेज नाम/आईडी निर्दिष्ट कर सकते हैं, अन्य चीजों के साथ (जैसे लोगो, रंग, स्प्लैश स्क्रीन और यहां तक ​​कि जावा कोड)।

defaultConfig { 
    applicationId "com.example.example" 
    minSdkVersion 16 
    targetSdkVersion 25 
    versionCode 1 
    versionName "1.0.0" 
} 

productFlavors { 
    variantone { 
      applicationId 'com.company1.example' 
    } 
    varianttwo { 
      applicationId 'com.company2.example' 
    } 
} 

आप उन प्रकारों के नाम से संसाधन फ़ोल्डर्स बना सकते हैं जहां आप अपना वैकल्पिक संसाधन या स्रोत कोड डाल सकते हैं। उदाहरण के लिए, src/variantone/res

एंड्रॉइड स्टूडियो में बिल्ड वेरिएंट के बीच स्विचिंग के परिणामस्वरूप फ़ाइल में परिवर्तन नहीं होता है (आप केवल "आउटपुट" चुनते हैं)। आप एक ही समय में सभी प्रकार के संस्करणों के लिए एपीके बना सकते हैं। बिल्ड/जनरेट किए गए एपीके जेनरेट में विज़ार्ड का उपयोग करें।

पीएस यहां बताया गया है कि डीबग बिल्ड के लिए आपके पास एक अलग पैकेज नाम कैसे हो सकता है:

buildTypes { 
    release { 
    } 
    debug { 
     applicationIdSuffix '.debug' 
     versionNameSuffix '.debug' 
    } 
}