[android-auto] Add gradle support #3892

Closed

AndrewShkrob wants to merge 1 commit from android-auto/gradle-config into master

AndrewShkrob commented

2022-11-15 18:42:38 +00:00

Member

The second part of #3806.

I know about issue #3886. From my pov, there is a lot of time to find a solution because it can wait until the end of Android Auto development.

My proposition:

Separate product flavor car for Android Auto development and maybe AAOS in future
Product flavor noCar. It will be used for release builds during the AA development
- I don't like noCar name. Do you have a better variant?
- I also tried to find a way to set an empty name for this flavor but didn't find a solution. Having an empty flavor name will be better in our case - no need to update almost all android workflows and playConfigs section in build.gradle . Maybe you know how to implement it?

Probably there is no way to set an empty flavor name.
So, AA support can be implemented by setting a flag f.e. in gradle.properties file. What do you think about this solution?

The second part of #3806. I know about issue #3886. From my pov, there is a lot of time to find a solution because it can wait until the end of Android Auto development. My proposition: * Separate product flavor `car` for Android Auto development and maybe AAOS in future * Product flavor `noCar`. It will be used for release builds during the AA development * I don't like `noCar` name. Do you have a better variant? * I also tried to find a way to set an empty name for this flavor but didn't find a solution. Having an empty flavor name will be better in our case - no need to update almost all android workflows and `playConfigs` section in `build.gradle` . Maybe you know how to implement it? Probably there is no way to set an empty flavor name. So, AA support can be implemented by setting a flag f.e. in `gradle.properties` file. What do you think about this solution?

rtsisyk reviewed 2022-11-15 18:42:38 +00:00

rtsisyk commented

2022-11-16 06:55:58 +00:00

Owner

Noted. Need some time to research available options.

biodranik commented

2022-11-16 09:41:55 +00:00

(Migrated from github.com)

I don't think that we need to complicate everything by supporting APIs 21 and 22. Let's make the decision and move to min SDK API 23. To make it smoother, let's follow this plan:

Review, test and merge as much API 21-compatible code for AA as possible.
Keep a separate branch with min API 23 and AA enabled for active development and testing.
When AA will be production-ready, we'll make the last stable API 21 public release of OM.
After that, we'll merge AA into the master and drop API 21-22 support.

It will help us to save a lot of time on future support and releases.

Ideally, it would be great to add dynamic map updates before dropping API 21, will see if we can make it.

I don't think that we need to complicate everything by supporting APIs 21 and 22. Let's make the decision and move to min SDK API 23. To make it smoother, let's follow this plan: 1. Review, test and merge as much API 21-compatible code for AA as possible. 2. Keep a separate branch with min API 23 and AA enabled for active development and testing. 3. When AA will be production-ready, we'll make the last stable API 21 public release of OM. 4. After that, we'll merge AA into the master and drop API 21-22 support. It will help us to save a lot of time on future support and releases. Ideally, it would be great to add dynamic map updates before dropping API 21, will see if we can make it.

rtsisyk commented

2022-11-17 11:04:52 +00:00

Owner

I don't think that we need to complicate everything by supporting APIs 21 and 22. Let's make the decision and move to min SDK API 23. To make it smoother, let's follow this plan:
1. Review, test and merge as much API 21-compatible code for AA as possible.

2. Keep a separate branch with min API 23 and AA enabled for active development and testing.

3. When AA will be production-ready, we'll make the last stable API 21 public release of OM.

4. After that, we'll merge AA into the master and drop API 21-22 support.
It will help us to save a lot of time on future support and releases.

Ideally, it would be great to add dynamic map updates before dropping API 21, will see if we can make it.

In this case we need inverted structure. All new AA code should go to main flavour, legacy stuff we can try to maintain in legacy flavour.

I haven't found any good documentation on how to use multiple AAB Bundles to target different API levels. With APK it is possible, with AAB - IDK. I filed a support request to Google. Let's wait for their response. Please be patient.

> I don't think that we need to complicate everything by supporting APIs 21 and 22. Let's make the decision and move to min SDK API 23. To make it smoother, let's follow this plan: > > 1. Review, test and merge as much API 21-compatible code for AA as possible. > > 2. Keep a separate branch with min API 23 and AA enabled for active development and testing. > > 3. When AA will be production-ready, we'll make the last stable API 21 public release of OM. > > 4. After that, we'll merge AA into the master and drop API 21-22 support. > > > It will help us to save a lot of time on future support and releases. > > Ideally, it would be great to add dynamic map updates before dropping API 21, will see if we can make it. In this case we need inverted structure. All new AA code should go to `main` flavour, legacy stuff we can try to maintain in `legacy` flavour. I haven't found any good documentation on how to use multiple AAB Bundles to target different API levels. With APK it is possible, with AAB - IDK. I filed a support request to Google. Let's wait for their response. Please be patient.

biodranik commented

2022-11-19 12:53:08 +00:00

(Migrated from github.com)

Let's proceed without hacks and workarounds. Separate and merge as much common code into the master branch as possible, and keep ready-to-merge, rebased, tested, and working AA branch, which will drop API 21-22 support when we decide that it's production-ready, and the last stable API 21-22 release is out. We can build and distribute betas from the AA branch to make sure that it is production-ready.

That means that there should be a separate commit that cleans up API 21-22 related stuff on the AA branch.

👍 2

rtsisyk commented

2022-11-20 06:49:28 +00:00

Owner

Let's proceed without hacks and workarounds. Separate and merge as much common code into the master branch as possible, and keep ready-to-merge, rebased, tested, and working AA branch, which will drop API 21-22 support when we decide that it's production-ready, and the last stable API 21-22 release is out. We can build and distribute betas from the AA branch to make sure that it is production-ready.

That means that there should be a separate commit that cleans up API 21-22 related stuff on the AA branch.

Agree.

> Let's proceed without hacks and workarounds. Separate and merge as much common code into the master branch as possible, and keep ready-to-merge, rebased, tested, and working AA branch, which will drop API 21-22 support when we decide that it's production-ready, and the last stable API 21-22 release is out. We can build and distribute betas from the AA branch to make sure that it is production-ready. > > That means that there should be a separate commit that cleans up API 21-22 related stuff on the AA branch. Agree.

AndrewShkrob commented

2022-11-20 16:20:40 +00:00

Author

Member

So, I'll prepare another PR with all AA code from #3806 to a separate branch.