One sample includes all

[hannesa2]

With one main sample app and include all others as modules it's easier to maintain, see what's included and verify on CI

[thatfiredev]

@hannesa2 I particularly prefer the way they are right now (separate modules), this way developers can build each module separately, since sometimes they're only interested in trying out only one of the apps.

On a side note, I think it would be cool if you listed on the PR description all the tools you've included on CI (e.g protobot/stale). Because some of those tools might require permissions that the organization (Google in this case) is not willing to grant.

[hannesa2]

@hannesa2 I particularly prefer the way they are right now (separate modules), this way developers can build each module separately, since sometimes they're only interested in trying out only one of the apps.

Yes, and every developer don't know, what the other does.
Separate apps will need a separate CI task, which are not done

On a side note, I think it would be cool if you listed on the PR description all the tools you've included on CI (e.g protobot/stale). Because some of those tools might require permissions that the organization (Google in this case) is not willing to grant.

Don't worry, as long as nobody likes this practical all-in-one sample, this CI changes will be never a pull request in upstream repo (look it's a PR into my fork)

[hannesa2]

For me at least it makes sense. Now, I've an overview what's included.
@rosariopfernandes
Please remember, you make your upstream repo for other developer, not for you !

[thatfiredev]

@hannesa2 Oops, I didn't notice this was on your fork, my bad. I got here through a comment you left on a PR to the upstream repo. Thanks for pointing that out!

[hannesa2]

@rosariopfernandes
Please mention, now there is a CI which tests ALL android projects

[hannesa2]

This is how it looks like