Related
Anybody else upset that you cannot root the device and install common linux shell utilities on it such as ssh, curl, etc? I created a petition for google to create a set of shell utilities for all android owners, regardless as root. Even without root, there is no reason we can't use ssh. This is common on most linux hosts. Please have a look and consider signing the petition, or give me feedback.
https://www.change.org/p/google-inc...utm_source=share_petition&utm_medium=copylink
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Hi #Sual, while you are correct, SSHDroid provides an SSHd server, However it does not provide a native ssh client, I could run through the connected device. I have tried many things suggested by users, but none of them offer a set of shell utilities I can run from the android host shell itself. Did you have a chance to read through the petition and fully understand what I'm requesting. Similar functionality would come from dan drowns android ports, or lil debi, or busybox, but all require root. Finally the fact things aren't updated for 5.0 compatibility, underscores that There is a reason that people desire this functionality on the device itself. Thanks for your feedback.
Saul Goodman said:
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Click to expand...
Click to collapse
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
ecaslak said:
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
Click to expand...
Click to collapse
Hi @ecaslak ,
I will try your suggestions. Most recently I've tried GNURoot Debian, which uses proot. However I was unable to use the open ssh server I installed on it. However, I will still stand by my petition.
A significant portion of the Android community spends great effort trying to root their devices, many with only the desire for common functionality that we have from any core linux distribution. While having root itself on a device would be great, it should be expected that google provide all device owners with basic functionality found in most core linux distributions for the last 20+ years. Not including an option for basic user utilities ( ssh / wget or curl / most of what is included in busybox, a fairly powerful common shell such as bash or similar ) , that most non-root accounts have on practically all systems, limits the freedom of expression and ability to create that users have come to expect from a GNU Linux distribution.
While root can be enjoyed on many devices, this is often only available to a small segment of the population who either pays a significant amount more for a unlocked device with a free bootloader, or spends a significant amount of time trying to root their device. Android does seem to provide a small set of simple userland utilities such as ls, cat, but not much beyond that. This is a request to provide a set of utilities similar to what is found on most any common Linux distribution.
While their is some concern for manufacturers or communication companies to lock their users devices down, there should be no concern allowing basic utilities on all android devices. To be specific, what harm does allowing somebody to download a file through a terminal using wget or curl, or to ssh into a host , or the phone itself? Similar functionality to these kind of operations are provided to developers in the form of the Android SDK, and or libraries and programs that can be installed on all android platforms. However having simple system shell utilities is quite different that writing an application. Then there should be no harm in making them more accessible to the Android community, in said form. Finally the communications companies will benefit from increased usage, and therefore data billings from providing these features.
This petition requests that Google compile / create / maintain / distribute a set of common linux shell utilities to be included with the device, or provided through the play store for all Android versions moving forward. The people who are signing this petition believe that any owner should be able to use common *nixy functionality on any personally owned android device, regardless of device manufacturer or communication company.
Furthermore, we believe that by creating a standard distribution for these tools will reduce the effort of many people doing the same thing in their own time. That a standard will improve the tools themselves, and improve the Android experience to the community at large.
Google Android has stood on the back of giants, and taken the Linux kernel and wrapped a nice system and SDK around it, with the exception of removing some of the core functionality included in most any Linux system. Thus Android is significantly limiting the freedom of users. This is a proposal for the middle ground, which will allow a better system for everyone, even people who have no root or unlocked device.
Finally I Had a look at the kbox project, I think this sentence from their site underscores the challenge users face:
"Android is not Linux, as Google repeatedly tells us — and getting ordinary Linux desktop utilities to work in Android can be a chore, to say the least."
Hi @sual, I believe change.org is having some issues with their servers the past few days. Sorry for the dead link. I re-posted above and found it working. I also pasted the petition arguments above. It is my belief that if enough people desire a feature, then it is reasonable to ask Google to provide such a feature. I think it's reasonable to create a petition for something you believe in. Finally I appreciate your feedback, and have considered your point of view.
Saul Goodman said:
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
Click to expand...
Click to collapse
Finally, another link in case the copy link from the change.org platform is broken.
https://www.change.org/p/google-inc...-linux-shell-comands-for-the-android-platform
Incredibly few Android users root. And Android is not a traditional Linux distribution; it's a mobile OS that happens to use the Linux kernel. GNU/Linux distributions contain all these common tools because large essential portions of them are written in scripting languages and because they are needed for operation of the system. These things are simply superfluous in Android.
Google hasn't removed any functionality from a Linux distribution in the building of Android. They build a totally different system using Linux as the kernel. and have no need to include other separate components that comprise a standard Unixlike environment Just like all kinds of other embedded devices do. In this sense, Linux is a commodity OS kernel that competes with other open-source and proprietary ones. Furthermore, Android in particular depends on non-POSIX mechanisms like wakelocks and SELinux and uses an unPOSIXlike approach to isolate different apps (different uid per app).
I suggest you start writing code or organize a project and recruit developers to build this.
@sual Developers have already built plenty of Android binaries. I can build em. Look here: http://dan.drown.org/android/ . There are busybox sets all over the play store. The problem remains that they are usually crippled if installed without root. Crippled beyond the point of what you can do with a user account in most Linux environments. I thought the desire for this would be greater, but maybe I'm just an odd fish. I should save up and look for a platform that meets my wants and needs.
If tools running as a non-root user on Android seem more crippled than a non-root user on a typical Linux distribution, it's because Android uses a different UID per app for isolation purposes. Which is a good thing. Hence the existence of the "system" user on Android, accessible via adb, which has many more permissions than available to any particular app. Making even this set of permissions more widely available to apps would be a security nightmare, there's a reason you have to deliberately turn on developer mode then again enable ADB, and a reason why you (afaik) have to have root if you want to enable ADB over wifi on the device itself.
With that said, you should be able to package your own tools and run them via the adb user on any Android device, no?
All features, full flexibility, no bloat -- one simple solution!
On the one hand, it is frequently being suggested to build into Lineage various apps and features. Most of these suggestions are required by some users only, would bloat the core ROM, or have other downsides. On the other hand, these apps and features are usually already implemented somewhere, most users want incremental updates and many would prefer a fully-featured ROM without GApps installed.
To satisfy those wishes and yet avoid the downsides, I suggest simply supporting F-Droid and microG instead:
Idea outline:
Provide API for and build in F-Droid Privileged Extension
Thus have a Store, with automatic updates, and all bells and whistles
Ship with (rebranded fork of) F-Droid pre-installed and a custom LineageOS repository pre-configured (like Guardian Project in F-Droid)
Add AOSP apps, Lineage apps and Lineage-specific versions / branches of apps to LineageOS repository
Use "unstable update" marker in F-Droid to beta test new versions, e.g. of launcher, locker, ...
For additional, bloating apps and features, have users install what's already there (for instance, Location Services: UnifiedNLP with LocalWifiNlpBackend)
Add to Lineage Wiki a curated list of well-tested app suggestions for basic tasks (for instance, WebDAV: DAVdroid, Tasker, Etar, ...).
Key Advantages:
Developer effort most efficiently used
Faster time to market, because much is already implemented
Higher quality, less bloat, more features by referring users to existing apps and joining efforts
Easier innovation, because versions of pre-installed / system apps are publishable like regular apps
Developers happy, because LineageOS is clean at its core
Enthusiasts happy, because they can built on a minimal ROM
End Users happy, because they can easily use ROM, using curated list of apps
Regular, normal app updates for all system apps and pre-installed apps through Lineage repository
Does not prevent using GApps, but improves life without
Major step towards fully featured ROM, and yet without any proprietary apps or services
For good reasons, it's what Google does, it's what GNU/Linux distributions do.
One framework will solve most problems, provide most features ever suggested.
This will make everybody happy.
tldr
Bump!!!!
1, 2, 3 - Fully agree. If I had a proper Play Store alternative I wouldn't need Gapps at all.
4 - Essential in what way? I'd say its best to have only AOSP apps and to let every user download the apps he uses.
There would be practically no bloatware available and the ROM would truly give users the best choices.
8 - Additional preinstalled apps? Rather not.
9 - Rather AOSP mail. Someone might not want to use K-9, but for those who do they can always download it.
10 - Same as 9, avoid preinstalling apps that are already provided by AOSP.
11 - Eleven is OK for me, but still I find it somehow way underpowered. I really miss Apollo from early CM days...
14, 15 - I agree on ROM type. Allow users to select nightly, weekly or stable update channel through settings. Regarding basic preloaded apps, it would be OK only by means of AROMA installer where you could choose which ones you actually want/need.
Cheers!
In this thread it is being suggested to build into Lineage various Launchers, Themes, Widgets, Apps, WebDAV support, et cetera. As a contrasting response to that, I suggest simply supporting F-Droid and microG instead. A Lineage repository for F-Droid could include all AOSP apps; F-Droids own repository would supplement this.
It appears to me, almost everything which has been popularly requested would thereby be solved.
dj_chapz said:
4 - Essential in what way? I'd say its best to have only AOSP apps and to let every user download the apps he uses.
There would be practically no bloatware available and the ROM would truly give users the best choices.
Click to expand...
Click to collapse
Here, "essential" refers to, more or less, what's needed to install other apps (launcher, browser, file manager),
but could be thought of as to include functions, which were typical for feature phones, too (basic messenger, dailer, calendar).
dj_chapz said:
8 - Additional preinstalled apps? Rather not.
9 - Rather AOSP mail. Someone might not want to use K-9, but for those who do they can always download it.
10 - Same as 9, avoid preinstalling apps that are already provided by AOSP.
11 - Eleven is OK for me, but still I find it somehow way underpowered. I really miss Apollo from early CM days...
Click to expand...
Click to collapse
These were just written-out to illustrate what would be possible.
I'll adjust the original post for clarity.
Anybody can fork it and add their ideas. Some people do not want to support fdroid. Keep it clean + gapps.
goorek said:
Anybody can fork it and add their ideas. Some people do not want to support fdroid. Keep it clean + gapps.
Click to expand...
Click to collapse
Even if F-droid wasn't preinstalled, could be a Lineage repo for it?
LineageOS IMHO should really seek to become the ROM for professional PIM, self-employed, small-business or even big-business device users which seek to avoid GApps and rely on a clean slim ROM. So I like many of grefnab's ideas but currently have no clear idea what the stakeholders of LineageOS have as main goals for the midterm.
Having everything App based in an "FOSS App Package" (as GApps and commercial/device App replacement) with advanced support by LineageOS and/or other main CustomROMs would be geat. See my post in What features would you like to see in Lineage that CM didn't have?
support 1-3
I really hope that this thread will get recognition. I really like the idea of having priviliged F-Droid build into the ROM.
That would make everything much easier.
I fully support the three first points
Provide API for and build in F-Droid Privileged Extensio
Thus have a Store, with automatic updates, and all bells and whistles
Ship with F-Droid pre-installed and a custom LineageOS repository (like Guardian Project) pre-configured
Click to expand...
Click to collapse
The rest is nice but I would put emphasis on the first three points. They seem like a real advantage to have.
Rephrased some sentences to clarify
This seems like a very good idea to me :good:
I mean it is basically the same procedure Google has in place to keep its apps up-to-date without people having to update their firmwares. Being able to update the apps independently from the rom would be a huge benefit in my opinion. While I don't use gapps on my phone at all, I understand, that some people find it essential. Therefore it would be a bad idea if this interfered with installing gapps in any way.
herrritschwumm said:
While I don't use gapps on my phone at all, I understand, that some people find it essential. Therefore it would be a bad idea if this interfered with installing gapps in any way.
Click to expand...
Click to collapse
This would not prevent installing GApps, it would simplify and improve usage without them, though.
+1 for having LOS F-droid repo and bundling F-droid and having fewer other preinstalled apps.
I think this thread is a very good idea!
Just a clarification on technicalities:
microG kinda requires signature spoofing. More specifically MicroG effectively has two principal frameworks inside -- location services and GCM. Location services would work regardless, but iirc for GCM to work properly the ROM itself would need a signature spoofing support. All other ways to enable spoofing employing needlepatch or whatever are ridiculously impractical and one cannot expect normal users to bother with them.
I have two phones (OP1 and OP3) and for both the choice is of exactly ONE custom rom only (based on LineageOS14.1) with a spoofing patch. Therefore applying spoofing patch into the main code base would be great. However the caveat here is that any app or framework like SafetyNET would most likely stop working. Since the developers decided to push for compatibility, I seriously doubt that they would implement signature spoofing.
They could try to implement the patch in a flashable zip like with root but I don't know if it is possible.
fully agree for spoofing support since we are out ot cm
Sent from my Nexus 5 CAF using Tapatalk
I would like to see signature spoofing built into lineageOS or an optional flashible zip, too. But right now a flashible zip could take a long time to flash. See: https://github.com/microg/android_packages_apps_GmsCore/issues/196
Sounds great.
dj_chapz said:
If I had a proper Play Store alternative I wouldn't need Gapps at all.
Click to expand...
Click to collapse
You could try Yalp Store, it's there in the F-Droid repository.
@grefnab: My flashable zip help those that want to automatically without any effort: remove GApps, install microG and F-Droid Privileged Extension.
1plus said:
Just a clarification on technicalities:
microG kinda requires signature spoofing. More specifically MicroG effectively has two principal frameworks inside -- location services and GCM. Location services would work regardless, but iirc for GCM to work properly the ROM itself would need a signature spoofing support. All other ways to enable spoofing employing needlepatch or whatever are ridiculously impractical and one cannot expect normal users to bother with them.
However the caveat here is that any app or framework like SafetyNET would most likely stop working. Since the developers decided to push for compatibility, I seriously doubt that they would implement signature spoofing.
Click to expand...
Click to collapse
Tingle is very easy to use, if you find something impratical just tell me.
SafetyNet do pass for me.
If you are running Lineage OS for the BLU R1HD, or almost any custom ROM on any device, you have probably gotten this message from android pay, PS Vue, or a number of other apps: "can not run on a rooted device". This is easy to fix on a rooted device, but a custom ROM is a whole other story. I kept getting CTS profile mismatch, regardless of what I tried. I'm not a developer, but I am no dummy, work as an OpenStack engineer, and have been in network engineering for 15 years, yet I could not find crap about CTS, other than it is the " Comparability Test Suite ". After hunting the web, I finally stumbled upon a good article that explains it pretty nicely, so here it is:
------------
Rooting your Android device gives you access to a wider variety of apps and a deeper access to the Android system. But some apps–like Google’s Android Pay–won’t work at all on a rooted device.
Google uses something called SafetyNet to detect whether your device is rooted or not, and blocks access to those features. Google isn’t the only one, either–plenty of third-party apps also won’t work on rooted Android devices, although they may check for the presence of root in other ways.
SafetyNet: How Google Knows You’ve Rooted Your Android Phone
Android devices offer a “SafetyNet API,” which is part of the Google Play Services layer installed on Google-approved Android devices. This API “provides access to Google services that help you assess the health and safety of an Android device,” according to Google. If you’re an Android developer, you can call this API in your app to check whether the device you’re running on has been tampered with.
This SafetyNet API is designed to check whether a device has been tampered with–whether it’s been rooted by a user, is running a custom ROM, or has been infected with low-level malware, for example.
Devices that ship with Google’s Play Store and other apps installed must pass Google’s Android “Compatibility Test Suite”. Rooting a device or installing a custom ROM prevents a device from being “CTS Compatible”. This is how the SafetyNet API can tell if you’re rooted–it merely checks for CTS compatibility. Similarly, if you get an Android device that never came with Google’s apps–like one of those $20 tablets shipped direct from a factory in China–it won’t be considered “CTS compatible” at all, even if you haven’t rooted it.
To get this information, Google Play Services downloads a program named “snet” and runs it in the background on your device. The program collects data from your device and sends it to Google regularly. Google uses this information for a variety of purposes, from getting a picture of the wider Android ecosystem to determining whether or not your device’s software has been tampered with. Google doesn’t explain exactly what snet is looking for, but it’s likely snet checks if your system partition has been modified from the factory state.
You can check the SafetyNet status of your device by downloading an app like SafetyNet Helper Sample or SafetyNet Playground. The app will ask Google’s SafetyNet service about your device’s status and tell you the response it gets from Google’s server.
It’s Up to the App
SafetyNet is optional for app developers, and app developers can choose to use it or not. SafetyNet only prevents an app from working if an app’s developer doesn’t want it to work on rooted devices.
Most apps won’t check the SafetyNet API at all. Even an app that does check the SafetyNet API–like the test apps above–won’t stop working if they receive a bad response. The app’s developer has to check the SafetyNet API and make the app refuse to function if it learns your device’s software has been modified. Google’s own Android Pay app is a good example of this in action.
Android Pay Won’t Work on Rooted Devices
Google’s Android Pay mobile payment solution doesn’t work at all on rooted Android devices. Try to launch it, and you’ll just see a message saying “Android Pay cannot be used. Google is unable to verify that your device or the software running on it is Android compatible.”
It’s not just about rooting, of course–running a custom ROM would also put you afoul of this requirement. The SafetyNet API will claim it’s not “Android compatible” if you’re using a custom ROM the device didn’t come with.
Remember, this doesn’t just detect rooting. If your device were infected by some system-level malware with the ability to spy on Android Pay and other apps, the SafetyNet API would also prevent Android Pay from functioning, which is a good thing.
Rooting your device breaks Android’s normal security model. Android Pay normally protects your payment data using Android’s sandboxing features, but apps can break out of the sandbox on a rooted device. Google has no way to know how secure Android Pay would be on a particular device if it’s rooted or running an unknown custom ROM, so they block it. An Android Pay engineer explained the problem on the XDA Developers forum if you’re curious to read more.
Other Ways Apps Can Detect Root
SafetyNet is just one way an app could check if it’s running on a rooted device. For example, Samsung devices include a security system named KNOX. If you root your device, KNOX security is tripped. Samsung Pay, Samsung’s own mobile-payments app, will refuse to function on rooted devices. Samsung is using KNOX for this, but it could just as well use SafetyNet.
Similarly, plenty of third-party apps will block you from using them, and not all of them use SafetyNet. They may just check for the presence of known root apps and processes on a device.
It’s tough to find an up-to-date list of apps that don’t work when a device is rooted. However, RootCloak provides several lists. These lists may be out-of-date, but they’re the best ones we can find. Many are banking and other mobile wallet apps, which block access on rooted phones in an attempt to protect your banking information from being captured by other apps. Apps for video streaming services may also refuse to function on a rooted device as a sort of DRM measure, attempting to prevent you from recording a protected video stream.
Some Apps Can Be Tricked
Google’s playing a cat-and-mouse game with SafetyNet, constantly updating it in an attempt to stay ahead of people getting around it. For example, Android developer Chainfire has created a new method of rooting Android devices without modifying the system partition, known as “systemless root”. SafetyNet initially didn’t detect such devices as being tampered with, and Android Pay worked–but SafetyNet was eventually updated to detect this new rooting method. This means Android Pay no longer works along with systemless root.
Depending on how an app checks for root access, you may be able to trick it. For example, there are reportedly methods to root some Samsung devices without tripping the KNOX security, which would allow you to continue using Samsung Pay.
In the case of apps that just check for root apps on your system, there’s an Xposed Framework module named RootCloak that reportedly allows you to trick them into working anyway. This works with apps like DirecTV GenieGo, Best Buy CinemaNow, and Movies by Flixster, which don’t normally work on rooted devices. However, if these apps were updated to use Google’s SafetyNet, they wouldn’t be so easy to trick in this way.
Most apps will continue working normally once you’ve rooted your device. Mobile payment apps are the big exception, as are some other banking and financial apps. Paid video-streaming services sometimes attempt to block you from watching their videos as well.
If an app you need doesn’t function on your rooted device, you can always unroot your device to use it. The app should work after you’ve returned your device to its secure, factory state.
I am checking every way hoping to find a solution ...
Yes...It's working.
I am using GPay on my rooted device !
It's with great pleasure that I inform you all that AndroIDentity 3.5 has been released, and it has several new features:
SafetyNet Attestation:
Attest the device per Google's SafetyNet API, using secure two-step validation of the results, and scan for Potentially Harmful Applications (PHAs)
System log (logcat)
A convenient and easy-to-use logcat tool, that displays the device's log, even on
non-rooted device (ADB is required to enable logcat on non-rooted devices). The output is color-coded by log type (verbose, info, warning, etc).
Powerful Package & Apps information
AndroIDentity's new Package Information gives you access to several important data on packages: store it was installed from, UID, storage location, direct link to its store (such as Google's, Amazon, Samguns, etc), filters, signing certificates, activities, and many other features usually not found on free apps.
Play Store and Service status
Check the status of the Play Store and Play Services and start Google's repair tool when a problem is found with Google Play Services.
Root Checker
Check for Root and Busybox status and location
KNOX Verification
For Samsung devices, AndroIDentity checks and reports the KNOX status of the device. Neverthless, AndroIDentity works on all brands of devices, from Android 4.0 forward.
Detailed device info
Keeping up with the tradition of AndroIDentity, it's most important feature is still there: it reports back to you several important information about the device under test, that can be compared to the device's datasheet for authenticity attestation.
Over 15,200 devices recognized
AndroIDentity correctly identifies and reports on over 15,200 devices, using an internal database that is kept up to date with new market releases.
Throughout the years, AndroIDentity has helped thousands of users being aware of fake/counterfeit devices, and even, in several cases, prevented users from buying non-genuine phones.
AndroIDentity works on all Androd devices, of all brands, as long as it runs Android 4.0 and newer. It is still donationware, which gives you a few perks, like an enhanced GUI, and the satisfaction to know you're supporting such an important project.
Download it now for free from: https://play.google.com/store/apps/details?id=com.alxdroiddev.gs3identity
I was just wondering why sailfishOS has still really bad apps.
and why is not developers are doing more apps for this amazing OS?
just wondering
it's very simple: no market.
In general you make apps to earn money. perhaps you'll find some developer or group of developers that will port a popular app as a hobby, student project, or simply because they are using sailfish and want an specific app.
so basically, if there is no market, there is no money. therefore no apps
Actually I have just bought xperia 10 plus to move away from toxic android ecosystem (from google to all the app junk), after I have figured out that I could delete 90% of application on my android phone and I would never miss them.
If you are using sailfish phone, you have an option to run apks there is no real need for native applications. Quite frankly in last few years I could hardly find any application that was something that "I have to have". All the really needed applications were added to the first smartphones: email, gps, browser, sms, mms, calls, video player, music player, camera, contacts, text editor, sound recording... and I am already stretching it with last two, I cant remember when I have last time wrote high volume of text on those tiny useless on screen keyboard or had a need to record some sound.
There is one app on android which I will need (access to online banking) and I hope it will work, it didnt work even on my previous android until I have reversed it and change some code to stop verifying for root and safetynet, so it should work here too.
Everything else is... more a toy than useful or actually some security application to prevent all others doing something that you don't want, from rolling ads to stealing data. I am waiting for this mobile application market to slowly collapse, there is no more value in it except maybe games. Everything else is just wasting time in the least constructive way.
And not having market is a huge bonus, if you check sailfish apps (jolla store and openrepos) you will find that you have everything you need for having a great phone, made by enthusiasts not people that want to become rich. And no one is making useless junk as, as valthunder said, there is no market. And this is fine. Actually great.
root said:
There is one app on android which I will need (access to online banking) and I hope it will work, it didnt work even on my previous android until I have reversed it and change some code to stop verifying for root and safetynet, so it should work here too.
Click to expand...
Click to collapse
Great to read about your decision!
For banking apps that require Google Services you could try to tweak your Sailfish Alien Dalvik with Signature Spoofing and a GServices replacement like MicroG.
The SafetyNet replacement here is the DroidGuard Helper that should be installed alongside GmsCore.
eltmosen said:
Great to read about your decision!
For banking apps that require Google Services you could try to tweak your Sailfish Alien Dalvik with Signature Spoofing and a GServices replacement like MicroG.
The SafetyNet replacement here is the DroidGuard Helper that should be installed alongside GmsCore.
Click to expand...
Click to collapse
Naah, I am having my own "cracked" apk build from previous phone, I have removed all checks to root and safetynet and it works fine, no need to change it. Since the app is just front end for web interface it works since forever, I have also removed version matching with server. Took a day or two but worth it
But I have one question: I am trying to integrate xposed framework (last version as there si no boot/recovery img to try with magisk) into system.img (8.1). And same goes for su. Is there any "official" way how to do it without unpacking system.img, adding binaries, repacking it...
root said:
But I have one question: I am trying to integrate xposed framework (last version as there si no boot/recovery img to try with magisk) into system.img (8.1). And same goes for su. Is there any "official" way how to do it without unpacking system.img, adding binaries, repacking it...
Click to expand...
Click to collapse
Following all things sfos quite closely i did not witness anyone get xposed framework to work. (at least no public report) That might be due to sfos users generally are not Android wizards. The matter might still be a low hanging fruit to anyone with deeper knowledge
Whenever rooting/xposed/su is brought up, much more competent guys then me hint at Alien Dalvik just being an AOSP tailored to run inside LXC on non android kernel plus filesystem integration, Intents integration, shared clipboard etc.
quoting my friend olf:
"Jolla uses many modern measures to confine the Android container: at LXC level, with cgroups, firewall rules, SElinux policies etc.
You may configure additional measures at all these levels, it is just a Linux machine and you are the administrator!"
So maybe what you want to achieve practically is even possible using a whole set of different tools then available in Android?
And yes, my vague explanation hinting at me being a simple user having no clue and just putting things together from forum posts is a correct observation