[tbb-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Nov 14 16:21:04 UTC 2018


#28051: Build Orbot into TBA
-------------------------------------------------+-------------------------
 Reporter:  sysrqb                               |          Owner:  sysrqb
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-mobile, tba-a2,                  |  Actual Points:
  TorBrowserTeam201811                           |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by sysrqb):

 Okay. I spent a more than a few days troubleshooting a bug in Fennec this
 patch introduced. There is one more issue that remains and I'm not sure
 which direction we go with this right now (see ticket:27977#comment:12),
 I'll paste it here, as well for reference:

 > Right, this is a problem. We have two choices, and I don't particularly
 like either of them. Orbot doesn't need API 27 support, API 26 is
 sufficient. However, we have a problem with the Android Support Library
 version it uses.

 > Orbot uses notifications (the message in the drop-down menu at the top)
 for showing information about Orbot's current state. We can take advantage
 of this by giving TBA users a way to open TBA's Orbot and configure it.
 The UX-flow is a little weird, and we can improve on it, but I think the
 notification is very helpful. However, this is only available beginning
 with the Android support library version 26.1.0. Orbot compiles and runs
 without a problem when its compiled against version 26.1.0, so we can make
 this change easily. However, Fennec uses version 23.4.0. Unfortunately,
 version 23.4.0 can't create notifications on new versions of Android
 (Android O added a new "Channel ID" attribute, and setting this is a
 requirement of all notifications, but there isn't a way to set it when we
 use an Android Support Library less than 26.1.0). It gets better because
 between version 23.4.0 and 26.1.0, Android changed the name of some built-
 in images (Material Design resources), so Fennec doesn't compile against
 Support library 26.1.0 (without patching Fennec for the name change). With
 all this being said:

 > 1) We can downgrade the version of the support library Orbot depends on,
 and lose Notifications on Android O (and later version)
 > 2) We can upgrade the version Fennec depends on and add a patch that
 changes the resource names.

 The bug I tracked was a result of the way Fennec recovers from Android
 killing part of the app but not the entire thing. Specifically, but for
 simplicity, we can think of Android apps as being divided into three
 parts: the Application, the Activity, and the Service. When Fennec is
 initialized (either first-run, or the device was rebooted, or the app was
 force stopped), Fennec's Application is created which instantiates
 numerous Java classes and keeps the state of the overall app. Then
 Fennec's Activity is created (the browser part) and that statically loads
 the Gecko library in addition to creating the browser UI and restoring
 previous saved state, and creating a new Gecko session with the Chrome and
 nsWindow and various other parts. Usually, if Android kills Fennec's
 Activity (because it needs to recover some memory or because the user
 "swipped" away the app), then the Activity is destroyed as well as the
 Application state. This means when the app is next run, everything is
 initialized again. However, now we have Orbot running as a background
 service, and it isn't destroyed when the Activity is destroyed...this also
 means the underlying Application isn't destroyed (because the Application
 encompasses all Activities and Services). This resulted in following a new
 code path within Fennec when the App was next launched. Now, instead of
 re-initializing everything, it only re-instantiated and initialized the
 Activity pieces. The end result is that the underlying application
 remembered some information about the previous time the app was run (in
 particular, the tabs that were open), but Gecko didn't have any
 information about them because that is created and tracked by the Activity
 (and it was lost when the Activity was destroyed). The fix is simply
 iterating over all of the tabs the application knows again, and
 "reloading" them - this instantiates new tabs within the chrome and brings
 the chrome in sync with the Android UI.

 I'm going to clean up the patches a little more, and then I'll post them.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28051#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tbb-bugs mailing list