Activity
I don't know how much of the current
projects/tor-browser/buildfile can be shared between the desktop and android builds. If nothing, or almost nothing is common to both, then it might make sense to use a completely separate build file for the android build. This can be done by adding this toprojects/tor-browser/config:diff --git a/projects/tor-browser/config b/projects/tor-browser/config index bb1c259..8edd1e2 100644 --- a/projects/tor-browser/config +++ b/projects/tor-browser/config @@ -41,6 +41,8 @@ targets: windows-x86_64: var: mar_osname: win64 + android-armv7: + build: '[% INCLUDE build.android %]' input_files: - project: container-imageThen the build instructions for the android build can be written to
projects/tor-browser/build.android.That looks pretty good. I'm not familiar with abicheck.cc, and it looks like the patch is missing https-everywhere. I don't immediately see anything else that's different from what I'm doing. For reference, the script I use is here: https://github.com/sysrqb/build_tba_alpha/blob/master/build_tba_alpha
One difference is that I was downloading https-everywhere from the EFF website (for simplicity), instead of building it locally. Of course, with tor-browser-build we should use the locally built xpi.
So, from a high-level point we'd like to get a properly built and named Tor Browser for Android by executing commands like
make alphaormake nightly. That means after e.g. enteringmake alphaand after the build job is done the result should be ator-browser-android-arm-8.5a4.apkin alpha/unsigned/8.5a4-buildN (yes, I think once we have the mobile build integrated it could be a good time to switch to our "regular versioning" scheme).From a less high-level viewpoint this requires (at least) a) adapting the
Makefileto add the new targets and b) getting the extensions we need funneled into the .apk.For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed.
Replying to boklm:
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed.
To add assets, we can just use 'aapt add' command from the android SDK. We also need to make sure we resign the apk as part of a tor-browser step. We would do this with 'apksigner'.
Replying to sisbell:
Replying to boklm:
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed. To add assets, we can just use 'aapt add' command from the android SDK. We also need to make sure we resign the apk as part of a tor-browser step. We would do this with 'apksigner'.
The app won't be signed within tor-browser-build, so that isn't a problem. We only must produce a valid unsigned-unaligned apk as the result.
I agree adding the extensions in the tor-browser project (like we do for desktop) makes the most sense. We'll need to investigate what Mozilla do when a distribution is defined and replicate that in
build- I haven't looked closely enough at this, so I don't know what is needed.Replying to sisbell:
Changes (android-1106)
- Added var/desktop field. Used to disable the projects that android doesn't need (if there is better way open to suggestions)
I think you could use
! c("var/android").For a review of
2614830bb270321eaca0796587d1bd1a13295997:- the build.android script is missing a
[% c("var/set_default_env") -%]line at the begining - maybe
projects/firefox/buildcould rename the apk files to a more predictible filename (for the desktop builds we usetor-browser.tar.gz) so that there is no need to usefindinprojects/tor-browser/build.androidto find the filename. - I think that:
apkname='tor-browser-[% c("version") %]-[% c("var/osname") %].apk' [...] zip -r $apkname . cp $apkname [% dest_dir _ '/' _ c('filename') %]could be replaced by:
zip -r '[% dest_dir %]/[% c('filename') %]/tor-browser-[% c("version") %]-[% c("var/osname") %].apk' .Trac:
Status: needs_review to needs_revisionReplying to sysrqb:
Replying to sisbell:
Replying to boklm:
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed. To add assets, we can just use 'aapt add' command from the android SDK. We also need to make sure we resign the apk as part of a tor-browser step. We would do this with 'apksigner'.
The app won't be signed within tor-browser-build, so that isn't a problem. We only must produce a valid unsigned-unaligned apk as the result.
I agree that we should produce a valid unsigned-unaligned .apk. sisbell: I think that should be reflected in the filename in the final output (as Mozilla does with Fennec). I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Replying to gk:
I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Ah. Good point. The unsigned-unaligned apk should be (as the name implies) not signed. But when building Fennec with Mozilla's build system, they produce an additional apk that is signed with a debug signing key. It looks like that happens in config/android-common.mk, calling mobile/android/debug_sign_tool.py. I think we can use this, too.
Replying to sysrqb:
Replying to gk:
I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Ah. Good point. The unsigned-unaligned apk should be (as the name implies) not signed. But when building Fennec with Mozilla's build system, they produce an additional apk that is signed with a debug signing key. It looks like that happens in config/android-common.mk, calling mobile/android/debug_sign_tool.py. I think we can use this, too.
We have different types of signing under consideration:
- v1: Android 6 and earlier jarsigning
- v2: with signing block (Android 7) : https://source.android.com/security/apksigning/v2
- v3: with key rotation (Android 9): https://source.android.com/security/apksigning/v3
It looks like mozilla is using v1 for debug, this is the only case we need to consider for the debug build. For production level signing, we should consider looking into v3 (perhaps mozilla is already using v3 signing?)
Replying to sisbell:
Replying to sysrqb:
Replying to gk:
I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Ah. Good point. The unsigned-unaligned apk should be (as the name implies) not signed. But when building Fennec with Mozilla's build system, they produce an additional apk that is signed with a debug signing key. It looks like that happens in config/android-common.mk, calling mobile/android/debug_sign_tool.py. I think we can use this, too.
We have different types of signing under consideration:
- v1: Android 6 and earlier jarsigning
- v2: with signing block (Android 7) : https://source.android.com/security/apksigning/v2
- v3: with key rotation (Android 9): https://source.android.com/security/apksigning/v3
It looks like mozilla is using v1 for debug, this is the only case we need to consider for the debug build. For production level signing, we should consider looking into v3 (perhaps mozilla is already using v3 signing?)
Yes, but for the outcome in our tor-browser-build whatever Mozilla is doing is enough (e.g. v1 if we get that in our current firefox build). It's just for testing on devices that our code does what it should (and only that :) ). The real signing for release is done later, outside of our tor-browser-build environment.
I don't know how much of the current
projects/tor-browser/buildfile can be shared between the desktop and android builds. If nothing, or almost nothing is common to both, then it might make sense to use a completely separate build file for the android build. This can be done by adding this toprojects/tor-browser/config:diff --git a/projects/tor-browser/config b/projects/tor-browser/config index bb1c259..8edd1e2 100644 --- a/projects/tor-browser/config +++ b/projects/tor-browser/config @@ -41,6 +41,8 @@ targets: windows-x86_64: var: mar_osname: win64 + android-armv7: + build: '[% INCLUDE build.android %]' input_files: - project: container-imageThen the build instructions for the android build can be written to
projects/tor-browser/build.android.That looks pretty good. I'm not familiar with abicheck.cc, and it looks like the patch is missing https-everywhere. I don't immediately see anything else that's different from what I'm doing. For reference, the script I use is here: https://github.com/sysrqb/build_tba_alpha/blob/master/build_tba_alpha
One difference is that I was downloading https-everywhere from the EFF website (for simplicity), instead of building it locally. Of course, with tor-browser-build we should use the locally built xpi.
So, from a high-level point we'd like to get a properly built and named Tor Browser for Android by executing commands like
make alphaormake nightly. That means after e.g. enteringmake alphaand after the build job is done the result should be ator-browser-android-arm-8.5a4.apkin alpha/unsigned/8.5a4-buildN (yes, I think once we have the mobile build integrated it could be a good time to switch to our "regular versioning" scheme).From a less high-level viewpoint this requires (at least) a) adapting the
Makefileto add the new targets and b) getting the extensions we need funneled into the .apk.For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed.
Replying to boklm:
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed.
To add assets, we can just use 'aapt add' command from the android SDK. We also need to make sure we resign the apk as part of a tor-browser step. We would do this with 'apksigner'.
Replying to sisbell:
Replying to boklm:
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed. To add assets, we can just use 'aapt add' command from the android SDK. We also need to make sure we resign the apk as part of a tor-browser step. We would do this with 'apksigner'.
The app won't be signed within tor-browser-build, so that isn't a problem. We only must produce a valid unsigned-unaligned apk as the result.
I agree adding the extensions in the tor-browser project (like we do for desktop) makes the most sense. We'll need to investigate what Mozilla do when a distribution is defined and replicate that in
build- I haven't looked closely enough at this, so I don't know what is needed.Replying to sisbell:
Changes (android-1106)
- Added var/desktop field. Used to disable the projects that android doesn't need (if there is better way open to suggestions)
I think you could use
! c("var/android").For a review of
2614830bb270321eaca0796587d1bd1a13295997:- the build.android script is missing a
[% c("var/set_default_env") -%]line at the begining - maybe
projects/firefox/buildcould rename the apk files to a more predictible filename (for the desktop builds we usetor-browser.tar.gz) so that there is no need to usefindinprojects/tor-browser/build.androidto find the filename. - I think that:
apkname='tor-browser-[% c("version") %]-[% c("var/osname") %].apk' [...] zip -r $apkname . cp $apkname [% dest_dir _ '/' _ c('filename') %]could be replaced by:
zip -r '[% dest_dir %]/[% c('filename') %]/tor-browser-[% c("version") %]-[% c("var/osname") %].apk' .Trac:
Status: needs_review to needs_revisionReplying to sysrqb:
Replying to sisbell:
Replying to boklm:
Replying to gk:
For b) we usually have the bundling step (i.e. the tor-browser project). If that's not going to work (Is that the case? If so, why?) for Android (which would mean reopening the .apk we got in the firefox step and putting the extensions into place after building them if needed) we need to find a way doing that in the firefox build step and could do just the renaming in the tor-browser step.
However doing that in the firefox build means we need to rebuild firefox to update the extensions, so if that's possible, doing it in the
tor-browserstep would be better.It looks like .apk files are zip files, so I'm wondering if extracting them and adding the extensions in the right directory before rezipping the .apk file would work, or if there is something more needed. To add assets, we can just use 'aapt add' command from the android SDK. We also need to make sure we resign the apk as part of a tor-browser step. We would do this with 'apksigner'.
The app won't be signed within tor-browser-build, so that isn't a problem. We only must produce a valid unsigned-unaligned apk as the result.
I agree that we should produce a valid unsigned-unaligned .apk. sisbell: I think that should be reflected in the filename in the final output (as Mozilla does with Fennec). I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Replying to gk:
I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Ah. Good point. The unsigned-unaligned apk should be (as the name implies) not signed. But when building Fennec with Mozilla's build system, they produce an additional apk that is signed with a debug signing key. It looks like that happens in config/android-common.mk, calling mobile/android/debug_sign_tool.py. I think we can use this, too.
Replying to sysrqb:
Replying to gk:
I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Ah. Good point. The unsigned-unaligned apk should be (as the name implies) not signed. But when building Fennec with Mozilla's build system, they produce an additional apk that is signed with a debug signing key. It looks like that happens in config/android-common.mk, calling mobile/android/debug_sign_tool.py. I think we can use this, too.
We have different types of signing under consideration:
- v1: Android 6 and earlier jarsigning
- v2: with signing block (Android 7) : https://source.android.com/security/apksigning/v2
- v3: with key rotation (Android 9): https://source.android.com/security/apksigning/v3
It looks like mozilla is using v1 for debug, this is the only case we need to consider for the debug build. For production level signing, we should consider looking into v3 (perhaps mozilla is already using v3 signing?)
Replying to sisbell:
Replying to sysrqb:
Replying to gk:
I am not so sure, though, that not signing it is not a problem. How are we testing our final result on Android devices without any signing? (We don't have that problem on desktop platforms as signing requirements can get disabled if they are existing at all)
Ah. Good point. The unsigned-unaligned apk should be (as the name implies) not signed. But when building Fennec with Mozilla's build system, they produce an additional apk that is signed with a debug signing key. It looks like that happens in config/android-common.mk, calling mobile/android/debug_sign_tool.py. I think we can use this, too.
We have different types of signing under consideration:
- v1: Android 6 and earlier jarsigning
- v2: with signing block (Android 7) : https://source.android.com/security/apksigning/v2
- v3: with key rotation (Android 9): https://source.android.com/security/apksigning/v3
It looks like mozilla is using v1 for debug, this is the only case we need to consider for the debug build. For production level signing, we should consider looking into v3 (perhaps mozilla is already using v3 signing?)
Yes, but for the outcome in our tor-browser-build whatever Mozilla is doing is enough (e.g. v1 if we get that in our current firefox build). It's just for testing on devices that our code does what it should (and only that :) ). The real signing for release is done later, outside of our tor-browser-build environment.