Hi, Mark.

hello, Randall!

how can I help you today?

I have more of an Android Studio question, than Android specifically...is that OK?

sure

I'm working on a parallel branch of development whilst the client is performing testing and validation. I need to be able to deliver a build of both branches, as needed. And I don't want to blow away data from either installation when the other is installed. I figured out how to change the bundle ID pretty easily based on a "flavor", but there doesn't seem to be a way to change the display app name. Or am I missing how to do this?

I'm not sure what a "bundle ID" is -- do you mean applicationId?

Yes, sorry. (That's my iOS leaking through.)

and by "display app name", you mean like the caption under the icon in the home screen launcher?

In Project Structure > Flavors, it was simple to change the appID,but not the app name. Yes, exactly.

in your AndroidManifest.xml file, your <activity> that has the MAIN/LAUNCHER <intent-filter> will be getting its label from either an android:label attribute on the <activity> element, or inheriting from the android:label attribute on the <application> element

what value do you have for that android:label attribute? is it a fixed string, or a reference to a string resource (e.g., @string/app_name)?

I have "android:label="@string/app_name"" in both the application and activity.

great!

if you want to change that value in a product flavor, simply redefine that string resource in that flavor

so, in addition to src/main/res/values/strings.xml having an app_name, you would have src/yourflavorname/res/values/strings.xml with its own app_name

(for a flavor cunningly named yourflavorname)

when you build yourflavorname, you'll get that flavor's version of app_name, and that will be what shows up on the home screen launcher icon

That might be part of the problem...I migrated this project from an ant-based IntelliJ project. Do I need to modify the folder structure to support that?

ah

This is the first stuff that's flavor-specific so far.

well, your alternative approach is to try defining it in build.gradle itself

hold on a moment while I quick look up the syntax for that

OK

right now, in your build.gradle file, you should have a productFlavors {} closure

Check.

in there would be closures for your flavors

in there is where you are overriding the applicationId

Yep.

phooey

let me try that again

sigh

let me type that into another editor and paste it here -- hold on...

right?

Yep.

OK

inside that same foo {} closure, you can have a resValue statement

now, I haven't tried this for having a flavor override a string resource (unless I'm forgetting having tried it -- it's been a long day...)

but it's worth a shot

as it means you won't have to fuss around with your project file structure

Sweet. I will try it.

that being said, eventually shifting over into the standard Android Studio directory structure is probably a good idea

at least for some value of "eventually"

That's really what I'm trying to avoid...I'm still merging changes between branches, and I think do that will just cause me no end of headaches.

yeah, it's not likely to be a picnic

Yeah, once FDA testing is over and I'm full-time on the new work, I'll try to do that.

Hmmm...looks like I might have to remove that entry from the strings.xml file...

you're getting a complaint about a conflict?

Error:Error: Duplicate resources: ...res/values/strings.xml:string/app_name

yeah, that's what I was afraid of

you should be able to define it purely in build.gradle and remove it from the strings.xml file

There's nothing wrong with removing it from the resource file, eh? Besides being "non-standard"?

not that I'm aware of, though I've never tried it

either have one resValue for every flavor, or put one resValue in defaultConfig and override it in flavors as needed

DING DING DING! We have a winner!

Thanks!

BTW, I'm the guy that asked you a while back about locking down a "kiosk" mode, pre-Lollipop. I got everything working as desired, nearly 100%. The only crack is the Recent Apps list; despite flagging it to not appear there, it does, ever so briefly, allowing the user a small windows to swipe to quit. But other than that...Back button, Home button, power key, status bar...locked down tight.

to a large extent, I'm actually sorry to hear that

heh

while your use case is fine, there are lots of other less-fine use cases for that sort of stuff

I agree that for a "normal" app, yeah, that would be annoying/irritating as an end user.

as I told somebody on Stack Overflow recently, just because you are a saint does not mean that all malware developers are magically becoming saints

Yeah.

Are you very familiar with making custom Android distros? That's probably the root my client *should* take, but I have no idea the scope of that.

I have never created one

They're actually talking about making the app available via the Play store, which I think would be bad.

whoever is advising your firm on FDA approval probably ought to weigh in on public distribution like that

IOW, is it FDA-approved if users install it, vs. getting the app pre-installed on hardware?

BTW, are you going to be happen to be a the BABBQ conference in TX in Oct?

no, sorry, I'm not attending the BBQ

back to distros

Yeah, I don't know how the FDA requirements fit into an end-user installation.

for low-level, how to bring up a custom Android build on hardware, try Karim Yaghmour's _Embedded Android_

I was hoping that by now, we'd have more turnkey services for custom ROMs, but that hasn't come to pass

drivers tend to be the big sticking point

I imagine.

Thanks for the tip.

Thanks again for your help. Have a great day!

you are very welcome