Update tor-android-service Project to Use Android Toolchain (Firefox 68)
Update tor-android-service Project to use the new android toolchain. This will include updating gradle dependencies and changes to the api versions.
Activity
Trac:
Parent Ticket: #30324 (moved)Branch 07017
https://github.com/sisbell/tor-browser-build/commit/36adde99982fc4792dbdeeed5faccf165b1cc623
Trac:
Status: new to needs_review
Here are some comments:
-
Where is the
remove-vpn.patchcoming from? I doubt that it applies to our current HEAD. If we need to have patches fortor-android-service, please provide them against our repo. That's the canonical one now. -
I doubt we still need
export GRADLE_MAVEN_REPO="file://$gradle_repo"as the patches relying on that are gone? -
How do I re-create the dependencies list? I tried now for a while but still failed. Please update the
how-to-create-gradle-dependencies-list.txtso I can verify your work.
Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201908R deleted, TorBrowserTeam201908 added-
Replying to gk:
Here are some comments:
- Where is the
remove-vpn.patchcoming from? I doubt that it applies to our current HEAD. If we need to have patches fortor-android-service, please provide them against our repo. That's the canonical one now. I'll submit a merge request for the changes. The tor-android-service on my branch has moved the vpn into its own module, so this patch will remove it entirely from the build.
- I doubt we still need
export GRADLE_MAVEN_REPO="file://$gradle_repo"as the patches relying on that are gone? Good point, we are now using command line to set repo. I'll remove this line.
- How do I re-create the dependencies list? I tried now for a while but still failed. Please update the
how-to-create-gradle-dependencies-list.txtso I can verify your work.
I'll add those changes now, but basically with gradle 4.10 download logs only show up in debug mode and I have a new grep command since the output is very different.
Change firefox/build export GRADLE_FLAGS="--no-daemon --offline --debug"
cat logs/firefox-android-x86.log | grep "Performing HTTP" | grep -o "https://.*" | sort | uniq > downloads.log
- Where is the
I need to get review and merge of tor-android-service. Branch 0801a contain all the latest changes from orbot to tor-android-service. There are a lot of changes here since I've been keeping up with the work going into Orbot.
https://github.com/sisbell/tor-android-service/commits/0801a
Revision 5c9583cf8e2b7002f71c2971aae7ebb44c067b42 on July 17th is the minimum I think we can use, so that would cut down a lot of review time. The changes after are not so critical for us.
How do we want to do this?
Trac:
Status: needs_revision to needs_review-
Replying to sisbell:
I need to get review and merge of tor-android-service. Branch 0801a contain all the latest changes from orbot to tor-android-service. There are a lot of changes here since I've been keeping up with the work going into Orbot.
https://github.com/sisbell/tor-android-service/commits/0801a
Revision 5c9583cf8e2b7002f71c2971aae7ebb44c067b42 on July 17th is the minimum I think we can use, so that would cut down a lot of review time. The changes after are not so critical for us.
Okay. I can see how that particular commit is relevant for us but I am not so sure about the previous ones. What about we pick just that one for now to unblock our nightly and alpha builds and think about the other ones later on?
How do we want to do this?
We can discuss this in one of our team meetings but here is how I think we should do it: we treat tor-android-service as any of our other project. That means proposed changes need a ticket on our bug tracker (right now this is Trac but it might become Gitlab or $foo). Then someone needs to write a patch, point to a branch (be that one on our own infrastructure, or Github, Gitlab or...) and find someone to review and merge the changes.
The patch should a) be based on our master branch as we own the canonical repo now and b) it should be written in a way that we don't have to suddenly apply patches to any of our other projects. E.g. it's nice to redo the VPN support part but the resulting patch should be written in a way that we not have to suddenly apply
tor-browser-buildpatches to rip things out there. More precisely, it would be written in a way that projects can make use of VPN support but others can safely ignore that part to reduce attack surface etc. by setting a compile time option to just not compile that part in in the first place.Does that make sense? If so, please file new tickets for the changes we should make in
tor-android-service, point to the patches (please base them on ourmasterbranch to make merging easier) and set the tickets intoneeds_review. Replying to gk:
Replying to sisbell:
I need to get review and merge of tor-android-service. Branch 0801a contain all the latest changes from orbot to tor-android-service. There are a lot of changes here since I've been keeping up with the work going into Orbot.
https://github.com/sisbell/tor-android-service/commits/0801a
Revision 5c9583cf8e2b7002f71c2971aae7ebb44c067b42 on July 17th is the minimum I think we can use, so that would cut down a lot of review time. The changes after are not so critical for us.
Okay. I can see how that particular commit is relevant for us but I am not so sure about the previous ones. What about we pick just that one for now to unblock our nightly and alpha builds and think about the other ones later on?
How do we want to do this?
We can discuss this in one of our team meetings but here is how I think we should do it: we treat tor-android-service as any of our other project. That means proposed changes need a ticket on our bug tracker (right now this is Trac but it might become Gitlab or $foo). Then someone needs to write a patch, point to a branch (be that one on our own infrastructure, or Github, Gitlab or...) and find someone to review and merge the changes.
The patch should a) be based on our master branch as we own the canonical repo now and b) it should be written in a way that we don't have to suddenly apply patches to any of our other projects. E.g. it's nice to redo the VPN support part but the resulting patch should be written in a way that we not have to suddenly apply
tor-browser-buildpatches to rip things out there. More precisely, it would be written in a way that projects can make use of VPN support but others can safely ignore that part to reduce attack surface etc. by setting a compile time option to just not compile that part in in the first place.Does that make sense? If so, please file new tickets for the changes we should make in
tor-android-service, point to the patches (please base them on ourmasterbranch to make merging easier) and set the tickets intoneeds_review.I think this makes sense but I don't think we would have time before first alpha. What we can do is just use latest tor-android-service from tor repo and I'll modify firefox to use it. It will also require regenerating the dependencies.
I updated the build to use the tor repo version of tor-android-service
https://github.com/sisbell/tor-browser-build/commit/7dbdddb716962ee0ee7de81460762c07d8d772f7 https://github.com/sisbell/tor-browser-build/tree/esr68_0830
Trac:
Status: needs_revision to needs_review
