Diciamo che ho un'app white label che sto convertendo per essere costruita in Android Studio da Eclipse. Questa app ha circa 10 iterazioni che utilizzano tutte la stessa base di codice con risorse diverse che utilizzano tutte la stessa convenzione di nome, in quanto alcune di queste iterazioni hanno attività o servizi aggiuntivi che non sono necessari in tutte le build.È possibile utilizzare più file manifest per differenti build/sapori di gradle?
Voglio eliminare l'intero lotto di vecchi database per mantenere le basi di codice che sono essenzialmente le stesse e utilizzare solo un progetto di Android Studio. Capisco la base di questo set up con tutti i file sorgenti e file res ma sono bloccato su come gestire i diversi file manifest.
È possibile utilizzare aromi o buildtype per gestire il passaggio di più file manifest?
Ah ah pensavo di poterlo fare, ma quella documentazione è stata abbastanza evidente una volta che ho iniziato a leggerlo (sì, è piuttosto confuso a prima vista). Quindi, come dovrei strutturare il mio progetto se ho una base di dati java ma più basi di risorse e file manifest? –
@Jamesandresakis: "Quindi, come dovrei strutturare il mio progetto se ho una base di dati java ma più basi di risorse e file manifest?" - beh, dal momento che sembra che tu stia cercando di avere le diverse risorse/manifest per differenti build di produzione (cioè, le varianti spedibili dalla base "white label"), gli aromi del prodotto sarebbero il veicolo principale. La maggior parte del tuo codice Java va in 'src/main /', insieme a un set di base di risorse e un manifest. Esegue l'override su tali risorse e manifest andrà in sorgenti di fonti specifiche per l'aroma (ad esempio, 'src/whiteLabelShippableVariant1 /'). – CommonsWare